Symlinks To Current Directory

stoa · 11-19-2015, 09:00 AM

Hi everybody:

I have a question regarding the operation of certain symlinks. My understanding is that, in general, if there is a symlink from the executable /usr/bin/foo to /usr/bin/baz, that an application or script calling foo will be "redirected" and baz will execute.

On my Slackware -current installation, though, there are three symlinks in /usr/include/seamonkey-2.39/ which point to the current directory:

Code:

lrwxrwxrwx  1 root root      1 Nov 15 10:54 nss -> .
lrwxrwxrwx  1 root root      1 Nov 15 10:54 plugin -> .
lrwxrwxrwx  1 root root      1 Nov 15 10:54 xpcom -> .

Can someone explain what happens when an application or script calls one of these files (nss, plugin, or xpcom) and is redirected to the current directory? In other words, what would happen if these symlinks were removed?

Any clarification is greatly appreciated!

bassmadrigal · 11-19-2015, 09:08 AM

This means that any script that is looking for /usr/include/seamonkey-2.39/nss/file.so will be redirected to /usr/include/seamonkey-2.39/file.so

It basically allows all the files that normally reside in those directories to sit in the parent directory. I think this was done because some programs expect it one way and others expect it the other way. One location was probably deprecated, but not all programs were updated to adjust the file locations, so Pat decided to just have them all reside in the same folder.

GazL · 11-19-2015, 10:10 AM

Nothing should go looking for a .so under /usr/include/... This is probably just about ensuring some old software(s) that use bits of seamonkey still compile.

There are over 2600 header files copied into that directory by the seamonkey slackbuild. Must have been a reason for it sometime in the past, but now we have a separate mozilla-nss package do we really need all this stuff included in seamonkey as well? It all feels kind of ugly, especially as it can lead to recursive nonsense like /usr/include/seamonkey/nss/nss/nss/plugins/nss/plugins/plugins/nss/...

This is not an area I know much about, and there's probably some reason behind it. I'd interested to know what.

In the mean time, I'll just removepkg seamonkey and wait and see if something breaks.

stoa · 11-19-2015, 10:12 AM

Thanks, bass - that explains the "why,", but I think I'm still confused on the "how." Maybe an example will expose my confusion. If I run the command

Code:

grep -R plugin /usr/include

I would expect an infinite loop to result. When grep gets to /usr/include/seamonkey-2.39 and finds "plugin," grep should be redirected to the same directory it just searched and find "plugin" again, over and over. But that's not happening; grep is finding "plugin" and happily moving on.

So, where am I going wrong?

GazL · 11-19-2015, 10:19 AM

I don't think you are "going wrong". It's just an ugly hierarchical construct to symlink a directory back onto its parent like that. "cd /usr/include/seamonkey && ln -s nss/*.h . " might have been a cleaner approach to achieving something similar (assuming that the headers were placed in nss in the first place), but that may have resulted in a lot of additional symlinks which is probably why Pat didn't want to do it that way.

Like I said above, I don't really know the background to any of this, just that its ugly.

bassmadrigal · 11-19-2015, 01:46 PM

@GazL, yeah, I forgot it is header files in there, not so files. I didn't bother to check and just wrote up a quick explanation. But as to why it is done, Pat included a quick blurb in the SlackBuild.

Quote:

# compat symlinks
( cd $PKG/usr/include/seamonkey-${VERSION}
# Relocate anything that might be in the nss directory, and replace the directory with a symlink.
# make install was putting an empty directory here, which was breaking other compiles.
if [ -d nss ]; then
mv nss/* .
rmdir nss
fi
ln -sf . nss
ln -sf . plugin
ln -sf . xpcom
)

@stoa, I believe the reason you don't run into an infinite loop with grep is because if you look at the man page for it, it states under the -r option

Quote:

Read all files under each directory, recursively, following symbolic links only if they are on the command line

So, when using the -r option, the only symbolic links it would follow would be the specific ones you specify (ie /usr/include/seamonkey-2.39/nss/ would follow the symbolic link to /usr/include/seamonkey-2.39/, but it wouldn't follow any it found in that directory (including nss)).

stoa · 11-19-2015, 02:28 PM

GazL - thanks for your explanations.

bass - thanks for looking into this further. While I agree with you if the -r option was specified, I specified the -R option just to try and force the point. From grep(1), the -R option:

Code:

Read all files under each directory, recursively.  Follow all symbolic links, unlike -r.

bassmadrigal · 11-19-2015, 05:47 PM

The only logical thing at that point is grep is smart enough to realize if it will be put into an infinite loop, and it prevents it. It could probably be verified digging through the source code, but I am certainly not smart enough to do that.

rknichols · 11-19-2015, 08:07 PM

Quote:

Originally Posted by bassmadrigal

The only logical thing at that point is grep is smart enough to realize if it will be put into an infinite loop, and it prevents it. It could probably be verified digging through the source code, but I am certainly not smart enough to do that.

It does, as does the find command when told to follow symlinks.

Code:

$ ls -ld image
lrwxrwxrwx. 1 rnichols rnichols 1 Jul  8  2007 image -> .
$ grep -R zxzxzxzxzxzx .
grep: warning: ./image: recursive directory loop