From: David W. Hodgins on
On Wed, 06 Jan 2010 21:18:42 -0500, Douglas Alan <darkwater42(a)gmail.com> wrote:

> that doesn't fix filename completion, which was what I've been asking
> about all along. Filename completion, and nothing but filename
> completion.

Sorry. Can you give an example of filename completion where
the difference between physical directory structure and
logical structure causes a problem? I can't think of any
examples, off hand, where this would matter.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
From: Alan Curry on
In article <194fa019-079c-48ac-9e9a-7beb912f146f(a)a15g2000yqm.googlegroups.com>,
Douglas Alan <darkwater42(a)gmail.com> wrote:
>
> Unfortunately, bash still doesn't obey the physical directory
>structure for FILENAME COMPLETION.
>
>I.e., what happens when you press <TAB> to complete the name of a
>file.

Why don't you show us what you meant with an actual example, in which you
have set -P and it still doesn't do what you want?

From: Douglas Alan on
On Jan 6, 6:28 pm, "Chris F.A. Johnson" <cfajohn...(a)gmail.com> wrote:

> > If you type <CR> instead of <TAB>, however, ls will show you the
> > contents of the root directory, as it should.
>
>     No, it shows the contents of shortcuts, as it should.

Then you either didn't follow my instructions, or you have a very
different version of bash from all the ones that I have.

> > $ set -P
> > $ cd shortcuts/etc/..
>
> > Now the working directory is "/". And all is good.
>
>     For me the working directory is now shortcuts, as I would expect
>     (and want).

Then you either didn't follow my instructions, or you have a very
different version of bash from all the ones that I have.

In any case, with all due respect, what you prefer is irrelevant to
this discussion. I'm asking how to configure bash so that it works the
way that *I* want it to, not to configure it the way that *you* want
it to.

When I tell a computer to open the file or directory named "..", then
that's what I want it do to. I don't want it second guessing me. I
know what I'm doing, thank you.

|>ouglas
From: Douglas Alan on
On Jan 6, 9:47 pm, pac...(a)kosh.dhis.org (Alan Curry) wrote:

> Why don't you show us what you meant with an actual example, in which you
> have set -P and it still doesn't do what you want?

I already did, when I wrote previously:

When you type the <TAB>, bash will show you the contents of
"shortcuts", rather than the contents of "/". This is the behavior
that I strongly dislike, and doesn't obey standard Unix semantics.

I.e., bash sees the ".." and decides rather than interpreting it as
the ".." directory entry in the "shortcuts/etc" directory, to
interpret it as just chopping off the previous path component.

|>ouglas

From: Douglas Alan on
On Jan 6, 9:27 pm, "David W. Hodgins" <dwhodg...(a)nomail.afraid.org>
wrote:

> Sorry.   Can you give an example of filename completion where
> the difference between physical directory structure and
> logical structure causes a problem?  I can't think of any
> examples, off hand, where this would matter.

I often have symlink shortcuts that point to various places in the
filesystem, and I *know* where the link points to. I'm using the
symlink as a shortcut, so that I don't have to type as much. When I
use ".." I want to use the UNIX meaning of "open the directory
named ..", which to UNIX also means, "open the parent directory of the
directory where '..' is located".

I know what I'm doing, and I don't want bash second-guessing me. I
don't want bash to interpret ".." as strip off the previous path
component. I want the UNIX meaning of ".." which is "the parent
directory".

Btw, the way I want bash to behave for me is the way the Bourne Shell
behaves, the way that the Korn shell behaves, the way the csh behaves,
the way the tcsh behaves, AND the way that the zsh behaves. So PLEASE
don't tell me that I'm asking for something weird.

I just want bash to behave the same way in this regard as *every*
other shell.

|>ouglas