PATCH: zsh-3.1.5-pws-20: emulate/su saga continues

[Peter Stephenson <pws@ibmth.df.unipi.it>]

(This somehow got stuck on math.gatech.edu for some reason.  It's quite
possible the original will appear again from there.)

"Bart Schaefer" wrote:
> On May 16,  5:55pm, Arnon Kanfi wrote:
> } Subject: zsh bug
> }
> } I have discovered a bug in zsh 3.1.4 when used on SunOs. when doing an "su"
> } zsh will not read any of the global RC files. After tracking the problem I
> } have found out that su on SunOs 4.1.4 sets argv[0] to "-su" which causes zs
> h
> } to do "sh" emulation and not read the RC files.
> 
> There was also a discussion on this in zsh-workers/4120 and follow-ups,
> including a patch that I sent in 4127.

I must have missed this because the search got too big.  I'm hopeless with
technology.

> On May 19, 10:57am, Peter Stephenson wrote:
> } Subject: PATCH: 3.1.5-pws-18: Re: zsh bug, again
> }
> } Arnon pointed out you might as well use $SHELL to find out what's what,
> } since su probably did to get the shell in the first place.  So this does
> } that.
> 
> That's what my patch in 4127 does, too.

I've now backed off 6299 and 6313 and put 4127 in instead, since this seems
to be the form people want (it's basically equivalent to Arnon's).  The
documentation for this is below; it applies after those three changes.

(Does anyone else think there are far too many quotes in the info version
--- but not the tex version, which looks fine --- of the documentation?  It
seems to be in the definition of @code, but it looks awful when there are
other quotes around.  Have we had this discussion?  I have GNU Makeinfo
(Texinfo 3.9) 1.67 if it makes a difference.)

> Before my disk got trashed, I had a message from Zefram explaining why he
> left my patch out of 3.1.5.  I don't think he liked the idea of having zsh
> compensate for a broken "su".  If you look at zsh-workers/4121, he opines
> that:
> 
>     The original behaviour is correct.  "su" really should not give the
>     shell this weird argv[0] (some versions don't).  But on the older
>     systems where it does, it's more likely that the shell being invoked
>     is supposed to be sh, so treating a name of "su" as "sh" is the best
>     behaviour.

Well, I agree with the middle comment, but it doesn't really help us.  I
don't agree with the last comment; it doesn't seem to me to apply to the
SunOS 4 systems where people have been having this difficulty.
Consequently I don't agree with the first comment either.

If Zefram complains, this could at worst be turned into an
--enable-emulate-su feature, since there's obviously call for it, but I
really can't see the harm in it as it is.

In the patch, I turned an `emulate zsh; setopt localoptions' into the more
memorable `emulate -L zsh'.  There is still the undocumented feature that
emulate just operates on the first letter of its argument ignoring an r,
although it's harmless as long as you use one of the documented arguments

--- Doc/Zsh/compat.yo.suN	Tue Jun  1 15:08:18 1999
+++ Doc/Zsh/compat.yo	Tue Jun  1 15:26:03 1999
@@ -7,7 +7,15 @@
 cindex(sh, compatibility)
 cindex(ksh, compatibility)
 Zsh tries to emulate bf(sh) or bf(ksh) when it is invoked as
-tt(sh) or tt(ksh) respectively.  In this mode the following
+tt(sh) or tt(ksh) respectively; more precisely, it looks at the first
+letter of the name by which it was invoked, excluding any initial `tt(r)'
+(assumed to stand for `restricted'), and if that is `tt(s)' or `tt(k)' it
+will emulate bf(sh) or bf(ksh).  Furthermore, if invoked as tt(su) (which
+happens on certain systems when the shell is executed by the tt(su)
+command), the shell will try to find an alternative name from the tt(SHELL)
+environment variable and perform emulation based on that.
+
+In bf(sh) and bf(ksh) compatibility modes the following
 parameters are not special and not initialized by the shell:
 tt(ARGC),
 tt(argv),
--- Doc/Zsh/options.yo.suN	Tue May 11 17:08:45 1999
+++ Doc/Zsh/options.yo	Tue Jun  1 15:14:37 1999
@@ -568,7 +568,8 @@
 if this is explicitly unset by a shell function the other options in
 force at the point of return will remain so.
 A shell function can also guarantee itself a known shell configuration
-with a formulation like `tt(emulate zsh; setopt localoptions)'.
+with a formulation like `tt(emulate -L zsh)'; the tt(-L) activates
+tt(LOCAL_OPTIONS).
 )
 pindex(LOGIN)
 item(tt(LOGIN) (tt(-l), ksh: tt(-l)))(

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy