LINENO behaviour in sh mode

LINENO behaviour in sh mode

[Martijn Dekker]

Test script:
printf "$LINENO "
printf "$LINENO "
eval '	printf "$LINENO "
	printf "$LINENO "
	printf "$LINENO " '
printf "$LINENO\n"

Output on various shells:
            bash: 1 2 5 6 7 6  (?!)
     {m,l,pd}ksh: 1 2 0 0 0 6  (?)
      AT&T ksh88: 1 2 3 3 3 6
      AT&T ksh93: 1 2 1 2 3 6
      FreeBSD sh: 1 2 1 2 3 6
            dash: 1 2 1 2 3 6
            yash: 1 2 1 2 3 6
    zsh (native): 1 2 1 2 3 6
        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.

- M.

Re: LINENO behaviour in sh mode

[Martijn Dekker]

[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

Op 20-03-17 om 03:57 schreef Martijn Dekker:
> Maybe 'emulate sh' should no longer turn off the EVAL_LINENO option.

Which turns out to be easy to accomplish.

Seems prudent to leave it turned off for ksh mode, as that emulates
ksh88 more than it does ksh93.

- M.


[-- Attachment #2: evallineno-sh.patch --]
[-- Type: text/x-patch, Size: 678 bytes --]

diff --git a/Src/options.c b/Src/options.c
index 2b5795b..5b068b3 100644
--- a/Src/options.c
+++ b/Src/options.c
@@ -131,7 +131,7 @@ static struct optname optns[] = {
 {{NULL, "exec",		      OPT_ALL},			 EXECOPT},
 {{NULL, "extendedglob",	      OPT_EMULATE},		 EXTENDEDGLOB},
 {{NULL, "extendedhistory",    OPT_CSH},			 EXTENDEDHISTORY},
-{{NULL, "evallineno",	      OPT_EMULATE|OPT_ZSH},	 EVALLINENO},
+{{NULL, "evallineno",	      OPT_EMULATE|OPT_SH|OPT_ZSH}, EVALLINENO},
 {{NULL, "flowcontrol",	      OPT_ALL},			 FLOWCONTROL},
 {{NULL, "forcefloat",         0},                        FORCEFLOAT},
 {{NULL, "functionargzero",    OPT_EMULATE|OPT_NONBOURNE},FUNCTIONARGZERO},

Re: LINENO behaviour in sh mode

[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.

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

}         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" ... Do we need a separate option?

Also, how should the doc be updated, given that csh emulation would
become the outlier?

Re: LINENO behaviour in sh mode

[Martijn Dekker]

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.

Re: LINENO behaviour in sh mode

[Bart Schaefer]

On Mar 23,  4:09am, Martijn Dekker wrote:
}
} Op 23-03-17 om 03:45 schreef Bart Schaefer:
} > 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.

Just pointing out that it's another difference that will appear.  It
may not matter but someone might care about their prompt changing etc.

} (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 for letting me know; that means at least some of gmail's SMTP
relays are off the blocklist used by primenet.  Gmail inbox suppresses
duplicates and so apparently does the list archive (do both copies of
what you see have the same X-Seq ?) so I can't see the effect myself.

I'll try this one without the second copy and see what happens.

Duplicate messages (was Re: LINENO behaviour in sh mode)

[Aaron Schrab]

At 09:11 -0700 23 Mar 2017, Bart Schaefer <schaefer@brasslantern.com> wrote:
>} (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 for letting me know; that means at least some of gmail's SMTP
>relays are off the blocklist used by primenet. 

Based on what I'd seen that was always the case. I started seeing dups 
pretty much as soon as that work around was put into place. I'd though 
that was expected, so I just enabled duplicate filtering on my end.

>(do both copies of >what you see have the same X-Seq ?)

No, each copy has its own X-Seq. (I keep copies of all incoming mail 
before any filtering is done.)

>I'll try this one without the second copy and see what happens.

It obviously made it to the list.