Web lists-archives.com

Re: BASH 4.4 mapfile/readarray/read builtins mis-behaving with pipe [edit] documentation bug

Reply to Eric Blake,

At this time, I do not have a Linux image available to me.   If you saw the same behavior on Fedora, then I suggest the behavior originates upstream at or close the the GNU source-code level.

Mr. Penny's response asserted the observed behavior "is intended behavior", in which case there should exist a GNU specification document describing the intended pipe STDIN re-direction restrictions for 'mapfile', 'read' and possibly other "builtins". Lacking such a reference nothing can be said about intent. Implementation-as-intent implies errors and conceptual and behavioral  inconsistencies in the implementation were intended. I decline to think that of the distributed BASH maintenance team. He provided a reference to http://mywiki.wooledge.org/BashFAQ/024, where, if you read the page, the behavior inconsistency I reported is shown under the heading of "More broken stuff:".  I take that "More broken stuff:" opinion to mean yet others read the same surface discrepancy between doc and behavior as I did.

I believe what we have at this point is:

A) GNU doc lacking nuance, attention to consistent terminology, and helpful rule-statement to code example/counter-example illustrations adjacent to rule statements.  For a doc counter-example, the Open Group doc at http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html does make an effort to distinguish behaviors between "2.14 Special Built-In Utilities" and "2.9.1 Simple Commands" whereas the GNU doc indiscriminately mixes the words "commands" (section 3.2) and "builtin" and "command" and the phrase "builtin command" (section 4) as if their behaviors are identical under the section 4 title of "Shell Builtin Commands" (https://www.gnu.org/software/bash/manual/html_node/Shell-Builtin-Commands.html#Shell-Builtin-Commands). The GNU doc for shopt lastpipeis fairly opaque unless you have deep knowledge and that knowledge is cued when considering the possible meanings of "current shell environment" for built-ins (same process) vs. external child-process executables.

B) However conceptually inconsistent, an obsessive BASH doc reader could imply the observed bash built-ins behavior by integrating multiple hints and rule statements scattered across the GNU doc and then, crucially, doubting the plain meaning of the unqualified doc statements of "Read lines from the standard input..." .

Thank you for your response.


UN*X Since '85

On 7/20/2018 12:08 PM, Eric Blake wrote:
On 07/17/2018 08:52 PM, BloomingAzaleas wrote:
Reply to Steven Penny <svnpenn at gmail dot com>:

    no mis-behaving: this is intended behavior - you yourself have given     workarounds: either redirect output to a file that can be later read, or pipe to     command grouping ala {} or () and read stdin from inside the subshell

I suggest the following adjustment to the man pages inserting a parenthetical cue regards behavior in pipes:

Is the behavior you are complaining about unique to Cygwin, or can it be reproduced on a GNU/Linux box?  If the latter, then an upstream bug report is better than asking for a cygwin-specific patch.  [Hint - as the maintainer of the cygwin bash port, I don't recall adding any cygwin-specific tweaks for mapfile - and a quick test on Fedora shows the same behaviors]

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