Bug 1278156 - bash is inconsistent in respect to symlink followup
bash is inconsistent in respect to symlink followup
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: bash (Show other bugs)
Unspecified Unspecified
low Severity low
: rc
: ---
Assigned To: Siteshwar Vashisht
BaseOS QE - Apps
Depends On:
  Show dependency treegraph
Reported: 2015-11-04 14:27 EST by Marek Haicman
Modified: 2016-05-23 02:33 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-05-23 02:33:04 EDT
Type: Bug
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 Marek Haicman 2015-11-04 14:27:03 EST
Description of problem:
When user is in symlink pointing into directory, there is disparity between behaviour of bash completion and coreutils commands.

Situation [annotated find output]:
./b/c [target dir of symlink]
./c [symlink to absolute ./b/c]

after going into ./c, there is disparity - bash understands .. as original ./, coreutils as ./b.

Bash even tries to use './' in tab completion, but fails when you try to continue to for example ./a [as autocompletion understands a as a file, not as directory]

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

How reproducible:

Steps to Reproduce:
1. Create structure noted above
2. cd c
3a. cat ../[tab][tab]  // now original ./ is displayed
3b. continue autocompletion with a // but it does not behave as directory but as a file [it is autocompleted with space after it - obviously wrong]

and as an illustration of coreutils behavior:
4. cat ../a/A   // failure 'cat: ../a/A: No such file or directory'
5. cat ../../a/A // success

Actual results:
inlined in reproduction steps

Expected results:
autocompletion of ../ looks into ./b/ directory [to be consistent with the rest of utilities]
Comment 2 Siteshwar Vashisht 2016-05-17 06:03:19 EDT
bash follows posix behaviour[1] and it is not aware if the external commands repsect symbolic links in current working directory path.

To avoid this issue you can use 'cd' with '-P' switch, or use 'set -o physical' flag to by default use physical paths in bash.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html

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