Bug 19747

Summary:	Bash's builtin function "read" does not set the variable
Product:	[Retired] Red Hat Linux	Reporter:	danmcnaul
Component:	bash	Assignee:	Bernhard Rosenkraenzer <bero>
Status:	CLOSED NOTABUG	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	danmcnaul, twaugh
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-10-26 12:25:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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. ***