Bug 19747 - Bash's builtin function "read" does not set the variable
Summary: Bash's builtin function "read" does not set the variable
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 7.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
: 20564 21902 42282 59222 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-10-25 13:04 UTC by danmcnaul
Modified: 2007-04-18 16:29 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2000-10-26 12:25:03 UTC


Attachments (Terms of Use)

Description danmcnaul 2000-10-25 13:04:40 UTC
PROBLEM:
The bash builtin function read doesn't seem to work.  Consider the 
following:

A configuration file named "serv.conf" that contains:
BASE_DIR=/usr/topms
TOPMS_BIN=bin
TOPMS_UNIT=840

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.

WORK-AROUND:
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 14:03:37 UTC
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 20:28:05 UTC
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".

Sorry

McNaul

Comment 3 danmcnaul 2000-10-26 11:48:36 UTC
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?

McNaul

Comment 4 Tim Waugh 2000-10-26 12:24:56 UTC
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
subshell)."

So it isn't really a bug in bash, as far as I can see.

Comment 5 Alan Cox 2000-10-27 16:14:09 UTC
It isnt a bash bug

do

foo|bar| (read A; echo $A)


Comment 6 danmcnaul 2000-10-27 20:58:21 UTC
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 09:46:24 UTC
*** Bug 20564 has been marked as a duplicate of this bug. ***

Comment 8 Karsten Hopp 2000-12-12 16:47:24 UTC
*** Bug 21902 has been marked as a duplicate of this bug. ***

Comment 9 Bernhard Rosenkraenzer 2001-05-28 07:01:55 UTC
*** Bug 42282 has been marked as a duplicate of this bug. ***

Comment 10 Bernhard Rosenkraenzer 2002-02-25 11:22:48 UTC
*** 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.