Re: Possible bug when combining Bash's process substitution with HERE-document?
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 < bla bla > BARFOO You have constructed a command where `read' will wait forever for terminal input and `true' will run with a here-document as its input. Change the first line to read -d '' -r foobar
Re: Possible bug when combining Bash's process substitution with HERE-document?
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 < bla bla > BARFOO read returns "failure" because it reaches end of file without encountering the delimiter character (0x00). This is why you don't use set -e (or errexit, or trap ERR, or any of the other syntaxes by which this misfeature is invoked). For more fun details, see http://mywiki.wooledge.org/BashFAQ/105 You may be amazed at how incredibly broken set -e actually is. Bourne shell and C were developed at a time when it was NOT the standard practice for programming languages to handle exceptions/errors for you. You need to check the results of each operation yourself.
Re: Possible bug when combining Bash's process substitution with HERE-document?
On Jun 19, 2014 5:00 PM, "Tim Friske" 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 < bla bla > BARFOO > > When I try to explicitly return success in case read fails because of > EOF the script indefinitely waits: > > read -d '' -r foobar || true < bla bla > BARFOO > > Do you know a solution? > > Cheers > Tim > > 2014-06-18 22:35 GMT+02:00 Chet Ramey : > > On 6/18/14, 4:27 PM, Dan Douglas wrote: > >> On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey 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 shell ever. > >> I suppose this might qualify as a bug too? > > > > Yes, with the same fix. > > > > Chet > > > > -- > > ``The lyf so short, the craft so long to lerne.'' - Chaucer > > ``Ars longa, vita brevis'' - Hippocrates > > Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ > Yes. Never use errexit. Use proper error handling.
Re: Possible bug when combining Bash's process substitution with HERE-document?
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 <: > On 6/18/14, 4:27 PM, Dan Douglas wrote: >> On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey 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 shell ever. >> I suppose this might qualify as a bug too? > > Yes, with the same fix. > > Chet > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Possible bug when combining Bash's process substitution with HERE-document?
On 6/18/14, 4:27 PM, Dan Douglas wrote: > On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey 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 shell ever. > I suppose this might qualify as a bug too? Yes, with the same fix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Possible bug when combining Bash's process substitution with HERE-document?
On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey 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 shell ever. I suppose this might qualify as a bug too? bash -c 'cat <(case x in x) echo test; esac)'; sleep 1 bash: process substitution: line 0: syntax error near unexpected token `newline' bash: process substitution: line 0: `case x in x' cat: /dev/fd/63 echo test; esac): No such file or directory
Re: Possible bug when combining Bash's process substitution with HERE-document?
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 problems if you use command substitution, it looks like a bug. I'll take a look. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Possible bug when combining Bash's process substitution with HERE-document?
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 <<"EOF"'
$ ksh -c $'cat <(cat <<"EOF"\n(test)(foo\nEOF\n)'
(test)(foo
This is probably the most directly equivalent workaround:
$ { cat <(cat) <&3-; } 3<&0 <<<'(test)(foo'
(test)(foo
Identical logic except the procsub inherits the heredoc FD from its
parent. The inner cat still gets the heredoc and the outer cat gets
the original stdin, but dodges needing the nested heredoc.
On Tue, Jun 17, 2014 at 4: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?
>
> Kind regards
> Tim
>
Possible bug when combining Bash's process substitution with HERE-document?
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
