when a puppet exec resource contains several "single commands", puppet exec only fails if the last exec command fails

[David Portabella]

exec {'test':

  command => "/bin/ls /doesnotexit", 

}

fails as expected:

Error: /bin/ls /doesnotexit returned 1 instead of one of [0]
Error: /Stage[main]//Exec[test]/returns: change from notrun to 0 failed: /bin/ls /doesnotexit returned 1 instead of one of [0]

However, 

exec {'test':

  command => "/bin/ls /doesnotexit; /bin/echo hello", 

}

does not fail, because the last command did not return an error!

that's a problem, because there are many puppet modules which concatenate several commands in one puppet exec, and they do not explicitly handle the errors.

(inserting "set -e" at the head of the command line does not work, as it is bash script specific)

I think that, by default, the puppet exec resource should fail if any of the "single commands" fail (as in the second example).
and if it is not by default, at least there should be an option in puppet exec to do so (equivalent to "set -e" in bash)

(tested on puppet 3.3.2)

[José Luis Ledesma]

When you use concatenated commands any shell will only return the last command return code by design, and this is what puppet receives. So its a ' works at a expected'

If you need to control each of the return codes just use different exec resources

Regards,

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fc8a32ca-1e7b-4376-ace7-a1c36dd665c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Portabella]

I don't agree with this statement.

in bash, for example, if you type "set -e" first, bash will stop and fail as soon as a concatenated command fails.

(i agree that this behaviour is unfortunatelly not enabled by default in bash scripts)

> If you need to control each of the return codes just use different exec resources

> If "you",
the problem is that there are many puppet modules which use concatenated commands, without realising about this problem.
to be safe, I am suggesting that puppet should enable that behavior by default.

> need to control each of the return codes

i don't suggest executing every concatenated command and control each return control.
i am suggesting failing as soon as a concatenated command fails. (as in bash set -e)

> just use different exec resources

as a side note, 

another improvement about puppet exec would be that the exec command can be an array of strings, executed in order as long as none fails.

Regards,

David

[Paul Tötterman]

in bash, for example, if you type "set -e" first, bash will stop and fail as soon as a concatenated command fails.

(i agree that this behaviour is unfortunatelly not enabled by default in bash scripts)

exec {'test':

  command => "/bin/ls /doesnotexit; /bin/echo hello", 

}

Use:

exec { 'test':

    command => '/bin/ls /doesnotexist && /bin/echo hello',

}

Cheers,

Paul

[David Portabella]

thanks. I agree, using && instead of ; solves the problem.

however, again, there are many puppet modules which use concatenated commands, without realising about this problem.
and so, I am suggesting that puppet should enable the "set -e" behavior by default.

Regards,
David

[David Arroyo]

Along the same lines, many exec resources are written with this behaviour in mind. For example, this exec will initialize the puppet CA certificate. Useful if you're running puppet under something like passenger.

exec{'Create initial puppet CA':

command => '/sbin/service puppetmaster start; /sbin/service puppetmaster stop',

creates => "${settings::ssldir}/certs/ca.pem",

}

Here I don't care if the first command returns an error (because puppet is already running). If execs were to to an implicit 'set -e', my manifest would fail where it didn't in the past.

If it's really a problem for you, I you can always write a 'paranoid' provider for exec resources.

-David

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/05d8ba97-4c12-414b-a821-f9276b9e6a1d%40googlegroups.com.

[Nikola Petrov]

Actually you can emulate what you want if you join the commands with &&.
Something like the following:

$command = "/bin/ls /doesnotexit; /bin/echo hello"

exec { 'cool':
command => join(split($command, '; '), " && "),
}

Note1: you will need https://github.com/puppetlabs/puppetlabs-stdlib for
this. Although I suppose you already have it.

Note2: this is not tested but it should work. Of course it written
in a generic way so you can wrap it in a define let's say.

Note3: the error messages from this can be cryptic...

P.S. Hate using execs..

--
Nikola

> > El 10/03/2014 16:02, "David Portabella" <david.po...@gmail.com<javascript:>>

> > escribió:
> >
> >>
> >> exec {'test':
> >> command => "/bin/ls /doesnotexit",
> >> }
> >>
> >> fails as expected:
> >>
> >> Error: /bin/ls /doesnotexit returned 1 instead of one of [0]
> >> Error: /Stage[main]//Exec[test]/returns: change from notrun to 0 failed:
> >> /bin/ls /doesnotexit returned 1 instead of one of [0]
> >>
> >> However,
> >> exec {'test':
> >> command => "/bin/ls /doesnotexit; /bin/echo hello",
> >> }
> >>
> >> does not fail, because the last command did not return an error!
> >>
> >> that's a problem, because there are many puppet modules which concatenate
> >> several commands in one puppet exec, and they do not explicitly handle the
> >> errors.
> >>
> >> (inserting "set -e" at the head of the command line does not work, as it
> >> is bash script specific)
> >>

> >> *I think that, by default, the puppet exec resource should fail if any of
> >> the "single commands" fail (as *
> >> *in the second example). and if it is not by default, at least there

> >> should be an option in puppet exec to do so (equivalent to "set -e" in

> >> bash)*

> >>
> >> (tested on puppet 3.3.2)
> >>
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Puppet Users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an

> >> email to puppet-users...@googlegroups.com <javascript:>.

> >> To view this discussion on the web visit

> >> https://groups.google.com/d/msgid/puppet-users/fc8a32ca-1e7b-4376-ace7-a1c36dd665c3%40googlegroups.com<https://groups.google.com/d/msgid/puppet-users/fc8a32ca-1e7b-4376-ace7-a1c36dd665c3%40googlegroups.com?utm_medium=email&utm_source=footer>
> >> .

> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
>

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/73dbd33c-4d80-4631-97b9-b860eddc5f37%40googlegroups.com.

[Felix Frank]

On 03/11/2014 01:23 AM, David Arroyo wrote:
> If it's really a problem for you, I you can always write a 'paranoid'
> provider for exec resources.

+1

...or add a parameter to exec that allows you to change the behavior of
the shell provider.

Changing the behavior of the shell to help people who write faulty shell
one-liners seems like a Bad Idea to me. Tools shouldn't enable and
encourage bad practices.

Cheers,
Felix

[José Luis Ledesma]

+1

Moroever the ser -e its just for bash, and bash is not installed by default in most Unixes.

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/531EDEF1.9020508%40alumni.tu-berlin.de.

[jcbollinger]

On Tuesday, March 11, 2014 5:01:21 AM UTC-5, Felix.Frank wrote:

Changing the behavior of the shell to help people who write faulty shell
one-liners seems like a Bad Idea to me. Tools shouldn't enable and
encourage bad practices.

+1

Furthermore, it would be quite surprising and annoying for Puppet to automatically set a non-default option for shell commands it launches via an Exec, so that I have to take explicit extra action to get standard shell behavior.  That there is bad code out there is poor justification for Puppet to change its behavior to make that bad code work, especially when doing so would make some working code fail.


John

[Joachim Schrod]

On 03/11/14 11:08, José Luis Ledesma wrote:
>
> Moroever the ser -e its just for bash

What makes you think that?

"set -e" is specified in IEEE Std 1003.1, 2004 Edition, a.k.a.
The Single Unix Specification. It's by no means bash specific
and will be supported by any sane /bin/sh on all current Unixes.

See
http://pubs.opengroup.org/onlinepubs/007904975/utilities/set.html

http://pubs.opengroup.org/onlinepubs/007904975/utilities/xcu_chap02.html#tag_02_14
demands that the special built-ins
http://pubs.opengroup.org/onlinepubs/007904975/idx/sbi.html are
supported, and set - as cited above - is one of them.

Could you please name the /bin/sh that doesn't support -e?

Joachim

PS: I don't support the wish to make "set -e" default. I want to question
a statement that I think is factually incorrect.

PPS: From my quotes file, for those of us old enough to have used the
original ancient Perl Configure:

========================
Drew Mills writes:
: A contest to see who could write the most useful script that could
: actually be used in the most languages *as is* [...]

I've written some scripts that work in 582 different languages,
all of them named sh.
[Larry Wall]
========================

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jsc...@acm.org

[José Luis Ledesma]

My bad, tried it incorrectly :s

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/lfsgen%24q2j%241%40ger.gmane.org.