From: Zefram <zefram@fysh.org>
To: schaefer@candle.brasslantern.com (Bart Schaefer)
Cc: zefram@fysh.org, zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: emulate (Re: Prompt fun)
Date: Thu, 7 Oct 1999 16:11:22 +0100 (BST) [thread overview]
Message-ID: <E11ZFCV-0000tq-00@crucigera.fysh.org> (raw)
In-Reply-To: <991007145347.ZM27050@candle.brasslantern.com> from Bart Schaefer at "Oct 7, 1999 2:53:47 pm"
Bart Schaefer wrote:
>I disagree with a number of these changes, particularly promptbang,
>promptpercent, and promptsubst. Most scripts do not alter the values
>of PS[1234], and resetting the prompt-expansion options will cause the
>user's settings to display as garbage in conjunction with either use
>of "select" loops or (as of 3.1.6) "setopt xtrace"/"set -x".
I changed them to *not* be set by emulate. They're a user interaction
matter, and really can't directly affect the operation of scripts,
so should not be set by emulate.
>I further think it's unwise to have emulate reset either errexit or
>"exec" -- though I don't see how it could possibly make any difference
>to the latter, as emulate itself won't be executed if exec isn't set.
I was a bit dubious about these, and a few others with that type of
meta effect, such as XTRACE. On reflection, I think the criterion that
needs to be used is "is it valid to change this option within a script,
as a programming technique?". "emulate -L zsh" is really the idiom used
to get known standard behaviour in a zsh function, so everything that
affects the direct behaviour of the function should be set by it.
With ERR_EXIT, I was imagining that a user might set the option in a
script (it can be quite convenient in scripts run from make), and then
call a function that doesn't want ERR_EXIT set -- the function should
decide for itself how to handle errors. Applying the criterion I state
above, it is normal to set this option within a script -- it has the
effect of suffixing all commands with "|| exit", which is sometimes what
one wants.
For EXEC, really there's no reason to change it within a script. Its sole
purpose is for syntax checking of a script, so I agree that it shouldn't
be considered to be emulation-relevant.
> Certainly I agree with
>some of the changes, e.g. the history options ought *not* to be reset.
Right. Again, these are user interaction features, and don't affect
scripts.
>
>} The patch quoted above is still necessary; EXTENDED_GLOB is unset
>} by default even in zsh mode. Would changing that break any scripts?
>
>Yes, it would break some of my scripts.
A pity.
-zefram
next prev parent reply other threads:[~1999-10-07 15:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-10-07 0:28 PATCH: Re: Prompt fun Bart Schaefer
1999-10-07 10:41 ` PATCH: emulate (Re: Prompt fun) Zefram
1999-10-07 14:53 ` Bart Schaefer
1999-10-07 15:11 ` Zefram [this message]
1999-10-07 15:42 ` Bart Schaefer
1999-10-07 15:50 ` Zefram
1999-10-07 17:20 ` Bart Schaefer
1999-10-07 17:29 ` Zefram
1999-10-07 18:56 ` Bart Schaefer
1999-10-08 9:58 ` Zefram
1999-10-07 20:32 ` Reasons for not wanting EXTENDED_GLOB interactively (was Re: PATCH:...) Bruce Stephens
1999-10-08 6:15 ` Andrej Borsenkow
1999-10-10 23:03 ` PATCH: Re: PATCH: emulate (Re: Prompt fun) Bart Schaefer
1999-10-10 23:19 ` Bart Schaefer
1999-10-11 8:20 ` Zefram
1999-10-10 23:21 ` Bart Schaefer
1999-10-11 8:17 ` Zefram
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=E11ZFCV-0000tq-00@crucigera.fysh.org \
--to=zefram@fysh.org \
--cc=schaefer@candle.brasslantern.com \
--cc=zsh-workers@sunsite.auc.dk \
/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).