[CLUE-Tech] Symlink oddity

[Keith Hellman]

--- Matt Gushee <mgushee at havenrock.com> wrote:
> I just discovered that bash (or maybe it's ls and mv) has some peculiar
> behavior WRT to symlinked directories.
> 
> I downloaded a file called popy-2.0.7.tar.gz (it's a PostgreSQL
> interface 
> for Python) to /usr/local/share, when I actually wanted it in
> /usr/local/src. On my system, by the way:
> 
>   bash-2.03$ file /usr/local      
>   /usr/local: symbolic link to /opt/usr.local
>   
> and
> 
>   bash-2.03$ file /usr/local/src
>   /usr/local/src: symbolic link to /.devel/usr.local.src
>   
> [okay, my partitioning scheme is a little odd, but I have my reasons]
> 
> So I do this:
> 
>   bash-2.03$ cd /usr/local/src
>   bash-2.03$ mv ../sh [TAB] -->
>              mv ../share
>              mv ../share/po [TAB] -->
>              mv ../share/popy-2.0.7.tar.gz .
> 
> and get:
> 
>   mv: ../share/popy-2.0.7.tar.gz: No such file or directory
> 
> Well, that's understandable, since there isn't a /.devel/share
> directory. And if I try to do
> 
>   $ ls ../share
> 
> it fails in a similar fashion.  Why, then, does ../share/, etc. appear
> through tab completion? Is this a bug in bash, or is it intentional? If
> it's intentional, what good is it to be able to do tab completion on
> paths that don't actually exist?
>   

You ask the BEST questions!

The crux of the issue is that a symlinked directory (.devel/usr.local.src)
never knows where it has been symlinked to (opt/usr.local/src).  For cl
completion, bash does it's own symlink resolving, which means you actually
see popy through cl.

But when a path (created with the help of bash's cl completion mind you)
is provided to another program (ls, mv, file, cc, ...) it simply tries to
do an open,stat,access or some-such system call on the file path.

This system call is resolved by the filesystem driver containing the true
'src' directory (the filesystem containing .devel/usr.local.src).  It
looks at ../share/popy and says, "Sorry, I don't have this..."

I realized you described most of these facts, I was simply giving them
some algorithmic context for other readers :^)

As for a bug in bash:
* I'm willing to bet there is an option in bash to prevent resolving
symlinks - I took a quick peek at the info page but nothing jumped out at
me.
* It's a bit of a toss-up whether this is a feature or bug:  symlink
resolution is helpful when doing cd ../share, but not helpful in this
case...
* My version of bash is 2.05, and I've noticed that it won't put the
trailing / on the end of symlinked directories that are not resolvable, I
have to put it there myself.  This usually tips me off that something is
fishy...

Dunno if this helps, it's mostly just my two cents...thanks for the
thought provoking morning Matt!



=====
Keith E. Hellman
kehellman at yahoo.com

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com