-
assigned issue to
resolve symbolic links to the idp executable
when a symbolic link to idp is made in /usr/local/bin, idp doesn't run because it searches for the kbs executable in that directory.
ingmar@42 ~> idp
/usr/local/bin/idp: line 6: /usr/local/bin/kbs: No such file or directory
This can be resolved by replacing
DIR="$( cd -P "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
with
SOURCE="${BASH_SOURCE[0]}"
while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
SOURCE="$(readlink "$SOURCE")"
[[ $SOURCE != /* ]] && SOURCE="$DIR/$SOURCE" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
done
DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
in the idp startup-script
Comments (10)
-
reporter -
who makes a symbolic link in that directory?
-
reporter The user himself, he could want to make a symbolic link in /usr/local/bin for quick startup of idp. This doesn't work
Pull Request #195 solves this.
-
Why does this not work? I have a symbolic link in /home/broes/bin/idp, also without kbs in that directory and it runs just fine?
-
I also do not agree that such a fix is merged without looking into whether it behaves the same on osx and windows.
-
reporter I don't understand linux links that well, but I only solved the problem because I had it. The top answer at http://stackoverflow.com/questions/59895/can-a-bash-script-tell-what-directory-its-stored-in should explain this.
-
reporter - changed status to resolved
-
Windows is not a problem I guess (it does not use this script, right?)
Good point about osx
-
Trouwens... Ik heb dit getest en op barrel had ik hetzelfde probleem als ingmar: symbolische links werden niet geresolved... Na de fix wel
-
vreemd, geen idee waarom het bij mij wel werkt dan :)
- Log in to comment