Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
uname output: Linux Cyborg.localdomain 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed
Mar 7 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 4.2
Patch Level: 46
Release Status: release
Description:
I noticed some strange behavior in the DIRSTACK variable (used in
pushd/popd).
`declare -p DIRSTACK`
shows the list of current directories on the stack, as expected.
${DIRSTACK[@]:1} show correctly expanded paths, i.e., âpushd ~/Jenkinsâ
will correctly store "/home/jeremy/jenkins"
However, ${DIRSTACK[0]} does NOT have this behavior, and will encode a
literal tilde, e.g., "~/jenkins"
This behavior is obfuscated by
dirs -v
and
dirs -l
The first option will *always* display the stack with ~ instead of $HOME,
and the second option will *always* display $HOME instead of ~.
This means, for instance, that rearranging the order of the DIRSTACK array
can produce invalid directory targets.
Repeat-By:
mkdir -p ~/some/test/path
cd ~/some/test/path
pushd ~/some/test/
pushd ~/some/
declare -p DIRSTACK
#output will show literal ~ in ${DIRSTACK[0]}
pushd +0 #works, but I believe this is because it just says "don't need to
move"
pushd +1 #works
DIRSTACK[1]=${DIRSTACK[0]}
pushd +1 #fails, "no such file or directory" because ~ isn't expanded
Fix:
Don't store ~ in ${DIRSTACK[0]}. pushd ~/some/ will be correctly expanded,
this just needs to be implemented for the current directory as well. I know you
probably wanted a technical fix here, sorry.
