[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-bash] Looking for something like "errexit" for interactive ses
From: |
Greg Wooledge |
Subject: |
Re: [Help-bash] Looking for something like "errexit" for interactive sessions |
Date: |
Wed, 28 Aug 2019 13:05:54 -0400 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
On Wed, Aug 28, 2019 at 09:48:20AM -0700, Eric Pruitt wrote:
> On Wed, Aug 28, 2019 at 09:46:31AM -0700, Eric Pruitt wrote:
> > On Wed, Aug 28, 2019 at 08:50:08AM -0400, Greg Wooledge wrote:
> > > Every command drops the user back to the prompt when it finishes, whether
> > > the exit status was 0 or non-zero.
> >
> > No, it doesn't when errexit is set unless I'm missing something:
https://mywiki.wooledge.org/BashFAQ/105
Let's imagine you're writing a loop. In this loop, there are several
commands. Some of these commands are *critical*. They have a usable,
meaningful exit status code, and if that exit status code is non-zero,
it means something bad happened, and you would like to terminate the
loop. Other commands are *noncritical*. They do not have a usable,
meaningful exit status code, or their failure is unimportant.
What you do is *decide* which commands are critical, and which commands
are noncritical. On the critical commands, you place this magic
syntax:
|| break
On the noncritical commands, you do nothing.
Here is an example:
#!/bin/bash
i=0
for f in ./*.foo; do
process "$f" || break
((i++))
done > logfile 2>&1
echo "$i files successfully processed"
In this loop, there are two commands. The first is critical -- if it
fails, we want to stop looping, and not process any more files. The
second is noncritical. Its exit status is not meaningful to us. When
it fails (and it will, see the FAQ), we do NOT want to stop the loop.
You cannot achieve your goal using set -e. You do not use set -e in
a real life script. set -e is fundamentally broken. set -e exists
only for legacy purposes. set -e hates you and wants to see you cry.
You achieve your goal by writing actual error-checking code in the
places where it is needed.
I'm wasting my time here, probably. You're not going to read this.
You're not going to listen to me. Other people will repeat my advice
and you won't listen to them, either.
It's always this way. We try and try and try, but there is no salvation
for the lost. You think there must be a magic bullet that will let you
not have to write error-checking code, because other scripting languages
have this feature. Well, bash is not other scripting languages. Bash
is feature-compatible with the Bourne shell from the 1970s. It was
designed by people in the 1970s. This is how it works.
This is how bash works.