Assigning command output to a variable

[Adam Mercer]

Hi

For one of my projects I need to get the contents of
/etc/redhat-release during the configure process and assign the
contents to a variable. I'm currently using the following:

redhat_release=`cat /etc/redhat-release 2> /dev/null`

This works fine, but I was wondering if anyone had any better suggestions?

Cheers

Adam

[Eric Blake]

Post by Adam Mercer
Hi
For one of my projects I need to get the contents of
/etc/redhat-release during the configure process and assign the
redhat_release=`cat /etc/redhat-release 2> /dev/null`
This works fine, but I was wondering if anyone had any better suggestions?

You can avoid the command substitution fork by using read:

{ read redhat_release < /etc/redhat-release; } 2>/dev/null

Whether that's deemed any simpler, though, is a matter of taste. Not to
mention that use of 'read' like this is limited to cases where you know
you are reading a one-line file (when present).

[Stefano Lattarini]

Post by Eric Blake

Post by Adam Mercer
Hi
For one of my projects I need to get the contents of
/etc/redhat-release during the configure process and assign the
redhat_release=`cat /etc/redhat-release 2> /dev/null`
This works fine, but I was wondering if anyone had any better suggestions?

{ read redhat_release < /etc/redhat-release; } 2>/dev/null
Whether that's deemed any simpler, though, is a matter of taste. Not to
mention that use of 'read' like this is limited to cases where you know
you are reading a one-line file (when present).

According to the Autoconf manual, the Tru64/OSF 5.1 sh might abort if
the above is run and the /etc/redhat-release file doesn't exist, since
that shell treats 'read' as a special (in POSIX sense) built-in. See
also Automake commit v1.11-289-g080efc9:

<git.savannah.gnu.org/cgit/automake.git/commit/?id=080efc9>

In addition, some other brain-dead /bin/sh shells (yes, I'm looking at
you, Solaris) seem to run commands specified in a stderr-redirected
{ ...; } compound command in a subshell:

$ /bin/sh -c 'a=ko; { a=ok; }; echo $a'
ok
$ /bin/sh -c 'a=ko; { a=ok; } 2>/dev/null; echo $a'
ko

Not sure how all of this is still relevant today, though (and it
certainly gives yet more good reasons to have Autoconf require a
POSIX shell ... ;-)

Regards,
Stefano

[Adam Mercer]

On Mon, Nov 19, 2012 at 1:36 PM, Stefano Lattarini

Post by Stefano Lattarini
According to the Autoconf manual, the Tru64/OSF 5.1 sh might abort if
the above is run and the /etc/redhat-release file doesn't exist, since
that shell treats 'read' as a special (in POSIX sense) built-in. See
<git.savannah.gnu.org/cgit/automake.git/commit/?id=080efc9>

Good to know, thanks for the tip.

Post by Stefano Lattarini
In addition, some other brain-dead /bin/sh shells (yes, I'm looking at
you, Solaris) seem to run commands specified in a stderr-redirected
$ /bin/sh -c 'a=ko; { a=ok; }; echo $a'
ok
$ /bin/sh -c 'a=ko; { a=ok; } 2>/dev/null; echo $a'
ko
Not sure how all of this is still relevant today, though (and it
certainly gives yet more good reasons to have Autoconf require a
POSIX shell ... ;-)

Ug, maybe best to leave my original line...

Thanks for the help.

Cheers

Adam

[Adam Mercer]

Post by Eric Blake
{ read redhat_release < /etc/redhat-release; } 2>/dev/null
Whether that's deemed any simpler, though, is a matter of taste. Not to
mention that use of 'read' like this is limited to cases where you know
you are reading a one-line file (when present).

I believe this is the case... so this is an option.

Cheers

Adam