I just encountered the following behaviour. Set up a directory structure like:
mkdir basedir cd basedir mkdir -p dir1/dir2 ln -s dir1/dir2 dir2link cd dir2link now, you're sitting in dir2link, and you type: cd ../ and hit the Tab key. The possible completions are shown as 'dir1' and 'dir2link', i.e. the contents of basedir. And if you finish the command as: cd ../dir1 It will change to dir1. However, if you instead do this while your current working directory is 'dir2link': echo foo > ../dir1/bar It fails with "No such file or directory". The problem is that some commands are "smart" and "know" how you got to your current working dir -- bash knows that you're in a symlink and that the parent dir of the *symlink* (not the actual directory you're in) is 'basedir'. However, this is not the literal meaning of the '..' directory entry according to the filesystem. Some parts of bash use the "smart" behaviour (cd and completion), and some parts use what the filesystem actually says, i.e. that '..' inside 'dir2' is 'dir1', not 'basedir' (output redirection). ...after thinking about this, I've managed to confuse myself and am not sure which behaviour should be considered correct. ~Felix.