Re: Possible bug when combining Bash's process substitution with HERE-document?

[Greg Wooledge]

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

[Chet Ramey]

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' will run with a here-document as its input.  Change the
first line to

read -d '' -r foobar BARFOO || true

-- 
``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: dot gob+extglob bug

[Chet Ramey]

On 6/19/14, 6:47 PM, Ian Kelling wrote:

 The doc says When matching a pathname, the slash character
 must always be matched explicitly.  Shortly thereafter, in the next
 paragraph of the same section, GLOBIGNORE is described, which does not
 treat / as special, but this is not mentioned, and is very unexpected to
 me. Closer inspection, I see same language filenames matching a
 pattern is used in both paragraphs, so I think some clarification is
 needed.

The GLOBIGNORE matching code treats the patterns and strings to be matched
as pathnames, and treats `/' specially (that is, it specifies FNM_PATHNAME
to bash's internal version of fnmatch).  If *a matches scratch/a, for
example, that's a bug in the matching code I will have to identify and fix.
None of `*', `?', or bracket expressions should match a slash.

 And then, another bug or doc clarification. The various [:class:] forms
 don't seem to work at all in GLOBIGNORE.

Yeah, this is a different problem caused by an oversight.  The colon in the
bracket expression is being treated as a pattern delimiter.  I've appended
a patch that fixes this problem.

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/
*** ../bash-4.3-patched/pathexp.c	2014-01-31 09:34:33.0 -0500
--- pathexp.c	2014-06-20 15:33:09.0 -0400
***
*** 539,543 
  return 0;
  
!   n = skip_to_delim (s, i, :, SD_NOJMP|SD_EXTGLOB);
t = substring (s, i, n);
  
--- 539,543 
  return 0;
  
!   n = skip_to_delim (s, i, :, SD_NOJMP|SD_EXTGLOB|SD_GLOB);
t = substring (s, i, n);