Prev: multiple scp using xargs
Next: bash first occurrence in log file
From: Douglas Alan on 5 Jan 2010 12:20
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.
From: Greg Andrews on 5 Jan 2010 19:39
Douglas Alan <darkwater42(a)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 ::::: gerg(a)panix.com :::::::::::::
I have a map of the United States that's actual size.
-- Steven Wright
From: Douglas Alan on 6 Jan 2010 14:35
On Jan 5, 7:39 pm, g...(a)panix.com (Greg Andrews) wrote:
> Douglas Alan <darkwate...(a)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
From: Alan Curry on 6 Jan 2010 16:20
In article <ea1edbda-d6a1-4348-a16a-d984efb01a0d(a)34g2000yqp.googlegroups.com>,
Douglas Alan <darkwater42(a)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.

From: Douglas Alan on 6 Jan 2010 17:42
On Jan 6, 4:20 pm, pac...(a)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




 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: multiple scp using xargs
Next: bash first occurrence in log file