Re^2: Question: Best practices for packaging scripts

Awesome! Thanks, this is the kind of input I was looking. I agree with you 100% as the applications being a guest on a machine. I do not care about duplication of modules. Disk space these days is cheaper than oil!!!

You mentioned, "Getting the actual location of the script is a bit tricky".

Can't I use "./lib" as the location of modules? It works both on Windows and Unix.

Ash

Comment on Re^2: Question: Best practices for packaging scripts

Replies are listed 'Best First'.
Re^3: Question: Best practices for packaging scripts by ELISHEVA (Prior) on Mar 27, 2009 at 15:02 UTC
Use "./lib" only works if the following two statements are true the current working directory is set to `appdir` the modules are stored in `appdir/lib` The only way to make sure that the current working directory is set to the application directory is to write a script that changes to "known" directory location. But how are you to know that directory location? You could force your user to store that application in a hard coded location, but that really isn't very guest-like. You could let your user choose a location and then set an environment variable during registration, but then you have no way of making sure that the application location and the environment variable stay in sync. You could educate your user about the environment variable, but now you have yet one more thing to teach and your users have yet one more thing that could go wrong. But even if your users were happy with the environment variable, would they be happy with being forced to change directories to the application directory every time the script starts up? And maybe the system is set up so that users can read and execute script files but they are not allowed to go exploring in application directories (e.g. they don't have permission to make the application directory their current working directory)? So in the main it is just more reliable to locate your application script without relying on cd or the current working directory. The script above avoids this by using some tricks to deduce the fully qualified path to the application. Then it appends a relative path. The actual relative path will depend on the layout of the application directory. In the script above, the layout is appdir/bin/myscript.pl - location of script appdir/lib - location of modules The relative path is "../lib". Thus in "$fullPathOfScript/../lib", ".." moves up from the script's own directory to its parent directory, i.e. from `appdir/bin` to `appdir`. "lib" moves back down again to `appdir/lib` Hope that helps, beth	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Question: Best practices for packaging scripts
by ELISHEVA (Prior) on Mar 27, 2009 at 15:02 UTC

Use "./lib" only works if the following two statements are true

the current working directory is set to appdir
the modules are stored in appdir/lib

The only way to make sure that the current working directory is set to the application directory is to write a script that changes to "known" directory location. But how are you to know that directory location? You could force your user to store that application in a hard coded location, but that really isn't very guest-like.

You could let your user choose a location and then set an environment variable during registration, but then you have no way of making sure that the application location and the environment variable stay in sync. You could educate your user about the environment variable, but now you have yet one more thing to teach and your users have yet one more thing that could go wrong.

But even if your users were happy with the environment variable, would they be happy with being forced to change directories to the application directory every time the script starts up? And maybe the system is set up so that users can read and execute script files but they are not allowed to go exploring in application directories (e.g. they don't have permission to make the application directory their current working directory)?

So in the main it is just more reliable to locate your application script without relying on cd or the current working directory. The script above avoids this by using some tricks to deduce the fully qualified path to the application. Then it appends a relative path.

The actual relative path will depend on the layout of the application directory. In the script above, the layout is

appdir/bin/myscript.pl - location of script
appdir/lib - location of modules

The relative path is "../lib". Thus in "$fullPathOfScript/../lib", ".." moves up from the script's own directory to its parent directory, i.e. from appdir/bin to appdir. "lib" moves back down again to appdir/lib

Hope that helps, beth

[reply]
[d/l]
[select]