Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Q. How do I get bash to respect my physical directory structure?

72 views
Skip to first unread message

Douglas Alan

unread,
Jan 5, 2010, 12:20:33 PM1/5/10
to
If in bash, I do "set -P" then bash follows the "physical directory
structure" when doing "pwd" and "cd .." etc, rather than the "logical
one" that might be defined via symlinks. Unfortunately, bash still
doesn't obey the physical directory structure for filename completion.
How can I get bash to respect my authority on this issue?

Thanks!
|>ouglas

P.S. Unfortunately, the same problem has now afflicted Emacs for
opening files, etc. If anyone also knows how to also tell Emacs to
respect my physical directory structure, then I'd also like to know
the answer to that.

P.P.S. I don't know who decided that having some programs try to
fathom your "logical directory structure" was a good idea, but it's
not! Not unless you can convince every program in the world to do
things this way, since having some programs use your physical
directory structure, and having other ones use your logical directory
structure is a recipe for confusion and annoyance.

Greg Andrews

unread,
Jan 5, 2010, 7:39:55 PM1/5/10
to
Douglas Alan <darkw...@gmail.com> writes:
>
>P.P.S. I don't know who decided that having some programs try to
>fathom your "logical directory structure" was a good idea, but it's
>not! Not unless you can convince every program in the world to do
>things this way, since having some programs use your physical
>directory structure, and having other ones use your logical directory
>structure is a recipe for confusion and annoyance.
>

If I understand you, you find the presence of both physical and
logical directory structures confusing and annoying, and as a result
you don't want programs to use the logical directory structure.

So why don't you remove the logical directory structure?

-Greg
--
::::::::::::: Greg Andrews ::::: ge...@panix.com :::::::::::::
I have a map of the United States that's actual size.
-- Steven Wright

Douglas Alan

unread,
Jan 6, 2010, 2:35:51 PM1/6/10
to
On Jan 5, 7:39 pm, g...@panix.com (Greg Andrews) wrote:
> Douglas Alan <darkwate...@gmail.com> writes:

> >P.P.S. I don't know who decided that having some programs try to
> >fathom your "logical directory structure" was a good idea, but it's
> >not! Not unless you can convince every program in the world to do
> >things this way, since having some programs use your physical
> >directory structure, and having other ones use your logical directory
> >structure is a recipe for confusion and annoyance.
>
> If I understand you, you find the presence of both physical and
> logical directory structures confusing and annoying, and as a result
> you don't want programs to use the logical directory structure.
>
> So why don't you remove the logical directory structure?

I've been using "logical directory structures" just fine for the last
25 years, and I have no intention of not using them, as I find them to
be utterly invaluable. What I find unpleasant is programs trying to be
too smart for their own good and changing behavior that used to be
perfectly well-defined. Now it's not well-defined, as some programs
have apparently to interpret ".." to mean something other than its
native Unix meaning.

I don't have to worry about the new logical/physical structure
dichotomy with tcsh, for instance. It continues to work the way it
always has, which was fine. Sometimes I have to use bash, however, and
when I do, I want to configure it to work correctly. I.e., I want ".."
to mean what Unix says it means, not what bash has decided to
reinterpret it as.

Re, Emacs: It changed its default behavior as of Emacs 23 (or perhaps
22, as I might have skipped 22), and this annoys me as it breaks
things that have worked fine for me for decades.

As long as I can reconfigure things so that they work the way that
have traditionally worked, I really don't care. But if I can't
reconfigure things to work according to traditional Unix semantics,
then that annoys me. "Do What I Mean" is not better than "Do What I
Say".

|>ouglas

Alan Curry

unread,
Jan 6, 2010, 4:20:02 PM1/6/10
to
In article <ea1edbda-d6a1-4348...@34g2000yqp.googlegroups.com>,

Douglas Alan <darkw...@gmail.com> wrote:
>
>I don't have to worry about the new logical/physical structure
>dichotomy with tcsh, for instance.

tcsh had "set symlinks=chase", "set symlinks=ignore", "set symlinks=expand"
a long time ago. The "expand" option is even crazier than anything bash can
do.

You'd probably get better advice if you provided an actual example of
misbehavior instead of just ranting. Some kind of repeatable experiment.

Douglas Alan

unread,
Jan 6, 2010, 5:42:18 PM1/6/10
to
On Jan 6, 4:20 pm, pac...@kosh.dhis.org (Alan Curry) wrote:

> tcsh had "set symlinks=chase", "set symlinks=ignore", "set symlinks=expand"
> a long time ago. The "expand" option is even crazier than anything bash can
> do.

(1) These aren't set to something DWIMy by default. By default, tcsh
obeys standard Unix semantics. (2) If someone were to set these to a
DWIMy mode for me (e.g., in a system dot file), these options are well
documented, easy to find, and the variable is called, intuitively
enough, "symlinks".

I having nothing against DWIMy features as long as they are opt-in,
rather than opt-out. Or worst of all, no opt at all.

> You'd probably get better advice if you provided an actual example of
> misbehavior instead of just ranting. Some kind of repeatable experiment.

$ mkdir shortcuts
$ ln -s /etc shortcuts
$ ls shortcuts/etc/../<TAB>

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.

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

Now if you do

$ cd shortcuts/etc/..

the working directory will now be "shortcuts", rather than "/". I
strongly dislike this, but fortunately this behavior can be fixed via
"set -P".

$ set -P
$ cd shortcuts/etc/..

Now the working directory is "/". And all is good. (Modulo bash
filename completion and Emacs.)

|>ouglas


David W. Hodgins

unread,
Jan 6, 2010, 6:04:17 PM1/6/10
to
On Wed, 06 Jan 2010 14:35:51 -0500, Douglas Alan <darkw...@gmail.com> wrote:

> when I do, I want to configure it to work correctly. I.e., I want ".."
> to mean what Unix says it means, not what bash has decided to
> reinterpret it as.

Add the following to ~/.bashrc ...
cd() {
builtin cd -P $@
}

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.)

Chris F.A. Johnson

unread,
Jan 6, 2010, 6:28:16 PM1/6/10
to
On 2010-01-06, Douglas Alan wrote:

> On Jan 6, 4:20?pm, pac...@kosh.dhis.org (Alan Curry) wrote:
>
>> tcsh had "set symlinks=chase", "set symlinks=ignore", "set symlinks=expand"
>> a long time ago. The "expand" option is even crazier than anything bash can
>> do.
>
> (1) These aren't set to something DWIMy by default. By default, tcsh
> obeys standard Unix semantics. (2) If someone were to set these to a
> DWIMy mode for me (e.g., in a system dot file), these options are well
> documented, easy to find, and the variable is called, intuitively
> enough, "symlinks".
>
> I having nothing against DWIMy features as long as they are opt-in,
> rather than opt-out. Or worst of all, no opt at all.
>
>> You'd probably get better advice if you provided an actual example of
>> misbehavior instead of just ranting. Some kind of repeatable experiment.
>
> $ mkdir shortcuts
> $ ln -s /etc shortcuts
> $ ls shortcuts/etc/../<TAB>
>
> 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.

That is what I would expect as well as what I would want.

> 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.

> Now if you do
>
> $ cd shortcuts/etc/..
>
> the working directory will now be "shortcuts", rather than "/". I
> strongly dislike this,

That, too, is what I would expect as well as what I would want.

> but fortunately this behavior can be fixed via
> "set -P".
>
> $ 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).

If tcsh does it differently, that is yet another count against it.

> (Modulo bash filename completion and Emacs.)

Yes, emacs does some things differently (strangely?), but I have
got used to it in that context.

--
Chris F.A. Johnson, author <http://shell.cfajohnson.com/>
===================================================================
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
===== My code in this post, if any, assumes the POSIX locale =====
===== and is released under the GNU General Public Licence =====

Alan Curry

unread,
Jan 6, 2010, 7:24:29 PM1/6/10
to
In article <c18e3af2-4388-417b...@a15g2000yqm.googlegroups.com>,

So in summary, everything behaves normally as long as set -P is used. What
was your complaint?

Douglas Alan

unread,
Jan 6, 2010, 9:15:48 PM1/6/10
to
On Jan 6, 7:24 pm, pac...@kosh.dhis.org (Alan Curry) wrote:

> So in summary, everything behaves normally as long as set -P is used. What
> was your complaint?

As I said in my *original* post on the subject:

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.

|>ouglas

Douglas Alan

unread,
Jan 6, 2010, 9:18:42 PM1/6/10
to
On Jan 6, 6:04 pm, "David W. Hodgins" <dwhodg...@nomail.afraid.org>
wrote:

> On Wed, 06 Jan 2010 14:35:51 -0500, Douglas Alan <darkwate...@gmail.com> wrote:
> > when I do, I want to configure it to work correctly. I.e., I want ".."
> > to mean what Unix says it means, not what bash has decided to
> > reinterpret it as.
>
> Add the following to ~/.bashrc ...
> cd() {
>      builtin cd -P $@
>
> }

Thanks, but actually "set -P" is good enough to accomplish that, and
that doesn't fix filename completion, which was what I've been asking
about all along. Filename completion, and nothing but filename
completion.

|>ouglas

David W. Hodgins

unread,
Jan 6, 2010, 9:27:26 PM1/6/10
to
On Wed, 06 Jan 2010 21:18:42 -0500, Douglas Alan <darkw...@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.

Alan Curry

unread,
Jan 6, 2010, 9:47:08 PM1/6/10
to
In article <194fa019-079c-48ac...@a15g2000yqm.googlegroups.com>,

Douglas Alan <darkw...@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?

Douglas Alan

unread,
Jan 6, 2010, 9:55:10 PM1/6/10
to
On Jan 6, 6:28 pm, "Chris F.A. Johnson" <cfajohn...@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

Douglas Alan

unread,
Jan 6, 2010, 10:00:37 PM1/6/10
to
On Jan 6, 9:47 pm, pac...@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

Douglas Alan

unread,
Jan 6, 2010, 10:08:56 PM1/6/10
to
On Jan 6, 9:27 pm, "David W. Hodgins" <dwhodg...@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

Alan Curry

unread,
Jan 6, 2010, 10:24:34 PM1/6/10
to
In article <63f539f4-4518-4420...@r24g2000yqd.googlegroups.com>,

Douglas Alan <darkw...@gmail.com> wrote:
>On Jan 6, 9:47�pm, pac...@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:

But what you wrote previously when I asked for a repeatable experiment did
not have set -P in it. If you intended for the set -P to be done first, you
should have included it as part of the instructions.

I tried that experiment exactly as you said, and the behavior you described
occurred. Then I did set -P and it behaved differently. Does it not do that
for you?

Douglas Alan

unread,
Jan 6, 2010, 11:02:10 PM1/6/10
to
On Jan 6, 10:24 pm, pac...@kosh.dhis.org (Alan Curry) wrote:

> I tried that experiment exactly as you said, and the behavior you described
> occurred. Then I did set -P and it behaved differently. Does it not do that
> for you?

Hmmm, actually now it does work for me!

When I originally posted about the problem last night, I must have
somehow gotten bash into a confused state, as "set -P" fixed
everything then *except* for filename completion. I found this
exception to be annoying. But now, though, once I do "set -P",
everything is working fine.

Well, thanks!
|>ouglas

jellybean stonerfish

unread,
Jan 7, 2010, 4:41:46 AM1/7/10
to

I am going to try to see if I understand what you mean. This won't be easy
it is late, and well, my nym says enough...
In '/home/js/' I have a symlink '/home/js/pictures' pointing to the
directory '/home/js/multimedia/pics'

$pwd
/home/js
$ls -l pictures
lrwxrwxrwx 1 js js 24 2008-04-01 22:01 pictures -> /home/js/multimedia/pics

First I 'cd' directly into the '/home/js/multimedia/pics/' directory,
Then use 'cd ..' and end up in '/home/js/multimedia' as I should.

$cd /home/js/multimedia/pics/
$pwd
/home/js/multimedia/pics
$cd ..
$pwd
/home/js/multimedia

Now, if I us the symlink '/home/js/pictures' I end up in the same
directory, '/home/js/multimedia/pics', but it acts like a different
place. 'pwd' returns '/home/js/pictures' and 'cd ..' leaves me in
'/home/js' And you don't like this behavior?

$cd /home/js/pictures
$pwd
/home/js/pictures
$cd ..
$pwd
/home/js

Or is it the failing of 'bash completion' after using 'cd /home/js/pics'
Hitting tab with 'cd ..' gives me no extra options.
If I 'cd' into '/home/js/multimedia/pics' then 'bash completion' works
fine on a 'cd ..'

jellybean stonerfish

unread,
Jan 7, 2010, 4:50:52 AM1/7/10
to
On Thu, 07 Jan 2010 09:41:46 +0000, jellybean stonerfish wrote:


> Or is it the failing of 'bash completion' after using 'cd /home/js/pics'
> Hitting tab with 'cd ..' gives me no extra options. If I 'cd' into
> '/home/js/multimedia/pics' then 'bash completion' works fine on a 'cd
> ..'

I should mention that 'set -P' does fix this failed competion, but only
because of the other effects of 'set -P'. Namely sending me to and acting
like I am in '/home/js/multimedia/pics' when using 'cd /home/js/pics'


Douglas Alan

unread,
Jan 7, 2010, 10:12:45 AM1/7/10
to
On Jan 7, 4:41 am, jellybean stonerfish <stonerf...@geocities.com>
wrote:

> First I 'cd' directly into the '/home/js/multimedia/pics/' directory,
> Then use 'cd ..' and end up in '/home/js/multimedia' as I should.
>
> $cd /home/js/multimedia/pics/
> $pwd
> /home/js/multimedia/pics
> $cd ..
> $pwd
> /home/js/multimedia
>
> Now, if I us the symlink '/home/js/pictures' I end up in the same
> directory, '/home/js/multimedia/pics', but it acts like a different
> place. 'pwd' returns '/home/js/pictures' and 'cd ..' leaves me in
> '/home/js'  And you don't like this behavior?

Precisely so, but as it turns out "set -P" fixes everything to work
the way I want it to. (I.e., as every other shell behaves.) At the
time I made my initial query, "set -P" had fixed everything for me
*except* for filename completion, and I couldn't figure out how to fix
filename completion. But I guess I had been fiddling with bash too
much and somehow confused it. With a fresh bash, "set -P" does the job
on everything including filename completion. (Or at least I haven't
yet noticed something that "set -P" doesn't quite fix.)

|>ouglas

Stephane CHAZELAS

unread,
Jan 7, 2010, 12:39:03 PM1/7/10
to
2010-01-7, 07:12(-08), Douglas Alan:
> On Jan 7, 4:41ï¿œam, jellybean stonerfish <stonerf...@geocities.com>

> wrote:
>
>> First I 'cd' directly into the '/home/js/multimedia/pics/' directory,
>> Then use 'cd ..' and end up in '/home/js/multimedia' as I should.
>>
>> $cd /home/js/multimedia/pics/
>> $pwd
>> /home/js/multimedia/pics
>> $cd ..
>> $pwd
>> /home/js/multimedia
>>
>> Now, if I us the symlink '/home/js/pictures' I end up in the same
>> directory, '/home/js/multimedia/pics', but it acts like a different
>> place. 'pwd' returns '/home/js/pictures' and 'cd ..' leaves me in
>> '/home/js' ï¿œAnd you don't like this behavior?

>
> Precisely so, but as it turns out "set -P" fixes everything to work
> the way I want it to. (I.e., as every other shell behaves.)
[...]

Although I agree with you that this behavior is annoying, it is
a behavior that has been found since the 80s, that was
introduced by the Korn shell, and even standardized by
POSIX.

So all the POSIX shells (bash, ksh, pdksh, posh, mksh, zsh,
recent ash...) behave like that and bash is not the one to
blame here.

That's the reason why in POSIX scripts, you have to write:

cd -P -- "$dir"
instead of
cd -- "$dir"

to get the same behavior as in other programming languages (and
a consistent behavior).

--
Stï¿œphane

Douglas Alan

unread,
Jan 7, 2010, 1:54:09 PM1/7/10
to
On Jan 7, 12:39 pm, Stephane CHAZELAS <stephane_chaze...@yahoo.fr>
wrote:

> So all the POSIX shells (bash, ksh, pdksh, posh, mksh, zsh,
> recent ash...) behave like that and bash is not the one to
> blame here.
>
> That's the reason why in POSIX scripts, you have to write:
>
> cd -P -- "$dir"
> instead of
> cd -- "$dir"
>
> to get the same behavior as in other programming languages (and
> a consistent behavior).

Hmmm, I didn't try cd in these other shells previously, but I did try
filename completion in ksh and zsh (not to mention tcsh, which I use
every day), and they do filename completion according to the physical
directory structure. (At least on my Mac.)

I just tried cd in ksh and zsh, and you're right. Which means that ksh
and zsh are just plain broken because they don't behave consistently.

And the posix folks are less that brilliant, if you ask me, for
requiring behavior that is inconsistent with normal Unix semantics and
with "real" programming languages.

Not that I have anything against having a way to navigate your
"logical directory structure", but they shouldn't have overloaded that
by default onto a notation that was already well defined.

And while they were at it, they should have required a "back"
function, like web browsers have. So that you might do "cd --back" to
retrace your cd steps.

|>ouglas

Janis Papanagnou

unread,
Jan 7, 2010, 2:18:01 PM1/7/10
to
Douglas Alan wrote:
> [...]

>
> And while they were at it, they should have required a "back"
> function, like web browsers have. So that you might do "cd --back" to
> retrace your cd steps.

There's at least the cd - to get back to the previous directory, so
you can switch forth and back, at least.

WRT a stack of visited directories; there's always (since decades) been
the pushd/popd/dirs functions available (though not as builtins, usually).

Janis

>
> |>ouglas
>

Stephane CHAZELAS

unread,
Jan 7, 2010, 3:02:37 PM1/7/10
to
2010-01-07, 20:18(+01), Janis Papanagnou:
[...]

> WRT a stack of visited directories; there's always (since decades) been
> the pushd/popd/dirs functions available (though not as builtins, usually).
[...]

pushd and popd are built in tcsh, zsh and bash. zsh also has the
~1, ~-1, ~2... expansions for the directory stack.

--
Stï¿œphane

pk

unread,
Jan 7, 2010, 3:40:34 PM1/7/10
to
Douglas Alan wrote:

you may try asking on the bug-bash mailing list, perhaps adding to a recent
thread that, as a matter of fact, is about a similar problem:

http://lists.gnu.org/archive/html/bug-bash/2010-01/msg00002.html

0 new messages