Using build 151. Should alias expansion cause an extra space to be inserted before switch (/) characters used in the alias parameters given when invoking the alias? It seems to do that with this alias: alias cpfrom=*copy /G ftp:%1 %2 c:\> cpfrom putget/idoc.zip After expansion with Ctrl-F: c:\> copy /G ftputget /idoc.zip Note the extra space after "putget". Needless to say, this causes the command to fail. A simple work-around is to use `cpfrom "putget/idoc.zip"` instead. Defining the alias as alias cpfrom=*copy /G "ftp:%1" %2 does not help. Is this behaviour deliberate or might it be a bug in the alias expansion handling? Might there be a way to define the alias so that `cpfrom putget/idoc.zip` works "as expected"? -- Niklas Bäckman
The "extra" space is in your alias definition, between the %1 and the %2. If you don't want PUTGET and /IDOC.ZIP to be treated as two separate parameters, then quoting the entire string is the correct way to do that.
nikbackm wrote: | Using build 151. | | Should alias expansion cause an extra space to be inserted before | switch (/) characters used in the alias parameters given when | invoking the alias? | | It seems to do that with this alias: | | alias cpfrom=*copy /G ftp:%1 %2 I presume you did not use the above command as displayed when defining the alias CPFROM, as it would have expanded %1 and %2 during definition, resulting in cpfrom is an alias: *copy /G ftp: With this definition of CPFROM, I get different result: Note the extra space BEFORE "putget". This is exactly what I would expect. I then tried alias cpfrom=`*copy /G ftp:%1 %2` Now entering as in the OP. Entering as expected, but it's wrong syntax! The problem is that / is parsed as a parameter separator. I have not come up with a variant alias to perform according to the perceived intent of the OP. Another problem is that if COPY is an alias, the alias expansion replaces *COPY with COPY, thus executing the command will use the value of the alias COPY, not the internal command COPY. This is definitely a parser error, or at least a limitation of the alias expansion logic triggered by ctrl-F. What I don't know is what the command actually built by the parser without the expansion actually looks like.
