On 27/03/2019 17:04, Bruce Dubbs via blfs-dev wrote:
On 3/27/19 9:44 AM, Roger Koehler via blfs-dev wrote:
On Wed, Mar 27, 2019, 6:52 AM Pierre Labastie via blfs-dev
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
When making scripts from the book (either by copy/paste
or some use of xsltproc), the generated scripts have `&&' at
the end of each line. It allows to not execute the following
instructions if one instructions fail, but it defeats the use of
"set -e". From the bash man page under the set builtin, for
option -e (emphasis by me):
------------
Exit immediately if a pipeline (which may consist of a
single simple command), a list, or a compound command
(see SHELL GRAMMAR above), exits with a non-zero status.
*The shell does not exit if the command that fails is
part of the command list immediately following a while
or until keyword, part of the test following the if or
elif reserved words, part of any command executed in a
&& or || list except the command following the final &&
or ||, any command in a pipeline but the last, or if the
command's return value is being inverted with !.*[...]
------------
In short, with a construct like:
----
set -e
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!
So why do we use those `&&' in the book???
I've tried to automatically remove the `&&' in jhalfs, but it is not
possible, because sometimes, the `... && ...' construct really
really means
if ...; then ...
There could be a solution: ask devs not to use `... && ...' when
they mean
if ...; then ...
Another is to not have `&&' at the end of line. Actually, what
would we
lose?
For me, it makes it easy to see which commands go together when
editing the jhalfs-generated scripts. For example, to remove the
generation of API documentation when I don't have the necessary tools
installed.
Good point: I do that too... (There should be a role or a remap
attribute for those instructions actually: they usually need some of the
optional dependencies.)
However, I would gladly forego that luxury for the peace of mind in
knowing that when a build completes successfully, it actually
installed everything.
I think most users just copy/paste the instructions instead of scripting.
Uh? there are 700+ packages in BLFS. Copy/paste would take forever. Even
if just building Xorg, there are more than 100 packages. Doing that once
could be tried, but I'm almost sure anybody using regularly BLFS is
scripting in some way (That's certainly different for LFS users. But in
the LFS book, there are almost no &&).
In that case using && makes the instructions fail on the problematic
instruction instead of continuing to the rest of the commands in the
block. In places like xorg-libs where we create a script-like
environment using 'bash -e', we do not use &&.
Personally I wrap my scripts in
{
a &&
b
}
if [ $PIPESTATUS -ne 0 ]; then exit 1; fi;
That sounds like a possible way to go for jhalfs. I think I could
enclose any block of code with {} and test PIPESTATUS. That would make
scriptlets harder to read though. The "remove API doc" goal would be
still achieved.
Xi Ruoyao idea of having a different entity for continuation double
ampersand could be used too.
Thanks to you all for your inputs. It helps a lot.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
