From: Zoltan Hidvegi <hzoli@cs.elte.hu>
To: schaefer@nbn.com
Cc: clive@epos.demon.co.uk, mdb@cdc.noaa.gov, zsh-workers@math.gatech.edu
Subject: Re: zsh.texi commentary (actually, HTML pages commentary)
Date: Fri, 21 Jun 1996 14:15:26 +0200 (MET DST) [thread overview]
Message-ID: <199606211215.OAA01436@bolyai.cs.elte.hu> (raw)
In-Reply-To: <960621003054.ZM3580@candle.brasslantern.com> from Bart Schaefer at "Jun 21, 96 00:30:52 am"
> 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
next prev parent reply other threads:[~1996-06-21 12:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199606192106.XAA09696@bolyai.cs.elte.hu>
1996-06-19 23:42 ` zsh-2.6-beta21 released Clive Messer
1996-06-20 21:03 ` Mark Borges
1996-06-20 21:05 ` Zoltan Hidvegi
1996-06-21 7:30 ` zsh.texi commentary (actually, HTML pages commentary) Bart Schaefer
1996-06-21 8:06 ` Zefram
1996-06-21 12:15 ` Zoltan Hidvegi [this message]
1996-06-21 12:30 ` Clive Messer
1996-06-21 12:52 ` Zoltan Hidvegi
1996-06-21 15:55 ` Bart Schaefer
1996-06-21 16:59 ` Zefram
1996-06-21 17:22 ` Clive Messer
1996-06-21 17:32 ` Mark Borges
1996-06-21 17:45 ` Mark Borges
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199606211215.OAA01436@bolyai.cs.elte.hu \
--to=hzoli@cs.elte.hu \
--cc=clive@epos.demon.co.uk \
--cc=mdb@cdc.noaa.gov \
--cc=schaefer@nbn.com \
--cc=zsh-workers@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).