On Tue, Aug 30, 2022 at 07:28:43AM +0200, Laszlo Ersek wrote:
I had grepped the virt-p2v and virt-v2v shell scripts for shebangs:
1 #!/bin/sh 2 #!/bin/bash 4 #!/usr/bin/env perl 17 #!/bin/bash -
1 #!/bin/bash 1 #!/usr/bin/env python3 1 #!/usr/bin/sh 5 #!/usr/bin/env perl 67 #!/bin/bash -
The thinking seems to have been that - python3 and perl may "move", - bash is considered always available.
For p2v, yeah, we are pretty much guaranteed to be running on Linux, and therefore have bash (even if /bin/sh is not bash).
+ +set -e -u -C
My personal opinion is that 'set -e' is a crutch that should be avoided because of its unintended interaction with functions;
Can you please elaborate?
POSIX writes, "When a function is executed, it shall have the syntax-error and variable-assignment properties described for special built-in utilities in the enumerated list at the beginning of Special Built-In Utilities", and I've checked that list -- I don't know what you mean.
Here's a good writeup: http://mywiki.wooledge.org/BashFAQ/105 One of the simplest demonstrations on that page: $ bash -c 'set -e; f() { set -e; false; echo huh; }; f; echo survived' $ bash -c 'set -e; f() { set -e; false; echo huh; }; f && echo survived' huh survived That is, using 'set -e' to end function f early "works", but ONLY in situations where f itself is not invoked in a context where 'set -e' is suppressed because of a conditional in an outer scope. And once 'if' or '&&' suppresses 'set -e', you cannot re-enable it within f itself. Context-sensitive behavior of your function body based on the context of the caller is NOT intuitive. That said, if you KNOW that -e behaves non-intuitively, and plan to write your script with that in mind, it can be helpful. The complaint is that because -e is disabled in so many situations, it is harder to prove that -e catches all the scenarios that you WANTED to be caught than it is to just write the error handling yourself.
but I'm not adamant enough about it to tell people to rip it out of scripts. For short scripts, like this one, it's easy enough to check that we aren't tripping over any of -e's surprises.
+ +disk= + +cleanup() +{ + set +e + if test -n "$disk"; then + rm -f -- "$disk" + disk= + fi +} + +trap cleanup EXIT
Is it intentional that you are not also cleaning up on signals like INT and HUP?
Yes, as EXIT covers those.
Okay; currently true enough for bash, but not portable to other shells. In fact, the Austin Group visited that topic just this week: https://austingroupbugs.net/view.php?id=621 After 2018 edition page 2420 line 77499 section 2.14 trap, add a new paragraph: The EXIT condition shall occur when the shell terminates normally (exits), and may occur when the shell terminates abnormally as a result of delivery of a signal (other than SIGKILL) whose trap action is the default. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org