top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

symlink for a command - affected by its location

0 votes

I created a symlink for an executable in /usr/bin which didnt work. But I created the same in /usr/local/bin which worked the way I expected. How are these two different?

Both the above locations are present in my $PATH.

posted May 17, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

Where was the symlink to, how did you create it, and what happened
when "it didn't work"? Do you still have the creation commands in your

answer May 17, 2013 by anonymous
Actual location of command- ~/Sources/nodejs/bin/node
Command -   cd "-->till bin "
                   sudo ln -s node /usr/bin  [executing node didnt work]
                   sudo ln -s node /usr/local/bin  [executing node worked as expected]
Similar Questions
+1 vote

Apache/Tomcat (by default) does not allow symbolic linking (nice as it can cross mounted file systems) except in the top apache/lib directory. I use hard links in the Application/WEB-INF/lib directories to reduce copying and help me manage things.

HOWEVER, some applications have special needs - e.g. pictures. You don't want to always distribute these with the release of the application (Application.war file), so symbolic links are the way to go (except for MS land, sorry). The nice solution to this is:

which must contain at least the two below lines:

However this allows ALL symbolic linking in the Application directory. I agree with the developers that this is dangerous.

Is there some way to allow linking in just ONE sub-directory of the Application?
- e.g. .../webapps/Application/images

This would allow all I need to have local images for the application without endangering other things using a symbolic link.

+1 vote

Any thoughts regarding supporting symlinks in SVN on Windows? Windows has supported symlinks since Vista:

Supporting cross-platform symlinks where possible will ease some compatibility pain for cross-platform development.