Symlinks To Current Directory
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 -> . Any clarification is greatly appreciated! |
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. |
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. ;) |
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 So, where am I going wrong? |
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. |
@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:
Quote:
|
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. |
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.
|
Quote:
Code:
$ ls -ld image |
All times are GMT -5. The time now is 09:35 PM. |