[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Assigning command output to a variable
From: |
Stefano Lattarini |
Subject: |
Re: Assigning command output to a variable |
Date: |
Mon, 19 Nov 2012 20:36:47 +0100 |
On 11/19/2012 07:36 PM, Eric Blake wrote:
> On 11/19/2012 10:09 AM, Adam Mercer wrote:
>> 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?
>
> 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).
>
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