options shenanigans in pre4

options shenanigans in pre4

[Zefram]

I'm not going to provide actual patches for any of the things I point
out as needing fixing here.  They're all very minor issues, and the
patches are trivial.

The pre4 patch says:
[Doc/zshexpn.man]
>+ preceding the set of five substitutions mentioned above.
>+ is
>  .SH FILENAME EXPANSION

Where did that "is" come from?  It's obviously a typo, and should be
removed.

[Doc/zshoptions.man]
>! \fBSHIN_STDIN\fP (\-\fBs\fP, ksh: \-\fBs\fP)
>--- 467,473 ----
>! \fBSHIN_STDIN\fP (\-\fBs\fP)

{setopt ramble localoptions
Hmm, I didn't notice that ksh handled this differently from sh.  Maybe
we *do* need a third set of option letters, though this seems to be the
only actual incompatibility.  We might want to implement the ksh option
at some point too.
}

>+ \fBSH_OPTION_LETTERS\fP
>+ If this option is set the shell tries to interpret single letter options
>+ (which are used with \fBset\fP and \fBsetopt\fP) like \fIksh\fP does.
>+ This also affects the value of the \fB-\fP special parameter.

Virtually identical to a patch I was planning to produce after the pre4
release.  I was going to call it KSH_OPTION_LETTERS, though, because
the set of options it selects are emulating ksh, not sh.  The other
option names that refer to ksh or sh do get the right one, so you might
actually want to change this.

>+ .BR sh / ksh
>+ emulation set:
...
>+ \-\fBs\fP SHIN_STDIN

Should not now be included in this list.

[Src/builtin.c]
>!     emulate(*argv, ops['R']);

Once again we have exactly the same idea.

-zefram

Re: options shenanigans in pre4

[Zefram]

>>+ \-\fBs\fP SHIN_STDIN
>
>Should not now be included in this list.

...and -t should.  I missed that one.

-zefram

Re: options shenanigans in pre4

[Zoltan Hidvegi]

> >+ preceding the set of five substitutions mentioned above.
> >+ is
> >  .SH FILENAME EXPANSION
> 
> Where did that "is" come from?  It's obviously a typo, and should be
> removed.

I just applied your patch and replaced SH_FILE_SUBST with SH_FILE_EXPN.
Either it was already in the patch or I accidently pressed some keys.

> [Doc/zshoptions.man]
> >! \fBSHIN_STDIN\fP (\-\fBs\fP, ksh: \-\fBs\fP)
> >--- 467,473 ----
> >! \fBSHIN_STDIN\fP (\-\fBs\fP)
> 
> {setopt ramble localoptions
> Hmm, I didn't notice that ksh handled this differently from sh.  Maybe
> we *do* need a third set of option letters, though this seems to be the
> only actual incompatibility.  We might want to implement the ksh option
> at some point too.
> }

I would not like that.  I've just checked pdksh which interprets -s as
SH_IN_STDIN unlike ksh93 which sorts the positional parameters.  POSIX does
not requires -s.  It seems that the majority of the shells interpret -s as
shinstdin.  Perhaps the best is to bring it back even if it increases the
risk of misusing it.

> >+ \fBSH_OPTION_LETTERS\fP

> Virtually identical to a patch I was planning to produce after the pre4
> release.  I was going to call it KSH_OPTION_LETTERS, though, because
> the set of options it selects are emulating ksh, not sh.  The other

I'd rather say pdksh.  Neither bash nor ksh93 know about -X and -l, but
both know all of the other sh options in zsh only they interpret -s in a
different way.  pdksh knows both -X and -l but -s behaves as in bash (and
as in the Solaris 2.4 /bin/sh).  This means that the most precise option
name would be PDKSH_OPTION_LETTERS :-) but the next best match is
SH_OPTION_LETTERS if we restore -s as shinstdin.

Zoltan

Re: options shenanigans in pre4

[Zefram]

>> Where did that "is" come from?  It's obviously a typo, and should be
>> removed.
>
>I just applied your patch and replaced SH_FILE_SUBST with SH_FILE_EXPN.
>Either it was already in the patch or I accidently pressed some keys.

I've checked; it was already in the patch.  It's a typo on my part.

>I would not like that.  I've just checked pdksh which interprets -s as
>SH_IN_STDIN unlike ksh93 which sorts the positional parameters.  POSIX does
>not requires -s.  It seems that the majority of the shells interpret -s as
>shinstdin.  Perhaps the best is to bring it back even if it increases the
>risk of misusing it.

I based the ksh option set on pdksh, not realising the
incompatibility.  As both sh and pdksh handle -s the way zsh does, I
think it would be better to use -s for SHIN_STDIN.  We should then
remove -t, if we're going to be consistent.

>I'd rather say pdksh.  Neither bash nor ksh93 know about -X and -l, but
>both know all of the other sh options in zsh only they interpret -s in a
>different way.  pdksh knows both -X and -l but -s behaves as in bash (and
>as in the Solaris 2.4 /bin/sh).  This means that the most precise option
>name would be PDKSH_OPTION_LETTERS :-) but the next best match is
>SH_OPTION_LETTERS if we restore -s as shinstdin.

OK, SH_OPTION_LETTERS seems fine in that case.

On a related matter, I suggest you re-examine the status of -1 and -C
(PRINT_EXIT_VALUE and NO_CLOBBER).  In pre4, -C returned to being
PRINT_EXIT_VALUE in the zsh option set, though zshoptions(1) claims
that -C is always NO_CLOBBER.  If this is due to me having merged the
change into my option patch incorrectly, I apologise.  Either the
documentation or the code needs to change, and I suggest that changing
the documentation would be preferable (as -C has traditionally been
PRINT_EXIT_VALUE in zsh, and it's NO_CLOBBER in the ksh option set
anyway).

-zefram

Re: options shenanigans in pre4

[Zoltan Hidvegi]

> On a related matter, I suggest you re-examine the status of -1 and -C
> (PRINT_EXIT_VALUE and NO_CLOBBER).  In pre4, -C returned to being
> PRINT_EXIT_VALUE in the zsh option set, though zshoptions(1) claims

Oops, I confess I did not notice that.

> that -C is always NO_CLOBBER.  If this is due to me having merged the
> change into my option patch incorrectly, I apologise.  Either the

Yes it is.

> documentation or the code needs to change, and I suggest that changing
> the documentation would be preferable (as -C has traditionally been
> PRINT_EXIT_VALUE in zsh, and it's NO_CLOBBER in the ksh option set
> anyway).

But I do not like this ambiguity.  I do not think that many people used -C
for PRINT_EXIT_VALUE.  It just creates confusion when a bash-junkie tries
set -C than accidently looses /etc/passwd because he forgot a >.

Zoltan