Bug 487785 - bash: highlight upgrade to 4.1 from 3.2
bash: highlight upgrade to 4.1 from 3.2
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Migration_Guide (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Laura Bailey
: Documentation
Depends On:
Blocks: 562999 588757
  Show dependency treegraph
Reported: 2009-02-27 16:20 EST by Andrew Hecox
Modified: 2013-02-05 18:55 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-04-18 02:04:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew Hecox 2009-02-27 16:20:49 EST
rhel6 will inherit a re-based version of bash, 4.0, whose inclusion should be highlighted for customers wherever we document such things.

The known compatibility issues are highlighted upstream at:


starting at #36 and going down. As of 02/27/2009, the interesting content in that file is:

36. Bash-4.0 now allows process substitution constructs to pass unchanged
    through brace expansion, so any expansion of the contents will have to be
    separately specified, and each process subsitution will have to be
    separately entered.

37. Bash-4.0 now allows SIGCHLD to interrupt the wait builtin, as Posix
    specifies, so the SIGCHLD trap is no longer always invoked once per
    exiting child if you are using `wait' to wait for all children.

38. Since bash-4.0 now follows Posix rules for finding the closing delimiter
    of a $() command substitution, it will not behave as previous versions
    did, but will catch more syntax and parsing errors before spawning a
    subshell to evaluate the command substitution.

39. The programmable completion code uses the same set of delimiting characters
    as readline when breaking the command line into words, rather than the
    set of shell metacharacters, so programmable completion and readline
    should be more consistent.

40. When the read builtin times out, it attempts to assign any input read to
    specified variables, which also causes variables to be set to the empty
    string if there is not enough input.  Previous versions discarded the
    characters read.

41. Beginning with bash-4.0, when one of the commands in a pipeline is killed
    by a SIGINT while executing a command list, the shell acts as if it
    received the interrupt.

42. Bash-4.0 changes the handling of the set -e option so that the shell exits
    if a pipeline fails (and not just if the last command in the failing
    pipeline is a simple command).  This is not as Posix specifies.  There is
    work underway to update this portion of the standard; the bash-4.0
    behavior attempts to capture the consensus at the time of release.
Comment 1 RHEL Product and Program Management 2009-02-27 16:35:14 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
Comment 4 Roman Rakus 2009-03-02 05:47:27 EST
>38. Since bash-4.0 now follows Posix rules for finding the closing delimiter
>    of a $() command substitution, it will not behave as previous versions
>    did, but will catch more syntax and parsing errors before spawning a
>    subshell to evaluate the command substitution.

I think, this would cause problems for customers. In bash-3.2 you may have:
e=$(cat << EOF
echo "$e"

and it's ok, but only in bash-3. In bash-4 you get

./bla.sh: line 2: unexpected EOF while looking for matching `)'
./bla.sh: line 7: syntax error: unexpected end of file

because end of here-document must be alone on line with end of line marker and with no spaces. So the right script should be:
e=$(cat << EOF
echo "$e"
Comment 5 Andrew Hecox 2009-03-02 09:00:37 EST
Ulrich also pointed out:

l.  The shell now has the notion of a `compatibility level', controlled
    by new variables settable by `shopt'.  Setting this variable
    currently restores the bash-3.1 behavior when processing quoted
    strings on the rhs of the `=~' operator to the `[[' command.

this actually covers a 3.1 -> 3.2 change, but may be worth noting.
Comment 6 Andrew Hecox 2009-03-02 09:19:15 EST
reviewing customer issues from the bash 2.x to bash 3.x rebase (EL 3 -> EL4), we had:

 - two issues where a customer started using a bash 3.x feature/fix, updated their scripts, and reported a bug in bash 2.x.
 - one performance issue related to a new feature (multibyte character support)
 - a change (not clear if intentional) in the ./configure options, via the .spec

On the last point, Roman: any changes to the .spec file when you rebased in F11?
Comment 7 Roman Rakus 2009-03-02 09:29:29 EST
Only one change - there is missing bash-doc. I don't generate it during building, user can generate it by himself.
Comment 8 Andrew Hecox 2009-03-02 10:19:50 EST
you mean the .ps files in /usr/share/doc/bash*/ ?
Comment 9 Roman Rakus 2009-03-02 11:23:11 EST
Comment 10 Andrew Hecox 2009-05-01 07:35:39 EDT
from NEWS

m.  The `ulimit' builtin now has new -b (socket buffer size) and -T (number
    of threads) options.

I don't see these options in the rawhide version of bash though ..
Comment 11 Roman Rakus 2010-01-26 11:06:07 EST
E14) Why does quoting the pattern argument to the regular expression matching
     conditional operator (=~) cause regexp matching to stop working?

In versions of bash prior to bash-3.2, the effect of quoting the regular
expression argument to the [[ command's =~ operator was not specified.
The practical effect was that double-quoting the pattern argument required
backslashes to quote special pattern characters, which interfered with the
backslash processing performed by double-quoted word expansion and was
inconsistent with how the == shell pattern matching operator treated
quoted characters.

In bash-3.2, the shell was changed to internally quote characters in single-
and double-quoted string arguments to the =~ operator, which suppresses the
special meaning of the characters special to regular expression processing
(`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^', and `$') and forces
them to be matched literally.  This is consistent with how the `==' pattern
matching operator treats quoted portions of its pattern argument.

Since the treatment of quoted string arguments was changed, several issues
have arisen, chief among them the problem of white space in pattern arguments
and the differing treatment of quoted strings between bash-3.1 and bash-3.2.
Both problems may be solved by using a shell variable to hold the pattern.
Since word splitting is not performed when expanding shell variables in all
operands of the [[ command, this allows users to quote patterns as they wish
when assigning the variable, then expand the values to a single string that
may contain whitespace.  The first problem may be solved by using backslashes
or any other quoting mechanism to escape the white space in the patterns.

Bash-4.0 introduces the concept of a `compatibility level', controlled by
several options to the `shopt' builtin.  If the `compat31' option is enabled,
bash reverts to the bash-3.1 behavior with respect to quoting the rhs of
the =~ operator.
Comment 14 Roman Rakus 2010-02-12 04:39:35 EST
(In reply to comment #0)
43. Bash-4.0 fixes a Posix mode bug that caused the . (source) builtin to
    search the current directory for its filename argument, even if "." is
    not in $PATH.  Posix says that the shell shouldn't look in $PWD in this

44. Bash-4.1 uses the current locale when comparing strings using the < and
    > operators to the `[[' command.  This can be reverted to the previous
    behavior by setting one of the `compatNN' shopt options.
Comment 16 Scott Radvan 2010-04-18 02:04:28 EDT
covered in migration guide for beta

Note You need to log in before you can comment on or make changes to this bug.