zsh-workers
 help / color / mirror / code / Atom feed
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



  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).