Hi,
On Wed, 27 Mar 2019, Pierre Labastie via blfs-dev wrote:
instruction A &&
instruction B &&
instruction C
----
The script does not exit if either instruction A or instruction B fails,
but the following instructions are not executed... This may lead to
a script completing successfully, while the package was in fact not
installed, or only partially installed or compiled!
Interesting point of view. I never cared about the exit code of such
script before. Unfortunatelly, running through without error does not mean
the installed result is sane. Instead, I check build time and
size/start/end of logged output.
Admittedly, a clean exit code would be a benefit, though maybe only a
small one.
So why do we use those `&&' in the book???
Not sure why it's in the book, but I like it for telling me which step
does not make sense after the previous failed. I do have lines without &&,
because some parts are independent or failing is just fine (like removing
potentially existing files). A long nested if/then would be harder to read
or comment out partially or similar.
I'm fine with a partially executed script - as long the result is sane.
This often enables me to [fix and] re-execute the part that failed without
doing everything from scratch.
Looks like your "set -e" approach has a similar aim, but it requires a
more carefully designed script. With "mark with && what depends on each
other" it is easier to write instructions than with "each and every
command depends on the previous one being executed successfully"
Another is to not have `&&' at the end of line. Actually, what would we
lose?
The freedom to have failing commands in a script [that e.g. try to remove
files that may not exist] and a way to mark command blocks as
independent...
Uwe
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
