+++ This bug was initially created as a clone of Bug #1360888 +++ Description of problem: On my machine I have a bash shell variable called "TOP" defined: $ echo $TOP 0 (Note this is not an environment variable). This breaks various things, in this case the lowRISC initialization script. The variable comes from gluster bash completion script /etc/bash_completion.d/gluster Version-Release number of selected component (if applicable): glusterfs-cli-3.8.0-0.2.rc2.fc24.x86_64 How reproducible: 100% Steps to Reproduce: 1. echo $TOP --- Additional comment from Niels de Vos on 2016-09-12 07:37:16 CEST --- All 3.8.x bugs are now reported against version 3.8 (without .x). For more information, see http://www.gluster.org/pipermail/gluster-devel/2016-September/050859.html --- Additional comment from Anoop C S on 2017-02-21 07:16:52 CET --- (In reply to Richard W.M. Jones from comment #0) > Description of problem: > > On my machine I have a bash shell variable called "TOP" defined: > > $ echo $TOP > 0 > > (Note this is not an environment variable). This breaks > various things, in this case the lowRISC initialization script. > Can you please direct towards this initialization script? And how severe is the issue? > The variable comes from gluster bash completion script > /etc/bash_completion.d/gluster > > Version-Release number of selected component (if applicable): > > glusterfs-cli-3.8.0-0.2.rc2.fc24.x86_64 > > How reproducible: > > 100% > > Steps to Reproduce: > 1. echo $TOP --- Additional comment from Richard W.M. Jones on 2017-02-21 09:26:22 CET --- (In reply to Anoop C S from comment #2) > Can you please direct towards this initialization script? As stated in the original description: /etc/bash_completion.d/gluster from the package glusterfs-cli. In the source, this file is called extras/command-completion/gluster.bash > And how severe is the issue? Annoying more than severe. However it prevents building all the RISC-V upstream software. --- Additional comment from Niels de Vos on 2017-02-21 09:37:39 CET --- It looks like "TOP" is not the only variable that leaks: From <glusterfs.git>/extras/command-completion/gluster.bash: 285 declare FINAL_LIST='' 286 declare LIST='' 287 declare -i TOP=0
> It looks like "TOP" is not the only variable that leaks: > > From <glusterfs.git>/extras/command-completion/gluster.bash: > 285 declare FINAL_LIST='' > 286 declare LIST='' > 287 declare -i TOP=0 What are the different ways in which such variables can be leaked into main script? One way that I can think of is by sourcing the child script(in this case gluster.bash) into main script(whatever it is). Otherwise these variables won't leak to outside world as they are used inside subshell. Please feel free to correct me if I am wrong. @Richard, Are you sourcing the gluster bash completion script into your specific script?
Of course not. Simply starting a new shell shows that $TOP is defined: $ echo $TOP 0
(In reply to Richard W.M. Jones from comment #2) > Of course not. > > Simply starting a new shell shows that $TOP is defined: > > $ echo $TOP > 0 Ok. So these bash completion scripts are being sourced and is available at launch of each session. It's the case that some other bash completion script are also leaking variables to outside world. Every session launch sources bash completion scripts from /etc/bash_completion.d/ via /usr/share/bash-completion/bash_completion[1] which in turn is sourced from /etc/profile.d/bash_completion[2] profile script. [1] https://github.com/scop/bash-completion/blob/master/bash_completion#L2070 [2] https://github.com/scop/bash-completion/blob/master/bash_completion.sh.in#L11 So.. now to /etc/bash_completion.d/gluster, I guess we need to make all those kind of global variables local to its completion script by rearranging the whole logic.
Compiling LineageOS / Android was no longer possible after updating from F25 to F26. export TOP=/mnt/android/lineageos resulted in -bash: export: /mnt/android/lineageos/: syntax error: operand expected (error token is "/mnt/android/lineageos/) -> removing /etc/bash_completion.d/gluster solved the issue. Still I wish I spent debugging 30 minutes somewhere else :D
We're hitting this as well: -bash-4.2$ cat /etc/system-release Red Hat Enterprise Linux Server release 7.2 (Maipo) -bash-4.2$ rpm -q glusterfs-cli glusterfs-cli-3.7.1-16.el7.x86_64 -bash-4.2$ TOP=/abc -bash: /abc: syntax error: operand expected (error token is "/abc") -bash-4.2$ grep "declare -i" /etc/bash_completion.d/gluster declare -i TOP=0 -bash-4.2$ declare +i TOP -bash-4.2$ TOP=/abc -bash-4.2$ It's not just that it is leaked, but that it is declared with "+i" causing bash to interpret it in an integer context from the on. This needs to be fixed. We have build scripts that set TOP=/path and users upgrading from RHEL 6 to RHEL 7 are hitting this problem now. Remove glusterfs-cli doesn't seem to be a good option either as even though we don't really use gluster, we do use libvirt, and libvirt ends up pulling in glusterfs-cli.
I opened this change request upstream on master: https://review.gluster.org/#/c/glusterfs/+/20732/ Once approved, I will pursue requesting that it be backported into RHEL 7. This may mean backport to 3.8 (used by RHEL 7.5), or 3.12 (used by future RHEL 7.x release?). Although I mention 3.7 above, I would be happy just to get it in RHEL 7.5 or 7.6. For prior releases, we'll come up with our own work-around.
REVIEW: https://review.gluster.org/20732 (Fix Bash command completion script to namespace global variables.) posted (#3) for review on master by
The patch looks good, thanks for dealing with this. Once it goes upstream it should easy to get it into RHEL >= 7.7, and less easy for older RHEL 7.
REVISION POSTED: https://review.gluster.org/20752 (Bash integration script should namespace variables) posted (#2) for review on release-4.1 by Anoop C S
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-5.0, please open a new bug report. glusterfs-5.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] https://lists.gluster.org/pipermail/announce/2018-October/000115.html [2] https://www.gluster.org/pipermail/gluster-users/