> >> > Since "echo." is clearly a shell builtin, and > >> > >> I don't think "echo." is a shell builtin. It is a > >> peculiar feature of the cmd.exe command parser. > > > > This is a semantic quibble. The shell builtin > > is "echo", "echo." is an alternative form, and > > I believe that the real issue here is that, in some cases, > cmd.exe throws away a '.' after a built-in command. So, > it isn't, IMO, strictly correct to add an 'echo.'.
If things aren't confusing enough already... it's not just the "." that CMD.EXE will parse oddly after echo. Depending on your version of CMD.EXE, there are other chars which can also be put after echo, and will still result in the echo command being invoked. For example, CMD.EXE under WinXP [Version 5.1.2600], the echo command will "silently parse" the following chars in addition to ".". This is not an exhaustive list, simply a list pulled together from some quick testing on the command line: .(+\[]:;,/ I find it especially interesting that the \ and / chars are parsed in this manner, since they already have special meaning to the command shell. The top puzzler to me is the special case of using "/", assuming it is your default switch char (which it is on my machine). "Echo/?" results in a help blurb "Echo/This is a Test" resuts in "This is a test" being echoed to the console. Weird. All of the other special chars above seem to act just like the "." in "Echo.". If it were JUST the special case of "Echo.", I would absolutely be on the side of making the tweak to Make to support the one special case... but now that I know that CMD.EXE just has an obnoxious parser with some undocumented rules, I feel that trying to emulate that weirdness in Make would be an endless chase. Best to just leave it alone, IMO. Keith _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
