From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id WAA18777 for ; Fri, 21 Jun 1996 22:31:22 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id IAA27943; Fri, 21 Jun 1996 08:16:12 -0400 (EDT) Resent-Date: Fri, 21 Jun 1996 08:16:12 -0400 (EDT) From: Zoltan Hidvegi Message-Id: <199606211215.OAA01436@bolyai.cs.elte.hu> Subject: Re: zsh.texi commentary (actually, HTML pages commentary) To: schaefer@nbn.com Date: Fri, 21 Jun 1996 14:15:26 +0200 (MET DST) Cc: clive@epos.demon.co.uk, mdb@cdc.noaa.gov, zsh-workers@math.gatech.edu In-Reply-To: <960621003054.ZM3580@candle.brasslantern.com> from Bart Schaefer at "Jun 21, 96 00:30:52 am" Organization: Dept. of Comp. Sci., Eotvos University, Budapest, Hungary Phone: (36 1)2669833 ext: 2667, home phone: (36 1) 2752368 X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Hi0LK2.0.Xq6.CAfon"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1397 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > For the rest of these comments, I don't know which need to change the > man pages, the FAQ, zsh.texi, and/or all of them; but they're all from > reading the HTML at the above URL. Undoubtadly there are things in the manual which is not very clear. Any patches are welcome. > Aside: Question about NO_RCS: > Commands are first read from `/etc/zshenv'. If the -f flag is > given or if the NO_RCS option is set within `/etc/zshenv', all > other initialization files are skipped. > Why doesn't NO_RCS in any init file stop reading of any files that would > normally follow the one where it is set? Or does it, and the doc just > doesn't explicitly say so? No, the documentation is correct. > Shell Grammar section: > > A simple command is a sequence of optional parameter assignments > followed by blank-separated words, > ^^^^^ > Should this read "whitespace" or some such? (Too early to mention $IFS.) IFS is not used for that. I think that blank and whitespace are synonyms. whitespace may also include newline which cannot be used here. > Aside: What's the value of a command executed in the background? E.g. > if false & then echo Hmmm & fi > Is it always consistent? Backgrounded commands always have 0 exit status (that is explicitely mentioned in POSIX 1003.2). > Precommand modifiers, `exec', should explain that the "parent" zsh is > replaced by the exec'd command, as if zsh had exited and the command > was run in its place. Also these are builins now, which is not yet documented. > Aside: Why doesn't `foreach name ( word ... )' need CSH_JUNKIE_PARENS? foreach is a csh command and in csh that is the only way it works as I know. When someone uses foreach he is a already a csh junkie and the shell knows that. > Aside: That it is possible to `disable -r fi' without first disabling > `if', scares the willies out of me. Simliarly for `done' and `esac'. Yes, disable -r should be use very carefully. But I do not think that any change is necessary here. > Aside: Given the above behavior of `disable -r', it'd be nice to be able > to get at the internal tokens for the disabled reserved words. E.g.: > foo() { if true ; then echo This function keeps working ; fi } > alias endif=fi > disable -r fi > bar() { if true ; then echo I wish this still worked ; endif } > Maybe an option to the alias builtin? Aliases realy modify the input to the lexer. I do not think that such a feature is necessary. > The paragraph on Comments still refers to HISTCHARS; it's now histchars. Perhaps I should have mentioned it: I put back HISTCHARS and now both histchars and HISTCHARS can be used. But HISTCHARS is disabled in sh/ksh mode. > Only the "expression" part of identifier=expression is expanded, right? Identifier is also expanded but it contains only letters, numbers and underscore so there is nothing to expand. I think that's clear. > The following statement is false for ${name:#pattern}, is it not? > If the colon is omitted from one of the above expressions > containing a colon, then the shell only checks whether name > is set or not, not whether it is null. Yes, but there the form without a colon is also documented. > There's something odd here: > Arithmetic Expansion > > A string of the form $[exp] is substituted with the value of > the arithmetic expression exp. exp is subjected to parameter > expansion, command substitution and arithmetic expansion before > ^^^^^^^^^^^^^^^^^^^^^^^^ > it is evaluated. See section Arithmetic Evaluation. > Is this wrong, or is it just a goofy way of saying that $[exp] can be > nested? (Which doesn't seem to be true, so that's not it.) It should be possible to nest arithmentic exansions. Unfortunately $[$[...]] does not work, that's a bug, I'll fix it. But $[$((...))] works. > Why isn't ***/ mentioned anywhere? That's like **/ except it follows > symlinks, correct? It is documented in the manual. Zoltan