Red Hat Bugzilla – Bug 448508
Parsing of {} broken; breaks startup scripts
Last modified: 2014-01-12 19:07:26 EST
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.
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"
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!
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.
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.
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.
After all it is fixed and available in rawhide bash-3.2-31.fc11.
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 "?".
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.
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.
Created attachment 474067 [details] Backported bash32-047 patch from upstream
Fixed in bash-3.2-25.el5
Bugfix successfully verified on package bash-3.2-29.el5 on all supported architectures.
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.
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.
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