Prev: multiple scp using xargs
Next: bash first occurrence in log file
From: David W. Hodgins on 6 Jan 2010 18:04
On Wed, 06 Jan 2010 14:35:51 -0500, Douglas Alan <darkwater42(a)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.)
From: Chris F.A. Johnson on 6 Jan 2010 18:28
On 2010-01-06, Douglas Alan wrote:
> 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.

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 =====
From: Alan Curry on 6 Jan 2010 19:24
In article <c18e3af2-4388-417b-b011-abbe04949fdb(a)a15g2000yqm.googlegroups.com>,
Douglas Alan <darkwater42(a)gmail.com> wrote:
>On Jan 6, 4:20�pm, pac...(a)kosh.dhis.org (Alan Curry) wrote:
>> 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.)
>

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

From: Douglas Alan on 6 Jan 2010 21:15
On Jan 6, 7:24 pm, pac...(a)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
From: Douglas Alan on 6 Jan 2010 21:18
On Jan 6, 6:04 pm, "David W. Hodgins" <dwhodg...(a)nomail.afraid.org>
wrote:

> On Wed, 06 Jan 2010 14:35:51 -0500, Douglas Alan <darkwate...(a)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

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