shell kung-fu with set -e, return codes and i/o redirection in while read ... loop
Hello,
in the cryptsetup init and cryptdists_{start|stop} scripts we use some
shell magic with set -e, while read ... done and input/output
redirection. i have to admit that this magic demonstrated me the limits
of my shell scripting skills.
the code in question is:
set -e
...
egrep -v ^[[:space:]]*(#|$) $TABFILE | while read dst src key opts; do
...
handle_crypttab_line_start $dst $src $key $opts 3
...
done 31
and the bugs that I try to fix are:
#524173
cryptdisk_start target doesn't return a sensible exit code on failure.
#524485
cryptdisks_start incorrectly reports failure
now let me try to explain the problem:
cryptdisks_start is a script that takes a target name as single argument
and starts this cryptdisks target with the options from /etc/crypttab.
many functions are shared in /lib/cryptsetup/cryptdisks.functions for
cryptdisks_{start|stop} and the cryptdisks initscripts.
cryptdisks_start at the moment always exits with error code 0 (success),
even if errors occured (target not found in /etc/crypttab, failed to
start, ...), and even worse, it doesn't even detect correctly whether
the target was found or not.
so the script needs to be changed to exit the while loop with
information about whether
- the target was found in crypttab
- the target setup succeeded or not
for the first one I only see one solution: add a counter to the while
loop which checks for $count -ge $valid_crypttab_lines.
for the second one I first thought that wrapping the complete while
loop with ret=$(while read ... done) would be an option, but
unfortunately that doesn't work due to input redirection to/from
filedescripter 3 (3, 31) ...
so second thought was to use return codes inside the while loop and
check for them after the while loop. but that failed due to 'set -e'
being set. therefore any return code != 0 caused the script to stop
immediately instead of just exiting the while loop.
now I see the option to set -e only inside the while loop, but I would
like to have other opinions about that idea before actually implementing
it. tests on my system gave me the impression that it works as expected:
count=0
tablen=$(egrep -v ^[[:space:]]*(#|$) $TABFILE | /usr/bin/wc -l)
egrep -v ^[[:space:]]*(#|$) $TABFILE | while read dst src key opts; do
set -e
count=$(( $count + 1 ))
if [ $1 = $dst ]; then
handle_crypttab_line_start $dst $src $key $opts 3
exit $?
fi
if [ $count -ge $tablen ]; then
device_msg $1 failed, not found in crypttab
exit 1
fi
done 31
ret=$?
...
log_action_end_msg $ret
only one issue remains that still doesn't work as expected:
if handle_crypttab_line_start fails with a warning, it still returns 0
(success) as return code. unfortunately I don't see an option t change
that one.
in initscripts it would be fatal for handle_crypttab_line_start to exit
with any return code != 0 as that would cause the whole initscript to
stop instead of processing the remaining crypt targets.
maybe the best solution would be to rewrite the whole story, but I don't
even have an idea how to do it better.
thanks in advance for any comments.
greetings,
jonas
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: iulib (5th attempt)
Le Sun, Jul 19, 2009 at 12:09:32AM +0200, Jeffrey Ratcliffe a écrit :
2009/7/18 Charles Plessy ple...@debian.org:
I found some issues in the latest version of your package:
- The build target can not been invoked twice in a row because of the mv
commands (you know what to do, you did it right for the clean target).
dh7 won't invoke the build target more than once, so I think this is OK.
Hi Jeffrey,
our tools do not invoke the build target twice in a row, but real people
sometimes have a good reason to do. For instance, I tried to build iulib it did
not work because I was missing dependancies, and when I installed them and
called the build target again, it triggered the bug discussed above. A good
makefile should be resilient to this.
Talking about dependancies, since there are only three versions of the libtool
package in circulation, you can probably depend on versions higher than Lenny.
Alternatively, you can support both: it looks easy. It would be especially
useful if you think that there are chances your package would be backported.
If the scons migration for the 0.4 version implies to drop libtool, you do not
need to put too much energy into this…
A much more problematic issue is the binary dependancies of libiulib0. You have
devised a long list by hand, but it is not accurate for Sid, which is the
target of your package. There is at least one error: libavcodec51 does not
exist there. Do you have evidence that ${shlibs:Depends} is not enough?
- The dependancy of libiulib-dev should be versioned on libiuli0. The
symbolic
link /usr/lib/libiulib.so - libiulib.so.0.0.0 will break otherwise.
Isn't this could be something that lintian should check for, along
with that .la files should be in -dev?
Probably. Maybe you can submit a whishlist bug, or if you have time, try to
write such a check.
PS: do you know how to write a symbols control file? (me not).
Have a nice day,
--
Charles Plessy
http://charles.plessy.org
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: shell kung-fu with set -e, return codes and i/o redirection in while read ... loop
In 20090719114552.ga15...@resivo.wgnet.de, Jonas Meurer wrote: so second thought was to use return codes inside the while loop and check for them after the while loop. but that failed due to 'set -e' being set. therefore any return code != 0 caused the script to stop immediately instead of just exiting the while loop. If you use the command in an if/while/until statement, it can fail without terminating the script, even when the -e shell option is set. You might be able to use something like: while something; do if cmd_that_can_fail; then :; else # Just can check $? if you want # to know the exact return code. # Print a warning, but continue fi done only one issue remains that still doesn't work as expected: if handle_crypttab_line_start fails with a warning, it still returns 0 (success) as return code. That warning seems more like an error to me -- the function fails. unfortunately I don't see an option t change that one. in initscripts it would be fatal for handle_crypttab_line_start to exit with any return code != 0 as that would cause the whole initscript to stop instead of processing the remaining crypt targets. Using something like the above you should be able to try to mount the all entries, print a warning for each one that fails, and then return an appropriate code to indicate success/partial success/failure. \-- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: shell kung-fu with set -e, return codes and i/o redirection in while read ... loop
Hello, On 19/07/2009 Chow Loong Jin wrote: On Sunday 19,July,2009 07:45 PM, Jonas Meurer wrote: so the script needs to be changed to exit the while loop with information about whether - the target was found in crypttab You already have that information. In the snippet of code: found=no egrep -v ^[[:space:]]*(#|$) $TABFILE | while read dst src key opts; do if [ $1 = $dst ]; then found=yes handle_crypttab_line_start $dst $src $key $opts 3 exit 0 fi done 31 Note the value of the variable found. If it's yes, it was found, otherwise it's not. no, unfortunately not. the while read ... loop opens a subshell, thus the found=yes inside is pointless. greetings, jonas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: shell kung-fu with set -e, return codes and i/o redirection in while read ... loop
On 19/07/2009 Boyd Stephen Smith Jr. wrote:
In 20090719114552.ga15...@resivo.wgnet.de, Jonas Meurer wrote:
so second thought was to use return codes inside the while loop and
check for them after the while loop. but that failed due to 'set -e'
being set. therefore any return code != 0 caused the script to stop
immediately instead of just exiting the while loop.
If you use the command in an if/while/until statement, it can fail without
terminating the script, even when the -e shell option is set. You might
be able to use something like:
while something; do
if cmd_that_can_fail; then :; else
# Just can check $? if you want
# to know the exact return code.
# Print a warning, but
continue
fi
done
ah, that indeed is an option. I now solved the issue the following way:
- in cryptdisks_{start|stop} only one device is setup anyway. here I
simply don't use set -e and check for the error code instead.
- in cryptdisks initscript set -e is set, and handle_crypttab_line_start
is wrapped in an if statement:
handle_crypttab_line_start $dst $src $key $opts 3 || true
greetings,
jonas
signature.asc
Description: Digital signature
RFS: gcontactsync
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package gcontactsync. * Package name: gcontactsync Version : 0.2.5-1 Upstream Author : Josh Geenen gcontacts...@pirules.net * URL : http://gcontactsync.mozdev.org/ * License : MPL-1.1 | GPL-2 | LGPL-2.1 Section : mail It builds these binary packages: icedove-gcontactsync - synchronizes contacts from Gmail into IceDove The package appears to be lintian clean. The upload would fix these bugs: 518465 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/g/gcontactsync - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/g/gcontactsync/gcontactsync_0.2.5-1.dsc I would be glad if someone uploaded this package for me. Kind regards Miguelangel Jose Freitas Loreto -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpj3rMACgkQEj/fBl4PScTtHwCfXAvO01go+U2DMw5w4+l5dwyk ySEAn00HHOQ/6KoCf5t1XRpNHv2TUSxm =yKs7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
