total weirdness? "cd dist"

Can anyone explain this? This doesn't happen on my i386 box.
Maybe I'm
just dense and I'm missing something:

roottaz:/root # ls
.cshrc              .klogin             .profile           
dmesg.current.out
.cshrc.good         .login              .shrc              
pkgpath
.cvspass            .lsof_taz           .ssh
roottaz:/root # cd dist
/usr/src/sys/dist
roottaz:/usr/src/sys/dist # pwd
/usr/src/sys/dist
roottaz:/usr/src/sys/dist # ls
CVS    acpica ipf    pf
roottaz:/usr/src/sys/dist #

What the heck? This works from any directory. I just do
"cd dist" as
root, and there I go. I logged out and back in and it still
works.

Doesn't work with bash, but does work with tcsh and regular
csh. I'm
normally using tcsh. I noticed cd was aliased to something,
so I
commented that out and restarted the shell, but still the
same
results. Again, this doesn't happen on my i386 machine.

Weird. But then again, it's entirely possible that I'm
missing something.

Andy

On Mon, 2 Apr 2007, Andy Ruhl wrote:
> Doesn't work with bash, but does work with tcsh and
regular csh. I'm
> normally using tcsh. I noticed cd was aliased to
something, so I
> commented that out and restarted the shell, but still
the same
> results. Again, this doesn't happen on my i386
machine.
>
> Weird. But then again, it's entirely possible that I'm
missing something.

Yes, the cdpath variable. From the tcsh manpage:

      cd [dir ]
      chdir [dir ]
            Change the shell's working directory to
directory dir.
            If  no argument is given, change to the home
directory
            of the user. If dir is a relative pathname  not 
found
            in the current directory, check for it in those
direc-
===>       tories listed in the cdpath variable. If  dir 
is  the
            name  of a shell variable whose value starts
with a /,
            change to the directory named by that value.


  - Hubert (longtime tcsh user)

On 4/2/07, Hubert Feyrer <hubertfeyrer.de> wrote:
> Yes, the cdpath variable. From the tcsh manpage:
>
>       cd [dir ]
>       chdir [dir ]
>             Change the shell's working directory to
directory dir.
>             If  no argument is given, change to the
home directory
>             of the user. If dir is a relative pathname 
not  found
>             in the current directory, check for it in
those direc-
> ===>       tories listed in the cdpath variable. If 
dir  is  the
>             name  of a shell variable whose value
starts with a /,
>             change to the directory named by that
value.

That's it. I had a /usr/src on my cobalt box, but not on my
i386 box.
Here's the variable:

roottaz:/usr # echo $cdpath
/usr/src/sys /usr/src/bin /usr/src/sbin /usr/src/usr.bin
/usr/src/usr.sbin /usr/src/lib /usr/src/libexec
/usr/src/share
/usr/src/local /usr/src/games /usr/src/gnu/usr.bin
/usr/src/gnu/usr.sbin /usr/src/gnu/libexec /usr/src/gnu/lib
/usr/src/gnu/games

I never knew of a such thing as $cdpath.

Andy

I would carefully examine environment. Is dist aliased to
something? it 
appears that it is aliased to /usr/src/sys/dist. It also
appears that it 
is csh/tcsh related. Look what initialization files they use
and grep in 
all of them for dist.

Regards,
Alex


Andy Ruhl wrote:
> Can anyone explain this? This doesn't happen on my i386
box. Maybe I'm
> just dense and I'm missing something:
> 
> roottaz:/root # ls
> .cshrc              .klogin             .profile       
    
> dmesg.current.out
> .cshrc.good         .login              .shrc          
    pkgpath
> .cvspass            .lsof_taz           .ssh
> roottaz:/root # cd dist
> /usr/src/sys/dist
> roottaz:/usr/src/sys/dist # pwd
> /usr/src/sys/dist
> roottaz:/usr/src/sys/dist # ls
> CVS    acpica ipf    pf
> roottaz:/usr/src/sys/dist #
> 
> What the heck? This works from any directory. I just do
"cd dist" as
> root, and there I go. I logged out and back in and it
still works.
> 
> Doesn't work with bash, but does work with tcsh and
regular csh. I'm
> normally using tcsh. I noticed cd was aliased to
something, so I
> commented that out and restarted the shell, but still
the same
> results. Again, this doesn't happen on my i386
machine.
> 
> Weird. But then again, it's entirely possible that I'm
missing something.
> 
> Andy
>