A common packaging issue I encounter is when a tool is looking for relative resources in its root directory (install directory).
Eg. pkg-name (
/usr/share/pkg-name/pkg-name) is looking for resourceA (
/usr/share/pkg-name/resourceA) so you can't call
/usr/share/pkg-name/pkg-name directly unless your $PWD =
/usr/share/pkg-name/, because if you're elsewhere (eg.
/home/user) that tool will look for
/home/user/resourceA and raise an error. So your are forced to create a wrapper like the following one:
#!/bin/sh cd /usr/share/pkg-name exec pkg-name "\$@"
Now you can call
/usr/bin/pkg-wrapper from whatever you want but a new issue is facing you!
cd /usr/share/pkg-name in your wrapper, $PWD =
/usr/share/pkg-name in the context of the script. So imagine that
pkg-wrapper -o file can write a file, now
pkg-wrapper -o file will try to save the file
/usr/share/pkg-name/file (current/working directory in the script context) and not at
/home/user/file (current/working directory from where you are calling the wrapper). So files are now saved not in the folder you would like and if
/usr/share/pkg-name/ is write protected you will get a permission error anyway.
So you can't use relative file path anymore and are forced to either specify absolute path eg.
pkg-wrapper -o /home/user/file or a little trick like
pkg-wrapper -o "$(pwd)/file" or
pkg-wrapper -o "$PWD/file".
Is there an agnostic way to solve this common issue? If not a way to patch ruby & python to use the "user current directory" rather than the script/process current directory? I already looked bash set options, bundle exec options.
For example a wrapper for a ruby script could be like the following if the
--magicoption option existed to specify the the root directory where to look
#!/bin/sh exec bundle exec /usr/share/pkg-name/pkg-name.rb --magicoption /usr/share/pkg-name/ "\$@"
This is just an example for a ruby package but it's the same issue for any script / binary from any language.