[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: completion of '../' with symlink component in CWD path
From: |
Felix |
Subject: |
Re: completion of '../' with symlink component in CWD path |
Date: |
Sat, 30 Mar 2013 02:06:47 -0700 |
On Fri, 29 Mar 2013 15:30:08 -0600
Bob Proulx <bob@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.