* Re: zsh-3.0-pre4 released [not found] <199607270206.EAA04563@hzoli.ppp.cs.elte.hu> @ 1996-07-27 4:30 ` Bart Schaefer 1996-07-27 15:55 ` Zoltan Hidvegi 1996-07-27 4:57 ` Bart Schaefer 1996-07-30 2:22 ` Clive Messer 2 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 1996-07-27 4:30 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: zsh-workers 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" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zsh-3.0-pre4 released 1996-07-27 4:30 ` zsh-3.0-pre4 released Bart Schaefer @ 1996-07-27 15:55 ` Zoltan Hidvegi 1996-07-27 18:35 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Zoltan Hidvegi @ 1996-07-27 15:55 UTC (permalink / raw) To: schaefer; +Cc: zsh-workers > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zsh-3.0-pre4 released 1996-07-27 15:55 ` Zoltan Hidvegi @ 1996-07-27 18:35 ` Bart Schaefer 1996-07-27 22:06 ` Zoltan Hidvegi 0 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 1996-07-27 18:35 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: zsh-workers 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" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zsh-3.0-pre4 released 1996-07-27 18:35 ` Bart Schaefer @ 1996-07-27 22:06 ` Zoltan Hidvegi 0 siblings, 0 replies; 12+ messages in thread From: Zoltan Hidvegi @ 1996-07-27 22:06 UTC (permalink / raw) To: schaefer; +Cc: zsh-workers > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zsh-3.0-pre4 released [not found] <199607270206.EAA04563@hzoli.ppp.cs.elte.hu> 1996-07-27 4:30 ` zsh-3.0-pre4 released Bart Schaefer @ 1996-07-27 4:57 ` Bart Schaefer 1996-07-27 17:03 ` Zefram 1996-07-27 22:27 ` Zoltan Hidvegi 1996-07-30 2:22 ` Clive Messer 2 siblings, 2 replies; 12+ messages in thread From: Bart Schaefer @ 1996-07-27 4:57 UTC (permalink / raw) To: zsh-workers, Zoltan Hidvegi 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" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zsh-3.0-pre4 released 1996-07-27 4:57 ` Bart Schaefer @ 1996-07-27 17:03 ` Zefram 1996-07-27 19:26 ` Bart Schaefer 1996-07-27 22:27 ` Zoltan Hidvegi 1 sibling, 1 reply; 12+ messages in thread From: Zefram @ 1996-07-27 17:03 UTC (permalink / raw) To: schaefer; +Cc: zsh-workers, hzoli >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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zsh-3.0-pre4 released 1996-07-27 17:03 ` Zefram @ 1996-07-27 19:26 ` Bart Schaefer 1996-07-27 20:02 ` Zefram 0 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 1996-07-27 19:26 UTC (permalink / raw) To: Zefram; +Cc: hzoli, zsh-workers 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" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zsh-3.0-pre4 released 1996-07-27 19:26 ` Bart Schaefer @ 1996-07-27 20:02 ` Zefram 1996-07-27 20:38 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Zefram @ 1996-07-27 20:02 UTC (permalink / raw) To: schaefer; +Cc: A.Main, hzoli, zsh-workers >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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zsh-3.0-pre4 released 1996-07-27 20:02 ` Zefram @ 1996-07-27 20:38 ` Bart Schaefer 0 siblings, 0 replies; 12+ messages in thread From: Bart Schaefer @ 1996-07-27 20:38 UTC (permalink / raw) To: Zefram; +Cc: zsh-workers 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" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zsh-3.0-pre4 released 1996-07-27 4:57 ` Bart Schaefer 1996-07-27 17:03 ` Zefram @ 1996-07-27 22:27 ` Zoltan Hidvegi 1 sibling, 0 replies; 12+ messages in thread From: Zoltan Hidvegi @ 1996-07-27 22:27 UTC (permalink / raw) To: schaefer; +Cc: zsh-workers > } 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zsh-3.0-pre4 released [not found] <199607270206.EAA04563@hzoli.ppp.cs.elte.hu> 1996-07-27 4:30 ` zsh-3.0-pre4 released Bart Schaefer 1996-07-27 4:57 ` Bart Schaefer @ 1996-07-30 2:22 ` Clive Messer 1996-07-30 12:18 ` Clive Messer 2 siblings, 1 reply; 12+ messages in thread From: Clive Messer @ 1996-07-30 2:22 UTC (permalink / raw) To: zsh-workers; +Cc: Mark Borges [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zsh-3.0-pre4 released 1996-07-30 2:22 ` Clive Messer @ 1996-07-30 12:18 ` Clive Messer 0 siblings, 0 replies; 12+ messages in thread From: Clive Messer @ 1996-07-30 12:18 UTC (permalink / raw) To: zsh-workers; +Cc: Mark Borges [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1996-07-30 12:29 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <199607270206.EAA04563@hzoli.ppp.cs.elte.hu> 1996-07-27 4:30 ` zsh-3.0-pre4 released Bart Schaefer 1996-07-27 15:55 ` Zoltan Hidvegi 1996-07-27 18:35 ` Bart Schaefer 1996-07-27 22:06 ` Zoltan Hidvegi 1996-07-27 4:57 ` Bart Schaefer 1996-07-27 17:03 ` Zefram 1996-07-27 19:26 ` Bart Schaefer 1996-07-27 20:02 ` Zefram 1996-07-27 20:38 ` Bart Schaefer 1996-07-27 22:27 ` Zoltan Hidvegi 1996-07-30 2:22 ` Clive Messer 1996-07-30 12:18 ` Clive Messer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).