Re: zsh-3.0-pre4 released

Re: zsh-3.0-pre4 released

[Bart Schaefer]

On Jul 27,  4:06am, Zoltan Hidvegi wrote:
} Subject: zsh-3.0-pre4 released
}
} -----BEGIN PGP SIGNED MESSAGE-----
} 
} Besides the many bugfixes in this release the biggest change is in this
} release is in trap handling.

Actually, I'd say the biggest change is "setopt nofoo" == "unsetopt foo".
Which I still think should have been left out until some post-3.0 version.
However, if it's staying, then this:

+ The following options are set if the shell is invoked as \fIsh\fP or
+ \fIksh\fP:
+ .BR NO_BAD_PATTERN ,
+ .BR NO_BANG_HIST ,
+ .BR NO_EQUALS ,
+ .BR NO_FUNCTION_ARGZERO ,
+ .BR GLOB_SUBST ,
+ .BR NO_HUP ,
+ .BR INTERACTIVE_COMMENTS ,
+ .BR KSH_ARRAYS ,
+ .BR NO_MULTIOS ,
+ .BR NO_NOMATCH ,
+ .BR RM_STAR_SILENT ,
+ .BR SH_FILE_EXPN ,
+ .BR SH_GLOB ,
+ .BR SH_OPTION_LETTERS ,

Should probably change to this:

+ The following options are set if the shell is invoked as \fIsh\fP or
+ \fIksh\fP:
+ .BR GLOB_SUBST ,
+ .BR INTERACTIVE_COMMENTS ,
+ .BR KSH_ARRAYS ,
+ .BR RM_STAR_SILENT ,
+ .BR SH_FILE_EXPN ,
+ .BR SH_GLOB ,
+ .BR SH_OPTION_LETTERS ,
+ .BR SH_WORD_SPLIT .
+ The following options are not set if the shell is invoked as \fIsh\fP
+ or \fIksh\fP:
+ .BR BAD_PATTERN ,
+ .BR BANG_HIST ,
+ .BR EQUALS ,
+ .BR FUNCTION_ARGZERO ,
+ .BR HUP ,
+ .BR MULTIOS ,
+ .BR NOMATCH .

I must say, having an option called BAD_PATTERN feels rather odd to me.
Since we have IGNORE_BRACES, either we should have IGNORE_BAD_PATTERN,
or else we should have just BRACES.  Or it should have been left alone.

And then there's HIST_NO_STORE (why not HIST_STORE?), HIST_IGNORE_DUPS,
HIST_IGNORE_SPACE and PUSHD_IGNORE_DUPS.  Why "fix" only the ones that
happen to begin with "NO"?  If we're making all the options have a
"positive" sense, then let's do it right, otherwise don't do it.

I think the hobgoblins have introduced a foolish consistency here.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: zsh-3.0-pre4 released

[Zefram]

>Actually, I'd say the biggest change is "setopt nofoo" == "unsetopt foo".
>Which I still think should have been left out until some post-3.0 version.

Why?  It breaks nothing except for scripts that try to detect options
being set by doing `setopt | grep foo`, which is broken anyway.  The
old names still work in [[ -o nofoo ]].

>I must say, having an option called BAD_PATTERN feels rather odd to me.
>Since we have IGNORE_BRACES, either we should have IGNORE_BAD_PATTERN,
>or else we should have just BRACES.  Or it should have been left alone.
[more like this]

Yes, I thought so too.  However, a "no" prefix is the prevalent way of
negating option sense, so I added support for that only.  To change
IGNORE_BRACES to NO_BRACES (i.e. a negated BRACES) would break backward
compatibility, unless there is some way to support the old name.

I do plan to write a patch to add exactly such a mechanism.  As it will
no doubt be somewhat controversial, I'll describe it now for people to
tear apart:

The general idea is that we have a list of fixed option `aliases',
which provide alternative names for certain options.  The list itself
would look something like

    {"ignorebraces", -BRACES},
    {"trackall", HASHCMDS},

The "trackall" entry provides a ksh name for the equivalent zsh
option.  The "ignorebraces" entry provides backward compatibility, in
the hypothetical situation that we decide that "braces" is a better
name.  I wouldn't make that type of change when adding the mechanism,
but would only do some ksh compatibility names.

The aliased names would be handled by optlookup(), with essentially no
changes required anywhere else.  In fact, I'd probably make the list
itself local to optlookup().  This flexibility, to add new types of
option name, is one of the reasons I added the optlookup()
abstraction.

I'd like to know what people think of this idea.  In particular,
Zoltan, would you allow such a patch into the baseline?

-zefram

Re: zsh-3.0-pre4 released

[Bart Schaefer]

On Jul 27,  6:03pm, Zefram wrote:
} Subject: Re: zsh-3.0-pre4 released
}
} >Actually, I'd say the biggest change is "setopt nofoo" == "unsetopt foo".
} >Which I still think should have been left out until some post-3.0 version.
} 
} Why?  It breaks nothing except for scripts that try to detect options
} being set by doing `setopt | grep foo`, which is broken anyway.

It also breaks the setopt/unsetopt wrapper functions I sent a few days ago,
but I don't consider that important.

What I do consider important is the confusion from the introduction of a
large number of new options -- which is what it looks like to anyone who
simply glances at the output of "setopt"; and which it is, syntactically
at least, although less so semantically.

Further, although I'm extremely happy about the attention that was paid
to backwards compatibility, I can only repeat how uncomfortable I am
about options that end up named BAD_PATTERN, EQUALS, EXEC, HUP, RCS, and
UNSET.  What does "setopt unset" look like to you?  Why shouldn't "nohup"
parallel the command prefix of the same name?  Even BEEP is a bit vexing.
At least with the NO_ prefix, you could tell that there is some expected
behavior that is being modified.

It's my opinion that, with the exception of options that reflect shell
state (such as "interactive" and "shinstdin"), the baseline expected
behavior of the shell should be the behavior with all options UNset.
That's why they're called "options" after all; because they introduce
optional behavior, different from the baseline.

Please note that I don't object much to the "setopt no..." == "unsetopt"
behavior.  It's the renaming of a number of the NO_ options that bothers
me.  I'd be perfectly happy to have "setopt NO_NO_RCS" be a valid way to
"unsetopt NO_RCS", but I don't want to "setopt RCS", and I don't like to
have "rcs" showing up in my setopt output.

BTW, while I'm on the subject, I'd like to throw in my vote for changing
SH_FILE_EXPN to KSH_FILE_EXPANSION.  Besides being, as Zefram pointed out,
more a ksh than sh thing, spelling out the "expansion" is no longer than
ALWAYS_LAST_PROMPT, and I think we should avoid unnecessary abbreviations.
("What does the Revision Control System have to do with my init files?")

} The general idea is that we have a list of fixed option `aliases',
} which provide alternative names for certain options.  The list itself
} would look something like
} 
}     {"ignorebraces", -BRACES},
}     {"trackall", HASHCMDS},
} 
} The "trackall" entry provides a ksh name for the equivalent zsh
} option.  The "ignorebraces" entry provides backward compatibility, in
} the hypothetical situation that we decide that "braces" is a better
} name.  I wouldn't make that type of change when adding the mechanism,
} but would only do some ksh compatibility names.

Now THIS I could support, because it would permit us to rename some of
the options without losing backwards compatibility and without having
to invert their default boolean sense.  I'd vote for renaming at least
these six:

braceccl            (what's a CCL, anyway?)
histnostore
nobadpattern
nobanghist
norcs               (IGNORE_RC_FILES, perhaps?)
nounset             (NULL_UNSET, ala NULL_GLOB?)

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: zsh-3.0-pre4 released

[Zefram]

>What I do consider important is the confusion from the introduction of a
>large number of new options -- which is what it looks like to anyone who
>simply glances at the output of "setopt"; and which it is, syntactically
>at least, although less so semantically.

I've been using the `new options' (slightly) longer than anyone else
(how's that for brag value :-)), and while I agree that it is initially
a little disconcerting, I find that I prefer the cleaner setopt
output.  I also find that the testing of options is a little clearer in
general, in the code.  (The option patch actually normalised all option
tests to either isset(FOO) or unset(FOO).)

>Further, although I'm extremely happy about the attention that was paid
>to backwards compatibility, I can only repeat how uncomfortable I am
>about options that end up named BAD_PATTERN, EQUALS, EXEC, HUP, RCS, and
>UNSET.  What does "setopt unset" look like to you?

Confusing.  However, I do prefer unset(UNSET) to isset(NOUNSET).

>                                                    Why shouldn't "nohup"
>parallel the command prefix of the same name?

It does.

>At least with the NO_ prefix, you could tell that there is some expected
>behavior that is being modified.

True, that's how the options used to work, but what is the "expected
behaviour"?  It varies depending on whether we're emulating sh, ksh,
csh, zsh, (when we get round to it) POSIX, or whatever.  Not to mention
that not even all the non-special options defaulted to off anyway,
IIRC.

>BTW, while I'm on the subject, I'd like to throw in my vote for changing
>SH_FILE_EXPN to KSH_FILE_EXPANSION.  Besides being, as Zefram pointed out,
>more a ksh than sh thing, spelling out the "expansion" is no longer than
>ALWAYS_LAST_PROMPT, and I think we should avoid unnecessary abbreviations.

Partially agreed.  When I produced that patch I used SH_FILE_SUBST, in
order to avoid excessive length but also avoid a cryptic abbreviation;
I guess a full "expansion" is fine.  But whether it's sh or ksh makes
little difference, as both behave the same way in this regard.

>("What does the Revision Control System have to do with my init files?")

That one had me stumped for a while.

>braceccl            (what's a CCL, anyway?)

Character CLass?  I think this one needs changing; how about
BRACE_CHARS?  Does anyone have a better idea?

>histnostore

Should be HIST_STORE.

>nobadpattern

BAD_PATTERN currently means "complain about malformed patterns".  I
can't immediately come up with a better name.

>nobanghist

Again, I don't see a better name.  There's history regardless of this
option -- it only enables the bangchar form.  (Admittedly not always a
!, but how else can one describe this?)

>norcs               (IGNORE_RC_FILES, perhaps?)

RC_FILES, meaning what RCS currently does.

>nounset             (NULL_UNSET, ala NULL_GLOB?)

Yes, NULL_UNSET is much clearer.  Currently we have UNSET meaning
"complain about unset parameters", and its negation isn't exactly
obvious.

Other possibilities: EXTENDED_GLOB should be ZSH_GLOB; RM_STAR_SILENT
should be negated to RM_STAR_WARNING (note that changing the default
behaviour is a separate issue); SHIN_STDIN should be STDIN or something
less cryptic; HIST_ALLOW_CLOBBER should be HIST_ADD_CLOBBER (that's
what it does); IGNORE_BRACES has already been discussed; NOMATCH should
be clearer; RC_EXPAND_PARAM arguably should be RC_ARRAYS; REC_EXACT
should be RECOGNISE_EXACT or ACCEPT_EXACT_MATCH or similar.

-zefram

Re: zsh-3.0-pre4 released

[Bart Schaefer]

On Jul 27,  9:02pm, Zefram wrote:
} Subject: Re: zsh-3.0-pre4 released
}
} I've been using the `new options' (slightly) longer than anyone else
} (how's that for brag value :-)), and while I agree that it is initially
} a little disconcerting, I find that I prefer the cleaner setopt output.

Cleaner?  Like I said, the baseline behavior should be what happens when
all the options are unset.  The cleanest output is none at all.

} I also find that the testing of options is a little clearer in
} general, in the code.  (The option patch actually normalised all option
} tests to either isset(FOO) or unset(FOO).)
} 
} I do prefer unset(UNSET) to isset(NOUNSET).

There's nothing that requires us to use NOUNSET in the code.  You yourself
used EXECOPT instead of EXEC, for example (and for obvious reasons).

} >                                                    Why shouldn't "nohup"
} >parallel the command prefix of the same name?
} 
} It does.

"setopt nohup" parallels it, but the output of "setopt" doesn't say "nohup".

} >At least with the NO_ prefix, you could tell that there is some expected
} >behavior that is being modified.
} 
} True, that's how the options used to work, but what is the "expected
} behaviour"?  It varies depending on whether we're emulating sh, ksh,
} csh, zsh, (when we get round to it) POSIX, or whatever.

The "expected behavior" is what you get when you run "./zsh" out of
the build directory on a machine that's never had zsh near it before.

Emulations are just that; they're by definition not baseline behavior
(unless what you're writing is nothing more than an emulator).

] Not to mention
} that not even all the non-special options defaulted to off anyway

The only ones that didn't are FUNCTION_ARGZERO, which is new; BG_NICE,
which has always annoyed me anyway (and which originally didn't default
that way, if I recall correctly); and the three HASH options, which
don't change any user-visible behavior, only performance tradeoffs.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: zsh-3.0-pre4 released

[Zoltan Hidvegi]

> } Besides the many bugfixes in this release the biggest change is in this
> } release is in trap handling.
> 
> Actually, I'd say the biggest change is "setopt nofoo" == "unsetopt foo".
> Which I still think should have been left out until some post-3.0 version.

This may seem to be a big change but in the code it is not really a big
change and it really cleans up the code.  The trap change is much more
complicated with much more `traps' which may result in memory leaks and
other nasty things.

Zoltan

Re: zsh-3.0-pre4 released

[Clive Messer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 376 bytes --]

On Sat, 27 Jul 1996, Zoltan Hidvegi wrote:

> The texinfo manual is almost up-to-date, but again, it does not contains
> the changes since zsh-3.0-pre3.


Attatched patch updates zsh.texi.

Clive.
-- 
C Messer. Epos Systems. UK.  |
<clive@epos.demon.co.uk>     |   "I pressed her thigh and death smiled."
<clive@epos.easynet.co.uk>   |    Jim Morrison.                       

[-- Attachment #2: zsh.texi.diff.pre4-2.1.4.gz --]
[-- Type: APPLICATION/octet-stream, Size: 12814 bytes --]

Re: zsh-3.0-pre4 released

[Clive Messer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 534 bytes --]

On Tue, 30 Jul 1996, Clive Messer wrote:

> On Sat, 27 Jul 1996, Zoltan Hidvegi wrote:
> 
> > The texinfo manual is almost up-to-date, but again, it does not contains
> > the changes since zsh-3.0-pre3.
> 
> 
> Attatched patch updates zsh.texi.

Oops!! I forgot to FIX a couple of references.
This little patch needs to be applied after the last.

Clive.
-- 
C Messer. Epos Systems. UK.  |
<clive@epos.demon.co.uk>     |   "I pressed her thigh and death smiled."
<clive@epos.easynet.co.uk>   |    Jim Morrison.                       

[-- Attachment #2: zsh.texi.diff-2.1.4-5.gz --]
[-- Type: APPLICATION/octet-stream, Size: 935 bytes --]

Re: zsh-3.0-pre4 released

[Zoltan Hidvegi]

> misleading.  E.g. from the FAQ:

You mean from the NEWS.

> ! Traps defined by the trap builtin are now executed in the current shell
> ! environment and not as a shell function.  This means that $1 is not set
> ! to the signal number.  Of course the TRAPxxx functions continue working
> ! as before.
> 
> This sounds as though TRAPFOO() continues to fire ("functions continue
> working") even after `trap bar foo`; sort of as if TRAPxxx() and "trap"
> are now in completely separate "namespaces".

Perhaps my wording was not the best.  Any improvements are welcome.

Zoltan

Re: zsh-3.0-pre4 released

[Bart Schaefer]

On Jul 27,  5:55pm, Zoltan Hidvegi wrote:
} Subject: Re: zsh-3.0-pre4 released
}
} > 	TRAPHUP() { echo Hangup }
} > 	trap "echo Hang UP" 1
} > 	
} > causes an implicit "unfunction TRAPHUP"
} > 
} > 	trap "echo Hangup" 1
} > 	TRAPHUP() { echo Hang UP }
} > 
} > causes an implicit "trap - 1"
} 
} Yes or course.  That's quite similar to the old behaviour.

OK, that's very good; but I think the documentation of this is a bit
misleading.  E.g. from the FAQ:

! Traps defined by the trap builtin are now executed in the current shell
! environment and not as a shell function.  This means that $1 is not set
! to the signal number.  Of course the TRAPxxx functions continue working
! as before.

This sounds as though TRAPFOO() continues to fire ("functions continue
working") even after `trap bar foo`; sort of as if TRAPxxx() and "trap"
are now in completely separate "namespaces".

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: zsh-3.0-pre4 released

[Zoltan Hidvegi]

> Hmm ... you seem to be saying that
> 
> 	TRAPHUP() { echo Hangup }
> 	trap "echo Hang UP" 1
> 	
> causes an implicit "unfunction TRAPHUP".  What, then, happens if
> 
> 	trap "echo Hangup" 1
> 	TRAPHUP() { echo Hang UP }
> 
> ??  Does the TRAPHUP definition cause an implicit "trap - 1"?

Yes or course.  That's quite similar to the old behaviour.

Zoltan

Re: zsh-3.0-pre4 released

[Bart Schaefer]

On Jul 27,  4:06am, Zoltan Hidvegi wrote:
} Subject: zsh-3.0-pre4 released
}
} Traps defined by a TRAPxxx function work as
} before.  TRAPxxx functions are undefined if the trap builtin is used to
} modify the corresponding trap.

Hmm ... you seem to be saying that

	TRAPHUP() { echo Hangup }
	trap "echo Hang UP" 1
	
causes an implicit "unfunction TRAPHUP".  What, then, happens if

	trap "echo Hangup" 1
	TRAPHUP() { echo Hang UP }

??  Does the TRAPHUP definition cause an implicit "trap - 1"?  Or do both
traps fire?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"