cd, pwd and symlinks

cd, pwd and symlinks

[Hubert Canon]

Hi,

I have strange behaviours with symlinks to directories.

youkaidi ~ % echo $PROMPT
%B%m %~ %#%b 
youkaidi ~ % mkdir foo
youkaidi ~ % mkdir foo/bar
youkaidi ~ % md bar
youkaidi ~ % cd bar
youkaidi ~/bar % ln -s ../foo/bar foo
youkaidi ~/bar % cd foo
youkaidi ~/bar/foo % ls ..
bar
youkaidi ~/bar/foo % pwd
/udd/canon/foo/bar
youkaidi ~/bar/foo % /bin/pwd
/udd/canon/foo/bar
youkaidi ~/bar/foo % cd ..
youkaidi ~/bar % 



when I type `cd ../' followed with TAB, I get the expansion `cd ../bar'
and if I hit ENTER, I get :

youkaidi ~/bar/foo % cd ../bar 
cd: no such file or directory: ../bar

I have no problem with that :

youkaidi ~/bar/foo % cd ..
youkaidi ~/bar % 

But I would like a way to do something like that :

youkaidi ~/bar/foo % cd ./..     
youkaidi ~/foo % 

instead of `youkaidi ~/bar % ', that is going the directory given by
/bin/pwd, i.e. the directory without any symlinks, the same that is
used for the ls command and the completion system.

Re: cd, pwd and symlinks

[Adam Spiers]

Hubert Canon (Hubert.Canon@irisa.fr) wrote:
> Hi,
> 
> I have strange behaviours with symlinks to directories.

[snip]

Put `setopt chaselinks' or `setopt chasedots' in your .zshrc.  From
the info pages:

CHASE_DOTS
     When changing to a directory containing a path segment `..' which
     would otherwise be treated as cancelling the previous segment in
     the path (in other words, `foo/..' would be removed from the path,
     or if `..' is the first part of the path, the last part of $PWD
     would be deleted), instead resolve the path to the physical
     directory.  This option is overridden by CHASE_LINKS.

     For example, suppose /foo/bar is a link to the directory /alt/rod.
     Without this option set, `cd /foo/bar/..' changes to /foo; with it
     set, it changes to /alt.  The same applies if the current directory
     is /foo/bar and `cd ..' is used.  Note that all other symbolic
     links in the path will also be resolved.

CHASE_LINKS (-w)
     Resolve symbolic links to their true values when changing
     directory.  This also has the effect of CHASE_DOTS, i.e. a `..'
     path segment will be treated as referring to the physical parent,
     even if the preceeding path segment is a symbolic link.

Re: cd, pwd and symlinks

[Hubert Canon]

Adam Spiers écrivait :
> Hubert Canon (Hubert.Canon@irisa.fr) wrote:
> > I have strange behaviours with symlinks to directories.
> 
> [snip]
> 
> Put `setopt chaselinks' or `setopt chasedots' in your .zshrc.  From
> the info pages:

Thank you. I didn't see these options.

But I am a bit confused, because I would like that `cd ..' had the
present behaviour (when these options are unset) and that I use
another construct (like `cd ./..' for example) when I want to follow
links.

youkaidi ~ % mkdir foo
youkaidi ~ % mkdir bar
youkaidi ~ % mkdir foo/bar
youkaidi ~ % cd bar
youkaidi ~/bar % ln -s ../foo/bar foo
youkaidi ~/bar % cd foo
youkaidi ~/bar/foo % l ..           # that's why I prefer chase_links unset
bar/
youkaidi ~/bar/foo % cd ..        
youkaidi ~/bar % cd foo             # that's why I prefer chase_dots unset
youkaidi ~/bar/foo % cd ./..
youkaidi ~/foo %                    # this the new behaviour I wish

Re: cd, pwd and symlinks

[Adam Spiers]

Hubert Canon (Hubert.Canon@irisa.fr) wrote:
> But I am a bit confused, because I would like that `cd ..' had the
> present behaviour (when these options are unset) and that I use
> another construct (like `cd ./..' for example) when I want to follow
> links.

Sounds like a reasonable request.  You could implement it with a
function:

  function ccd {
    # Chase Change Directory
    setopt localopts chaselinks
    builtin cd "$@"
  }

and then do 

  % ccd ..

or even as a wrapper around cd, but I'll leave that as an exercise to
the reader :-)

Re: cd, pwd and symlinks

[Adam Spiers]

Adam Spiers, on thelonious (adam@thelonious.new.ox.ac.uk) wrote:
> Hubert Canon (Hubert.Canon@irisa.fr) wrote:
> > But I am a bit confused, because I would like that `cd ..' had the
> > present behaviour (when these options are unset) and that I use
> > another construct (like `cd ./..' for example) when I want to follow
> > links.
> 
> Sounds like a reasonable request.  You could implement it with a
> function:
> 
>   function ccd {
>     # Chase Change Directory
>     setopt localopts chaselinks
>     builtin cd "$@"
>   }
> 
> and then do 
> 
>   % ccd ..
> 
> or even as a wrapper around cd, but I'll leave that as an exercise to
> the reader :-)

This is of course all stupid.  If I had a brain I would have consulted
the manual before giving advice.  Check out the -L and -P options to cd.

Re: cd, pwd and symlinks

[Stefan Monnier]

>>>>> "Adam" == Adam Spiers <adam@thelonious.new.ox.ac.uk> writes:
> Put `setopt chaselinks' or `setopt chasedots' in your .zshrc.  From
> the info pages:

I must say I don't like the names and defaults.  The names give the
impression that chasing links is a very unusual feature while it's the
normal unix behavior.

But apart from that, I'm more often annoyed by `pwd' not checking the
value it returns:

	~/tmp-0% mkdir foo 
	~/tmp-0% cd foo
	tmp/foo-0% mv ../foo ../bar
	tmp/foo-0% pwd
	/home/monnier/tmp/foo
	tmp/foo-0% 

This is with 3.0.6,


	Stefan

Re: cd, pwd and symlinks

[Bart Schaefer]

On Sep 27,  7:05pm, Stefan Monnier wrote:
> Subject: Re: cd, pwd and symlinks
> >>>>> "Adam" == Adam Spiers <adam@thelonious.new.ox.ac.uk> writes:
> > Put `setopt chaselinks' or `setopt chasedots' in your .zshrc.  From
> > the info pages:
> 
> I must say I don't like the names and defaults.  The names give the
> impression that chasing links is a very unusual feature while it's the
> normal unix behavior.

It's not, however, the normal zsh behavior, and has not been for a very long
time.  It may even date back to a specific personal preference of Falstad's;
I don't recall for certain now.

> But apart from that, I'm more often annoyed by `pwd' not checking the
> value it returns

"pwd" is nothing more than a slightly fancified alias for "echo $PWD", and
PWD does not get reset every time zsh prints a prompt (unless you do it in
your precmd function).  Rather, it gets reset every time you "cd".

The builtin pwd in bash and (I think) ksh also have the same behavior.
There is no builtin pwd in tcsh, but tcsh does not reset $cwd following
such a "mv" command.

You can always put

	disable pwd

in your init files somewhere, to force zsh to run the external pwd command
instead.

Re: cd, pwd and symlinks

[Stefan Monnier]

>> I must say I don't like the names and defaults.  The names give the
>> impression that chasing links is a very unusual feature while it's the
>> normal unix behavior.
> It's not, however, the normal zsh behavior, and has not been for a very long
> time.  It may even date back to a specific personal preference of Falstad's;
> I don't recall for certain now.

That's indeed what I'm complaining about.  The default behavior is very
non-unixish which is surprising for a unix-only tool.

> "pwd" is nothing more than a slightly fancified alias for "echo $PWD", and
> PWD does not get reset every time zsh prints a prompt (unless you do it in
> your precmd function).  Rather, it gets reset every time you "cd".

But how hard would it be to have `pwd' do a stat("$PWD") and stat(".")
and compare the inode to make sure the current $PWD is still valid ?


	Stefan

Re: cd, pwd and symlinks

[Rob Windsor]

Verily did "Stefan Monnier" write:

>>> youkaidi ~ % mkdir foo
>>> youkaidi ~ % mkdir foo/bar
>>> youkaidi ~ % md bar
>>> youkaidi ~ % cd bar
>>> youkaidi ~/bar % ln -s ../foo/bar foo
>>> youkaidi ~/bar % cd foo
>>> youkaidi ~/bar/foo % ls ..
>>> bar
*>> youkaidi ~/bar/foo % pwd
*>> /udd/canon/foo/bar
*>> youkaidi ~/bar/foo % /bin/pwd
*>> /udd/canon/foo/bar
*>> youkaidi ~/bar/foo % cd ..
*>> youkaidi ~/bar % 

>> Put `setopt chaselinks' or `setopt chasedots' in your .zshrc.  From
>> the info pages:

> I must say I don't like the names and defaults.  The names give the
> impression that chasing links is a very unusual feature while it's the
> normal unix behavior.

That depends wholly upon the shell.  C-shell variants do it one way, sh
sorta does it like zsh (the items marked with a `*' above are like csh,
but because sh doesn't appear to have a builtin cd(1) or pwd(1)).  Zsh
does it (by default?) the same way that ksh does.

The use of symlinks pointing to subdirs has long been flagged as A Bad
Idea due to the handling of `..', so "ymmv" when you choose to use them.

> But apart from that, I'm more often annoyed by `pwd' not checking the
> value it returns:

> 	~/tmp-0% mkdir foo 
> 	~/tmp-0% cd foo
> 	tmp/foo-0% mv ../foo ../bar
> 	tmp/foo-0% pwd
> 	/home/monnier/tmp/foo
> 	tmp/foo-0% 

> This is with 3.0.6,

And ksh does the same thing.  Again, sh(1) doesn't do this because it
doesn't have a builtin pwd(1).

I'm surely not complaining about how zsh handles either of these behaviors,
I prefer a ksh-on-steriods look and smell for a shell.

-- Rob
----------------------------------------
Internet: windsor@warthog.com                             __o
Life: Rob@Carrollton.Texas.USA.Earth                    _`\<,_
                                                       (_)/ (_)
The weather is here, wish you were beautiful.