From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Zefram <A.Main@dcs.warwick.ac.uk>,
Zoltan Hidvegi <hzoli@cs.elte.hu>,
clive@epos.demon.co.uk
Cc: mdb@cdc.noaa.gov,
zsh-workers@math.gatech.edu (Z Shell workers mailing list)
Subject: Re: zsh.texi commentary (actually, HTML pages commentary)
Date: Fri, 21 Jun 1996 08:55:54 -0700 [thread overview]
Message-ID: <960621085558.ZM4927@candle.brasslantern.com> (raw)
In-Reply-To: Zefram <A.Main@dcs.warwick.ac.uk> "Re: zsh.texi commentary (actually, HTML pages commentary)" (Jun 21, 9:06am)
In-Reply-To: Zoltan Hidvegi <hzoli@cs.elte.hu> "Re: zsh.texi commentary (actually, HTML pages commentary)" (Jun 21, 2:15pm)
In-Reply-To: Zoltan Hidvegi <hzoli@cs.elte.hu> "Re: zsh.texi commentary (actually, HTML pages commentary)" (Jun 21, 2:52pm)
On Jun 21, 9:06am, Zefram wrote:
} Subject: Re: zsh.texi commentary (actually, HTML pages commentary)
}
} > What the heck happened to NO_NOMATCH when the change
} >was made to make the prefix "no" into a magic equivalent of "unsetopt"?
}
} That patch isn't in the baseline yet. It made the canonical form of
} that option NOMATCH, so that "setopt NOMATCH", "unsetopt NOMATCH",
} "setopt NO_NOMATCH" and "unsetopt NO_NOMATCH" are valid.
So you check for canonical forms before stripping off the leading "no",
and then check again after stripping it to invert the sense? Or what?
On Jun 21, 2:15pm, Zoltan Hidvegi wrote:
} Subject: Re: zsh.texi commentary (actually, HTML pages commentary)
}
} > 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.
So then, answer the "Why?" part of the question.
} > 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.
Exactly what difference does that make? (Which is part of what ought to
be documented ...)
} > 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.
Yes, I know. I was suggesting, for lack of a better idea, that there be
a magic form of lexer input that could force a reference to a disabled
reserved word. Anybody have a better idea? It's obviously possible,
because functions that were tokenized before the disable still work.
} I do not think that such a feature is necessary.
Whatever; it was just a suggestion.
} > 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.
Shouldn't $((...)) be mentioned in the Arithmetic Expansion discussion?
Or is it different in some subtle way?
} > Why isn't ***/ mentioned anywhere? That's like **/ except it follows
} > symlinks, correct?
}
} It is documented in the manual.
I know, but it isn't mentioned in the Filename Generation discussion of
the .texi, and I think it should be.
On Jun 21, 2:52pm, Zoltan Hidvegi wrote:
} Subject: Re: zsh.texi commentary (actually, HTML pages commentary)
}
} But these changes should also be made in the manual. Any voulnteers to
} clean up the manual? The texinfo and the nroff documentation should be
} updated paralelly. The manual also needs spell checking. I'm quite busy
} and I think I'm not the best in correcting sylistic problems in English.
I couldn't promise to have time, unfortunately.
--
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"
next prev parent reply other threads:[~1996-06-21 16:10 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
1996-06-21 12:30 ` Clive Messer
1996-06-21 12:52 ` Zoltan Hidvegi
1996-06-21 15:55 ` Bart Schaefer [this message]
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=960621085558.ZM4927@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=A.Main@dcs.warwick.ac.uk \
--cc=clive@epos.demon.co.uk \
--cc=hzoli@cs.elte.hu \
--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).