Re: Problems with echo. (echo period)

[Christopher Faylor]

On Mon, Apr 23, 2007 at 03:22:40PM +0100, Dave Korn wrote:
>On 21 April 2007 10:02, Eli Zaretskii wrote:
>
>[ got left sitting in my drafts folder over the weekend. ]
>
>>> From: "Dave Korn" 
>>> Date: Fri, 20 Apr 2007 17:18:01 +0100
>>> On 20 April 2007 17:15, Aaron Shatters wrote:
>>> 
>>>> As I noted previously, there are many workarounds to this problem.  I am
>>>> interested in fixing the root cause.  After all of this investigation, do
>>>> we have consensus that this is a limitation of make?  More importantly, do
>>>> we have consensus that it should be fixed?  We seem to have run out of
>>>> reasons for not fixing this problem.
>>> 
>>>   Since "echo." is clearly a shell builtin, and since the code is supposed
>>> to recognize shell builtins and hand them off to the shell, I would support
>>> fixing this in the source.
>> 
>> 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 the main point is:

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 we really wanted to do this, it seems
like it would be better to recognize those built-ins which allow a '.'
and eat a dot in those case.

cmd.exe's handling of '.' seems to be funky, though.  It isn't as simple as
saying "just ignore the dot" since some commands (like dir or echo) seem to
semi-ignore it while others (cd) seem to be almost short-circuited by it.

IMO, cmd.exe's handling of '.' in these scenarios is strange enough that
it's best to just not bother with it in make, as Eli has maintained.
Otherwise, it seems like we'd potentially be spending a lot of time
tweaking corner cases or discovering that different versions of
cmd.exe/command.com behave differently.

cgf