On Fri, 29 Mar 2013 15:30:08 -0600 Bob Proulx <b...@proulx.com> wrote:
> Marcel Giannelia wrote: > > 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. > > I consider the 'set -o physical' behavior the canonical and correct > form. Try it. You might like it. Because it isn't possible to have > the shell create a 100% correct facade over the top of everything. Yeah, discovered set -o physical just after posting, and am considering adopting it... but on the other hand, I'm not so sure the facade behaviour has to be all that elaborate. For instance, if I give you the paths '/path/to/directory' and '..' and tell you to append them, you don't need to know anything special to come up with '/path/to'. I think I'd be OK with a "always do path arithmetic" mode which behaves consistently like that, or a "physical" mode. Things being a mish-mash of aspects of both, though, does seem like a bug -- I can't think of a conceptual reason why ">" would, by design, behave differently from tab completion, especially since you can tab-complete its destination. i.e. if you start typing something like cat > ../fo<Tab> and it helpfully completes to cat > ../foo ...then that really should work when you press the return key. ~Felix.
