Fail due to set -e when exec_in

[ArthurGarnier]

Step to reproduce :

exec_in: |
true
true
false
true

The last true isn't executed due to "set -e" added by kameleon to the script.

[lnussbaum]

isn't that a good thing? writing scripts without set -e is very dangerous (think of "cd non-existing-dir ; rm *")

if something should be allowed to fail, why not use:
command-that-can-fail || true
?

[jgaida]

set -e is full of pitfalls:

• http://mywiki.wooledge.org/BashFAQ/105
• http://david.rothlis.net/shell-set-e/

IMO, it should be the responsibility of the user to add set -e in its script if he want to. Kameleon users should have the choice to use it or not (and set -e is not a default behaviour).

[mickours]

I also think that set -e is a better default behavior for instructions that are put directly un Kameleon. Also, you can use set +e to override it in your scripts if you want.

[mickours]

I mean we use to have this behavior before and we changes because the silently failing instructions are really hard to catch, and the breakpoint that is triggered by it are really useful.

[ArthurGarnier]

@lnussbaum Some few commands return non-zero value even if all is OK. For example, puppet do that, if some files have changed during the puppet apply, the return code is 2.

Like @jgaida, I think it's the responsability of the user to put -e. But if it's really the behaviour expected, this should be documented here : http://kameleon.imag.fr/commands.html?highlight=exec

[SalemHarrache]

Upon verification, I already removed the errexit flag after this issue #64

Indeed, set -o errexit overwrites trap. This prevents me from saving the history and the env when there is an error. That is why some people do not recommend it.

(As far as I'm concerned, I always use it for simple scripts that don't handle errors)

I didn't encounter any bug with the git version, so I'll release a new version tonight (hopefully) :)

[npf]

So can it be closed ?

[SalemHarrache]

Yep :)