Hi,
Reading through the recent discussion about set -e reminded me of an
old patch I sent a couple of years ago for an optional errreturn shell
option.
The goal was never really to "fix" errexit, and I agree with other
responses highlighting the complexity of this approach. The idea was
much narrower: provide an opt-in mechanism that propagates failures
out of functions even when the function happens to be called from a
conditional context.
One thing that always bothered me about errexit is that whether a
command aborts execution or not depends on how the caller invokes the
function. For example:
~~~
fcopy()
{
cp f1 d1
cp f2 d2
}
# 2nd copy (in fcopy above) will get executed, even if first copy failed.
set -e
if fcopy; then
# printed if 2nd copy failed, regardless of the status of the first cp
echo "ALL GOOD"
fi
# With errreturn, fcopy will return after the failure in the first cp
set -o errreturn
if fcopy ; then
# printed if both 1st copy and 2nd copy passed.
echo "ALL GOOD"
fi
~~~
In the above example, When fcopy is executed under if, the behavior
inside the function changes. The proposed errreturn option was
intended to address that specific case without changing existing
errexit semantics.
I know there is still ongoing work around the current 5.x cycle, and I
don't want to restart the entire discussion from 2022. But if there is
still some interest in the idea, I'm happy to rebase the patch on top
of the current devel branch, refresh the tests and resend it.
Thanks,
Yair
On Thu, Jun 11, 2026 at 11:58 PM <[email protected]> wrote:
>
> Send bug-bash mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/bug-bash
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bug-bash digest..."
>
>
> Today's Topics:
>
> 1. Re: The politics of "set -e" (Was: Regression with subshells
> and set -e) (Robert Elz)
> 2. Re: PS0 vs. \[ \] followup (Chet Ramey)
> 3. Bash/readline coupling (was: PS0 vs. \[ \] followup)
> (G. Branden Robinson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 12 Jun 2026 03:41:45 +0700
> From: Robert Elz <[email protected]>
> To: [email protected]
> Subject: Re: The politics of "set -e" (Was: Regression with subshells
> and set -e)
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> Date: Thu, 11 Jun 2026 12:45:41 -0600
> From: Stan Marsh <[email protected]>
> Message-ID: <[email protected]>
>
> | This paragraph is obviously nonsense, taken at face value.
>
> You're welcome to your opinion, but I meant what I said.
>
> | But in fact, properly interpreting it depends on two variables:
> |
> | 1) Are we talking about using -e as your primary (i.e., only)
> | method of error handling or are we talking about using it as "last
> | resort" - a handler for the truly unexpected?
>
> That actually makes no difference. Using -e at all, except in very
> specialised scripts (I mean the way they are written, not what they do)
> is almost always going to cause more problems than it solves.
>
> | 2) Are we operating in the world of actual reality, or is our
> | orientation that of lecturing to newbies?
>
> There's certainly a bunch of the latter, but for this, the vast
> majority of people who write sh code are newbies. There are
> certainly people who actually understand -e (though even they can
> sometimes be surprised by how it often doesn't do what was planned)
> but they are a fairly small group.
>
> As a general rule, unless you have written a shell, or worked on the
> code for one for years, you probably don't really understand -e (many
> people believe they do, most of them are wrong.)
>
> Just don't use it. Really, just don't.
>
> If you need a shell option to help make your code safer, by all
> means, turn on -u. That one works in a predictable, and fairly
> easy to understand, way (it isn't an alternative to -e of course,
> there isn't one of those).
>
> kre
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 11 Jun 2026 16:43:22 -0400
> From: Chet Ramey <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: Re: PS0 vs. \[ \] followup
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 6/10/26 6:20 AM, Koichi Murase wrote:
> >
> >> variable expansions for all the rest (creating new variables for the
> >> expansions which don't currently have one) - expanded at assignment
> >> time (inside "")
> >
> > That doesn't work because a backslash at the end of the value of the
> > variable will escape the next character unexpectedly.
> >
> > bs='\'
> > PS0="${bs}w "
> >
> > Then you'll get «<current working directory> » instead of «\w ».
>
> Because you used double quotes in the assignment, assigning the string
> "\w" to PS0. If you had used single quotes, the ${bs} would have been
> expanded after the backslash-escape sequences, and you'd see `\w '
> displayed.
>
> > That doesn't work with «shopt -u promptvars». If it were the user's
> > personal setting, the user should just turn on `promptvars', but we
> > are now talking about interactive shell settings injected by the
> > terminal, which need to work with various user configurations.
>
> Document your assumptions. Tell the user that there are caveats if they
> change the default bash settings, or the settings that you assume.
>
> >
> >> (and the promptvars option should just go away and always
> >> act as it does now when set).
> >
> > OK, so, do you suggest removing «shopt -u promptvars»? Yeah, if that
> > will be accepted, that is ideal.
>
> Come on.
>
> > I totally agree, but we can't redesign this for backward
> > compatibility. Adding even another option to unify those expansions to
> > a single-pass conversion is even worse.
> >
> >> when one sometimes wants one before the other, and other times the
> >> other order, it is all just a giant mess.
> >
> > We consistently want post-promptvars removal. I don't think there are
> > cases where people want pre-promptvars removal.
>
> You want a magic, invisible separator character that bash adds and deletes
> for you. That is not what \[ and \] are.
>
>
> > Because they are internally used for the markers of \[ and \]. I don't
> > know the reason that the markers are not embedded in a transparent
> > way, such that raw \1 and \2 are preserved by an escaping mechanism.
>
> \1 and \2 are documented by readline as the way for applications to signal
> which characters in the prompt string are and are not visible for
> redisplay. Readline is used by dozens of other applications, some of which
> support their own mechanisms for using them. They are not bash-specific.
>
>
> > It's just for historical reasons, and we can't switch the behavior
> > now.
> >
> >> What if I want to send \1 or \2 to the terminal for some reason?
> >
> > There is no way. However, PS1 worked this way for a long time, and it
> > hasn't caused an issue because most terminals just ignore \1 and \2.
>
> Most do, some don't. That was the substance of the original report:
>
> "In turn, most modern terminal emulators that I'm aware of ignore these
> bytes. An exception I've found is Zutty, it prints replacement symbols,
> causing unexpected visual result. I'm pretty sure there are other software
> and hardware terminals as well where this can cause problems."
>
>
>
> >> | To remove \x01 and \x02 properly, they should be removed at the very
> >> last
> >> | step, as we are requesting in the present thread.
> >>
> >> Those shouldn't be removed at all, I see nothing in the bash doc that
> >> says they are special.
> >
> > However, that's how Readline worked for PS1 from at least bash-1.14.7:
> >
> > bash-1.14.7$ grep -rn '#define RL_PROMPT_'
> > lib/readline/readline.h:282:#define RL_PROMPT_START_IGNORE '\001'
> > lib/readline/readline.h:283:#define RL_PROMPT_END_IGNORE '\002'
> >
> > though I agree that they should actually be documented in the manual.
>
> They are documented as part of the readline documentation; this is a
> readline feature.
>
> "Applications may indicate that the prompt contains characters that take
> up no physical screen space when displayed by bracketing a sequence of
> such characters with the special markers @code{RL_PROMPT_START_IGNORE}
> and @code{RL_PROMPT_END_IGNORE} (declared in @file{readline.h} as
> @samp{\001} and @samp{\002}, respectively).
> This may be used to embed terminal-specific escape sequences in prompts.
> If you don't use these indicators, redisplay will likely produce screen
> contents that don't match the line buffer."
>
>
> > The characters
> > \1 and \2, which are effectively no-op in terminals, are different
> > from graphical characters and control characters associated with
> > functions in terminals.
>
> They're not always, see above. But if they are, at least to a degree with
> which you're comfortable, there's nothing stopping you from using them
> yourself.
>
> >> The issue is that, as I understand things, they aren't being removed at
> >> all - they simply are no longer being inserted where they once were, as
> >> they are not needed in PS0 or PS4 (in them, nothing there cares what chars
> >> in the string use char positions on the terminal, and which don't).
> >
> > I don't think whether we call it "remove" or "not insert" is relevant.
> > They are equivalent.
>
> Obviously not. You want them inserted, then removed later, so they exist in
> the prompt string for long enough to act as dummy separators.
>
>
> >> Any \[ \] in the string are simply deleted - and technically,
> >> perhaps even that shouldn't happen, as PS0 and PS4 don't need such
> >> things.
> >
> > So, you mean deleting \[\] shouldn't happen in PS0 and PS4? That is
> > the behavior before commit 1e9f5e10 in the devel branch.
>
> That is not what he said, and not what used to happen. The behavior of bash
> before the above commit was to replace \[ and \] with 0x01 and 0x02,
> respectively, when expanding PS0 and PS4.
>
>
> Let me clarify this for you: Before commit 1e9f5e10 (and in
> > Bash 5.3):
> >
> > PS1 underwent (1) the \ processing, (2) the promptvars processing,
> > (3) (layout calculations if necessary and) deletion of \1\2.
>
> Sigh. 0x01 and 0x02 remain in the prompt string, even when it's passed to
> readline. Readline performs its own interpretation of those markers, which
> effectively means that it doesn't use them in redisplay calculations or
> write them to the terminal. Bash is out of the picture.
>
> >
> > PS0 underwent (1) the \ processing, (2) the promptvars processing.
> >
> > We requested to add to PS0 a transform that is equivalent to (3),
> > i.e., expecting something like this:
>
> The original request asked for 0x01 and 0x02 not to appear in PS0.
>
> Subsequent messages clarified that you want 0x01 and 0x02 to act as dummy
> separator characters, and new code that goes through the decoded prompt
> string and removes occurrences of 0x01 and 0x02 (but not when it's PS1 or
> PS2!).
>
> >
> > PS1: (1) (2) (3),
> > PS0: (1) (2) (3).
> >
> > However, after commit 1e9f5e10, the behavior became effectively
> >
> > PS1: (1) (2) (3),
> > PS0: (1) (3) (2),
> >
> > though, in the actual implementation, (1)+(3) is effectively combined
> > to directly produce the (1)+(3) result). In this thread, we are
> > requesting to correct (1) (3) (2) to (1) (2) (3) to match PS0's
>
> You say that like it's an error to correct.
>
> It's not. You want a way to separate arbitrary portions of the prompt
> string (or the final portion of the supplied PS0 and what the user
> might want to append, at least). That's the ask here.
>
> The issue of having two passes that both process a backslash quoting a
> backslash (the "if we want 10 backslashes we have to put up to 40 in the
> prompt string" depending on the `promptvars' setting from a follow-up
> message) isn't really the problem. That doesn't affect anything unless the
> user wants to append to PS0.
>
> The problem is having a dummy invisible character to separate the final
> backslash from whatever the user might want to add. You could, in fact,
> add such a dummy character yourself -- it could even be 0x02, since that
> doesn't affect most terminals, you assert above, and it's not going to
> affect cursor positioning.
>
> > behavior to PS1's behavior because that creates a difference between
> > PS1 and PS0 for how promptvars is applied to an identical setting.
>
> Why would you force PS1 and PS0 to behave identically, when one is passed
> to readline and one is not? They serve different purposes and have
> different requirements.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: OpenPGP_signature.asc
> Type: application/pgp-signature
> Size: 203 bytes
> Desc: OpenPGP digital signature
> URL:
> <https://lists.gnu.org/archive/html/bug-bash/attachments/20260611/e85d323c/attachment.sig>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 11 Jun 2026 15:57:12 -0500
> From: "G. Branden Robinson" <[email protected]>
> To: [email protected]
> Subject: Bash/readline coupling (was: PS0 vs. \[ \] followup)
> Message-ID: <20260611205712.zv2imv342efl35xx@illithid>
> Content-Type: text/plain; charset="utf-8"
>
> At 2026-06-11T16:43:22-0400, Chet Ramey wrote:
> > \1 and \2 are documented by readline as the way for applications to
> > signal which characters in the prompt string are and are not visible
> > for redisplay. Readline is used by dozens of other applications, some
> > of which support their own mechanisms for using them. They are not
> > bash-specific.
>
> I think this fact would be significantly more obvious if readline and
> Bash releases were not coupled. For as long as they are, the impression
> that readline updates only where and when Bash needs it to is going to
> be difficult to overcome.
>
> Have you considered this?
>
> Regards,
> Branden
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL:
> <https://lists.gnu.org/archive/html/bug-bash/attachments/20260611/0169045c/attachment.sig>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bug-bash mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/bug-bash
>
>
> ------------------------------
>
> End of bug-bash Digest, Vol 283, Issue 20
> *****************************************
