public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Andy Rushton <ajr1@ecs.soton.ac.uk>
To: Kevan Gelling <Kevan.Gelling@euphony.co.uk>
Cc: Cygwin mailing list <cygwin@cygwin.com>
Subject: Re: 1.5.9: Trouble with setting variables using 'read' in a script
Date: Thu, 06 May 2004 14:20:00 -0000	[thread overview]
Message-ID: <409A4817.5010001@ecs.soton.ac.uk> (raw)
In-Reply-To: <201BC46BD93D244AB0A910D1203FFC1904B6A873@ecexchange02.euphony.com>

Kevan Gelling wrote:

>I'm having trouble setting variables using the 'read' command in bash.
>
>All of the following lines fail to set $var and return a blank line.
>  - echo "text" | read var ; echo $var
>  - cat file | read var ; echo $var
>  - read var < file | echo $var
>  
>
The problem is that the pipeline is executed by spawning a sub-process 
and running a sub-shell in it. The variable that is being read into is 
actually a copy that exists within that sub-shell, not the original that 
you declared in the script. Variables set in sub-shells cannot be passed 
back to their parent shell (the script itself).

>I can get it work by explicitly declaring the file descriptor with the file
>redirection, but I'd prefer to use a pipe.
>  - read -u 0 var <file ; echo $var
>  
>
This doesn't create a sub-shell, so the variable being read is the one 
in the script.

>Another related quirk, is that variables set within 'while read' loops lose
>their values once the loop ends.  The following example displays "text text"
>within the loop and blank line outside.
>  - echo "text" |\
>    while read
>    do 
>      foo=$REPLY ; bar="text"
>      echo $foo $bar
>    done
>    echo $foo $bar
>  
>
The while loop also becomes a sub-shell. Same problem as the pipeline.

This is a 'feature' of bash and indeed all Bourne-shell derivatives. It 
makes a lot of shell features much harder to use than you would expect.

Incidentally, this is why you cannot write shell scripts to change your 
environment. The script runs in a sub-shell, changes the local copy of 
the environment and then discards the local copy on exit leaving the 
parent shell in the same state as it was in before.

Andy

-- 
Andy Rushton, Southampton, UK

We may eventually come to realize that chastity is no more a virtue
than malnutrition.
		-- Alex Comfort


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

  reply	other threads:[~2004-05-06 14:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-06 13:25 Kevan Gelling
2004-05-06 14:20 ` Andy Rushton [this message]
2004-05-06 14:22 ` 'read' and pipes, was: " Jan Schormann
2004-05-06 15:27 ` cont'd - " Jan Schormann
2004-05-06 16:36 ` Brian Dessent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=409A4817.5010001@ecs.soton.ac.uk \
    --to=ajr1@ecs.soton.ac.uk \
    --cc=Kevan.Gelling@euphony.co.uk \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).