On Fri, Jun 20, 2014 at 12:00:02AM +0200, Tim Friske wrote:
While searching for an alternative I came up with the following code
which does not work when I have the shopt -os errexit command line
at the top of my script:
read -d '' -r foobar BARFOO
bla bla
BARFOO
read returns failure
On 6/19/14, 6:00 PM, Tim Friske wrote:
When I try to explicitly return success in case read fails because of
EOF the script indefinitely waits:
read -d '' -r foobar || true BARFOO
bla bla
BARFOO
You have constructed a command where `read' will wait forever for terminal
input and `true'
Hi,
first I want to thank you for your help.
While searching for an alternative I came up with the following code
which does not work when I have the shopt -os errexit command line
at the top of my script:
read -d '' -r foobar BARFOO
bla bla
BARFOO
When I try to explicitly return success in
On Jun 19, 2014 5:00 PM, Tim Friske m...@timfriske.com wrote:
Hi,
first I want to thank you for your help.
While searching for an alternative I came up with the following code
which does not work when I have the shopt -os errexit command line
at the top of my script:
read -d '' -r foobar
I've heard process substitutions considerably complicate parsing. zsh
and ksh93 are the only others that have process substitutions that I
know of, and zsh can't handle unbalanced parentheses in that situation
either.
$ zsh -c $'cat (cat EOF\n(test)(foo\nEOF\n)'
zsh:4: parse error near `(cat
On 6/17/14, 5:54 PM, Tim Friske wrote:
Hi,
see my question
http://unix.stackexchange.com/questions/137506/how-to-combine-bashs-process-substitution-with-here-document
for a description.
Could the described behavior be a bug?
Yes, since bash can parse the same construct without any
On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey chet.ra...@case.edu wrote:
Yes, since bash can parse the same construct without any problems if you
use command substitution, it looks like a bug. I'll take a look.
It brings to mind all those unbalanced paren case..esac bugs that
affected every
On 6/18/14, 4:27 PM, Dan Douglas wrote:
On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey chet.ra...@case.edu wrote:
Yes, since bash can parse the same construct without any problems if you
use command substitution, it looks like a bug. I'll take a look.
It brings to mind all those unbalanced
Hi,
see my question
http://unix.stackexchange.com/questions/137506/how-to-combine-bashs-process-substitution-with-here-document
for a description.
Could the described behavior be a bug?
Kind regards
Tim