Bug 448508 - Parsing of {} broken; breaks startup scripts
Parsing of {} broken; breaks startup scripts
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: bash (Show other bugs)
5.2
All Linux
low Severity medium
: rc
: ---
Assigned To: Roman Rakus
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-27 06:58 EDT by Klaus Ethgen
Modified: 2014-01-12 19:07 EST (History)
5 users (show)

See Also:
Fixed In Version: bash-3.2-25.el5
Doc Type: Bug Fix
Doc Text:
When using the source builtin at location ".", occasionally, bash opted to preserve internal consistency and abort scripts. This caused bash to abort scripts that assigned values to read-only variables. This is now fixed to ensure that such scripts are now executed as written and not aborted.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-21 06:38:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
bug448508 -- a small script to hit the bug (261 bytes, application/octet-stream)
2008-06-04 04:33 EDT, Klaus Ethgen
no flags Details
Backported bash32-047 patch from upstream (1.54 KB, patch)
2011-01-18 09:46 EST, Roman Rakus
no flags Details | Diff

  None (edit)
Description Klaus Ethgen 2008-05-27 06:58:02 EDT
Description of problem:
With the new bash the parsing of {} is broken. So if I use such constructs in 
my bashrc to accept errors, the bashrc gets immediately stopped at that point.

For example use the bash_completions you have in Fedora (epel version 20060301-
4.el5), the construct

   {
     # These declarations must go within braces in order to be able to silence
     # readonly variable errors.
     BASH_COMPLETION="${BASH_COMPLETION:-/etc/bash_completion}"
     BASH_COMPLETION_DIR="${BASH_COMPLETION_DIR:=/etc/bash_completion.d}"
   } 2>/dev/null || :
   readonly BASH_COMPLETION BASH_COMPLETION_DIR

do work with bash version up to the version in 5.1. With the version in 5.2 it 
breaks after the line "} 2>/dev/null || :". So the "|| :" has no effect at this 
point.

Version-Release number of selected component (if applicable):
3.2-21.el5

How reproducible:
Use the bash_completions told above or setup a startup script with the above 
content and do something after the construct.

Actual results:
It stops and skip all after this construct.

Expected results:
It should work.

Additional info:
I know that bash_completions are not in RHEL5 but the bug is in the new bash 
and not in the completions.
Comment 1 Roman Rakus 2008-05-28 11:26:57 EDT
Unfortunately I can't reproduce it. I have added line: echo "test" at the end
and every time I get echoed "test".
Test script looks:
#! /bin/bash
{
        # These declarations must go within braces in order to be able to silence
        # readonly variable errors.
        BASH_COMPLETION="${BASH_COMPLETION:-/etc/bash_completion}"
        BASH_COMPLETION_DIR="${BASH_COMPLETION_DIR:=/etc/bash_completion.d}"
} 2>/dev/null || :
readonly BASH_COMPLETION BASH_COMPLETION_DIR
echo "test"
Comment 2 Klaus Ethgen 2008-06-04 04:33:49 EDT
Created attachment 308329 [details]
bug448508 -- a small script to hit the bug

I did test it and have a case how to reproduce.

Please save the attached script and do TWICE:
. bug448508
. bug448508

It does only breake when setting stil setted readonly variables. Use of false 
in the braces do not break. But as the "|| :" after the braces it must never 
die!
Comment 3 RHEL Product and Program Management 2008-08-12 08:52:44 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 4 Roman Rakus 2008-08-19 07:31:43 EDT
This behavior occurs in bash 3.2.20 (version 3.2 with patch level 20).
http://www.nabble.com/.-%28source%29-builtin-behavior-changed-when-commands-are-in-%7B%7D-braces-td18997909.html
Here you can see discussion with upstream. There is written that this is rather right behavior (closer what posix specify) then bug.
Comment 5 RHEL Product and Program Management 2008-10-27 14:20:42 EDT
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time.  This request will be
reviewed for a future Red Hat Enterprise Linux release.
Comment 6 Roman Rakus 2009-01-05 10:32:55 EST
After all it is fixed and available in rawhide bash-3.2-31.fc11.
Comment 7 RHEL Product and Program Management 2009-03-26 12:48:58 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 8 RHEL Product and Program Management 2009-11-06 13:43:40 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 10 RHEL Product and Program Management 2010-08-09 14:15:47 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 11 RHEL Product and Program Management 2011-01-11 15:08:53 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 12 RHEL Product and Program Management 2011-01-11 17:18:48 EST
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 13 Roman Rakus 2011-01-18 09:46:35 EST
Created attachment 474067 [details]
Backported bash32-047 patch from upstream
Comment 14 Roman Rakus 2011-02-10 09:59:46 EST
Fixed in bash-3.2-25.el5
Comment 16 Branislav Náter 2011-04-14 03:46:01 EDT
Bugfix successfully verified on package bash-3.2-29.el5 on all supported architectures.
Comment 17 Misha H. Ali 2011-04-20 04:43:15 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When using the `.' (source) builtin, under certain circumstances bash 
was too careful in discarding state to preserve internal consistency. One
effect was that assignments to read-only variables would cause entire 
scripts to be aborted instead of execution of the offending command. 
This is now fixed to ensure that the scripts are not aborted unexpectedly
and execute as expected.
Comment 18 Misha H. Ali 2011-04-20 19:46:37 EDT
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,6 +1 @@
-When using the `.' (source) builtin, under certain circumstances bash 
+When using the source builtin at location ".", occasionally, bash opted to preserve internal consistency and abort scripts. This caused bash to abort scripts that assigned values to read-only variables. This is now fixed to ensure that such scripts are now executed as written and not aborted.-was too careful in discarding state to preserve internal consistency. One
-effect was that assignments to read-only variables would cause entire 
-scripts to be aborted instead of execution of the offending command. 
-This is now fixed to ensure that the scripts are not aborted unexpectedly
-and execute as expected.
Comment 19 errata-xmlrpc 2011-07-21 06:38:10 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-1073.html

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