Bug 19747 - Bash's builtin function "read" does not set the variable
Bash's builtin function "read" does not set the variable
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
David Lawrence
: 20564 21902 42282 59222 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2000-10-25 09:04 EDT by danmcnaul
Modified: 2007-04-18 12:29 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-10-26 08:25:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description danmcnaul 2000-10-25 09:04:40 EDT
The bash builtin function read doesn't seem to work.  Consider the 

A configuration file named "serv.conf" that contains:

Suppose we want to grab the TOPMS_UNIT value, which is 840.  In a script 
(or at the command line) we type

grep BASE_UNIT= serv.conf | sed 's/BASE_UNIT=//' | read UNIT

then we issue

echo $UNIT

UNIT contains "nothing", but should contain 840.

Instead of using "read" one can set the variable UNIT as follows:

UNIT=`grep BASE_UNIT= serv.conf | sed 's/BASE_UNIT=//'`

the issue

echo $UNIT

which will show the correct value was set (840)
Comment 1 Tim Waugh 2000-10-25 10:03:37 EDT
What about:

grep TOPMS_UNIT= serv.conf | sed 's/TOPMS_UNIT=//' | read UNIT

?  Or is that what you were doing?
Comment 2 danmcnaul 2000-10-25 16:28:05 EDT
Oh Jesus,

Yes, that is what I meant.

I went back and retested to make sure I didn't pull a Homer.  In my examples 
where I say "BASE_UNIT=" I meant to say "TOPMS_UNIT".


Comment 3 danmcnaul 2000-10-26 07:48:36 EDT
If you're going to mark the MR as "Resolved, notabug" shouldn't you at least 
explain yourself.  I have scripts that used to work in previous Redhat releases 
that are now failing because of this.  Why is this NOTABUG?

Comment 4 Tim Waugh 2000-10-26 08:24:56 EDT
I misunderstood and thought that your original script was in error.

But this is what the Single UNIX spec says:

"Some systems have implemented the last stage of a pipeline in the current
environment so that commands such as: 

    command | read foo

set variable foo in the current environment. This extension is allowed, but not
required; therefore, a shell programmer should consider a pipeline to be in a
subshell environment, but not depend on it."

And 'man bash' (line 277) says:

"Each  command in a pipeline is executed as a separate process (i.e., in a

So it isn't really a bug in bash, as far as I can see.
Comment 5 Alan Cox 2000-10-27 12:14:09 EDT
It isnt a bash bug


foo|bar| (read A; echo $A)
Comment 6 danmcnaul 2000-10-27 16:58:21 EDT
I agree that this MR should be closed as NOTABUG.

The example given above works to set a variable in the current shell to the 
value expected.  The coding is different, but it works.

Dan McNaul
Comment 7 Bernhard Rosenkraenzer 2000-11-10 04:46:24 EST
*** Bug 20564 has been marked as a duplicate of this bug. ***
Comment 8 Karsten Hopp 2000-12-12 11:47:24 EST
*** Bug 21902 has been marked as a duplicate of this bug. ***
Comment 9 Bernhard Rosenkraenzer 2001-05-28 03:01:55 EDT
*** Bug 42282 has been marked as a duplicate of this bug. ***
Comment 10 Bernhard Rosenkraenzer 2002-02-25 06:22:48 EST
*** Bug 59222 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.