Bug 1264077 - Tilda expansion failing in bash
Tilda expansion failing in bash
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: bash (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Siteshwar Vashisht
BaseOS QE - Apps
Depends On:
Blocks: 1295396 1264802
  Show dependency treegraph
Reported: 2015-09-17 08:55 EDT by Martin Kyral
Modified: 2016-05-17 06:46 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 802565
: 1264802 (view as bug list)
Last Closed: 2016-05-17 06:46:39 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 Martin Kyral 2015-09-17 08:55:53 EDT
The same problem is with bash, too. Under some circumstances, tilda doesn't get expanded properly.

Version-Release number of selected component (if applicable):

+++ This bug was initially created as a clone of Bug #802565 +++

Description of problem:

Tilda expansion fails to take place under certain conditions

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.  create the following script:  (here ~root/bin/date is just a copy of 

    echo $(~root/bin/date)

2.  Execute the script

Actual results:

The first line prints the date, the second line prints an error because ~root is not getting expanded:

/tmp/ksh.bug[3]: ~root/bin/date: not found [No such file or directory]

Expected results:

Both lines should print the date.

Additional info:

If the second line is commented out, then tilda expansion correctly takes place in the third line and the date is printed.

RHEL 5.8 has ksh93t+.  The bug is also showing up in ksh93u+ and AT&T gave me this patch for 93u+:

--- .../sh/macro.c      Tue Feb  7 09:56:20 2012
+++ sh/macro.c  Fri Mar  9 15:58:54 2012
@@ -2700,7 +2700,12 @@
                logins_tree = dtopen(&_Nvdisc,Dtbag);
+       {
+               c = shp->subshell;
+               shp->subshell = 0;
                nv_putval(np, pw->pw_dir,0);
+               shp->subshell = c;
+       }

--- Additional comment from Michal Hlavinka on 2012-03-13 05:30:47 EDT ---

Reproducible and I can confirm that patch fixes this issue.

Modified reproducer:
cd ${HOME}
TMPDIR=$(mktemp -d test-XXXXXX)
cp /bin/echo ${HOME}/${TMPDIR}/echo
if [ "$(~${USER}/${TMPDIR}/echo OK)$(~${USER}/${TMPDIR}/echo OK)$(~${USER}/${TMPDIR}/echo OK)" = OKOKOK ];
  echo "bug fixed"
  echo "bug present"
rm -rf ${TMPDIR}
exit $rc
Comment 1 Martin Kyral 2015-09-17 09:01:45 EDT
Version-Release number of selected component (if applicable):

Comment 3 Siteshwar Vashisht 2016-05-09 12:48:22 EDT
On RHEL 7 I can see that both bash and ksh show same behaviour :

I have this script under /root/root/bin/ :

# cat /root/root/bin/date

and this is the reproducer code :

# cat tmp.sh 
echo $(~root/bin/date)

If I execute the reproducer script, both commands expand to '/root/bin/date' :

root@qeos-126 tmp]# ./tmp.sh 
./tmp.sh: line 2: /root/bin/date: No such file or directory

./tmp.sh: line 3: /root/bin/date: No such file or directory

If I modify the script to run ksh instead of bash :
# cat tmp.sh 
echo $(~root/bin/date)

I get same beahviour, both the commands expands to '/root/bin/date' :

./tmp.sh[2]: /root/bin/date: not found [No such file or directory]

./tmp.sh[3]: /root/bin/date: not found [No such file or directory]

What should be the expected behaviour on RHEL 7 ?
Comment 4 Martin Kyral 2016-05-17 06:46:39 EDT
After some investigation I found out that there is no bug. The failing scenario is the following script:

# cat tmp.sh 
echo $(~${USER}/bin/date)

man page says the following about expansion:

The order of expansions is: brace expansion, tilde expansion, parameter, variable and arithmetic  expansion  and  command substitution (done in a left-to-right fashion), word splitting, and pathname expansion.

Because tilde expansion happens before variable expansion (apparently the opposite order is in ksh), the ~${USER} can't be resolved properly and it is expected.

Thus, this is not a bug. Sorry for the fuss.

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