From: ericblake AT comcast DOT net (Eric Blake)
To: cygwin AT cygwin DOT com
Subject: Re: Shell (bash, (pd)ksh, zsh, /not/ ash) + exec + here-doc +redirect == trouble!
Date: Wed, 25 Jan 2006 15:48:37 +0000
Message-Id: <012520061548.27768.43D79DD500077D3900006C7822064246130A050E040D0C079D0A@comcast.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

> You might want to quote <<'EOSH', but that's not the cause of your
> problem.  Here's a funny thing:
> 
> #!/bin/bash
> exec 5<&0 /bin/bash <<'EOSH'
> echo "First exec: Done."
> cat
> exec 0<&5
> echo "Second exec: Done."
> exit 0
> EOSH
> 
> works for me.  Don't ask me why, though.  Perhaps Eric will chime in.

Define "works for me".

$ ./exectest.sh 
First exec: Done.
exec 0<&5
echo "Second exec: Done."
exit 0

Here, the cat uses fd 0 (which is still set to the pipe from the
here-doc), and consumes it by echoing the remainder of
the here-doc to stdout, so that when /bin/bash goes
to read the next line, fd 0 is at EOF, and you never execute
the "exec 0<&5" line in the shell.  Thus, the process never
tries to duplicate fd 5 back to fd 0, and your example no longer
hangs waiting for input from the terminal.  But it doesn't do what
was originally intended (that is, allow /bin/bash to execute
the remainder of the here-doc).

--
Eric Blake

--
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/