Re: LINENO behaviour in sh mode

[Martijn Dekker <martijn@inlv.org>]

Op 23-03-17 om 03:45 schreef Bart Schaefer:
> On Mar 20,  3:57am, Martijn Dekker wrote:
> }
> } Output on various shells:
> }             bash: 1 2 5 6 7 6  (?!)
> 
> Clearly bash is incrementing LINENO through the parse of the eval and
> then continuing to increment it through the execution.

Yes. http://lists.gnu.org/archive/html/bug-bash/2017-03/msg00128.html

> I'm mildly surprised that no shell prints "1 2 3 4 5 6".

Well, I can see how that would be non-trivial to pull off.

> }         zsh (sh): 1 2 3 3 3 6  (like ksh88)
> } 
> } Since ksh88 is dead and buried (even Solaris now has ksh93 as their
> } /bin/sh), it looks like zsh's "sh" mode is not emulating any current sh.
> } Maybe 'emulate sh' should no longer turn off the EVAL_LINENO option.
> 
> You're forgetting about the second effect of this, which is to print
> "(eval)" in xtrace output instead of the script or function name.  Try
> your test again with "set -x" ... 

Yes, but how is that a problem? Seems like logical behaviour to me.

If zsh is launched as sh, by default it prints neither of those anyway.

> Do we need a separate option?

Something this minor hardly seems worth a separate option, IMHO.

In any case, for some reason my message took three days to get through
to the list and meanwhile there's an update: mksh has just been patched
to fix the bug where LINENO is always zero for eval or alias expansion.
The only simple way to patch it was to make it act like ksh88, so as of
the next mksh release there will once again be a current shell with a
LINENO that acts like ksh88.

(BTW, Bart, all your messages have been coming through zwh-workers in
duplicate for quite some time now, the second copy always about 2K
larger than the first due to extra routing headers.)

Thanks,

- M.