First thanks to all for your input!
ralph.ronnquist wrote:I understood hartrock's problem to be how to know the name of the script file currently being evaluated, without hard-coding its name into the script. ...
This is one usecase: e.g. for output of scriptname by logging and getopts.
ralph.ronnquist wrote:For example, hartrock initially refers to "the directory of the script", ...
This is another usecase: being able to load code from other files located relative
to executed script.
Using NEWLISPDIR by storing code relative to it, is not an alternative for code not thought as suited or mature enough to stand for itself (*) as published module. Moreover it needs admin rights and has the risk of overwriting something, if something has to be installed in this area as a precondition for getting some software run (**).
ralph.ronnquist wrote:My suggestion, which (likely) is Linux only, tries to exploit procfs to find the last opened file descriptor (which hangs around a while in procfs even after being closed in the program), and then pick up the file name from there. This method, where it works, locates the canonical path name for that file (i.e., resolving any links), and assumes this to be the name of the script file currently being evaluated, whether mentioned on the command line or loaded recursively or manually.
I think this can be a good solution, if you are limited to Linux-like OSes. But changing it to a working one for other systems - if someone wants to use some software at another kind of OS - is not trivial (it's Linux expert code (and I cannot say, if and what are the restrictions between different Linux or Linux like OSes here)).
xytroxon's first approach chooses the second command line argument, and clips that path name. This is a simple and straight-forward method that usually works, except of course if the script is not the second argument.
This is a show stopper for newlisp calls of scripts with newlisp CLI arguments before them and/or calling multiple scripts.
And xytroxon's second approach provides the current working directory, which also is good if you are sure that the script file resides there.
Such an assumption may or may not hold: which is bad for having flexibility and robustness
at the same time.
My current usecase is https://github.com/hartrock/Inspector
- installation of this app should be as easy as possible,
- to get it run should be as easy and robust
as possible, without the need to write complicated explanations about
- how to adapt paths in scripts for other configurations, and/or
- restrictions about how to call start scripts.
Ideally, I think, the system load function should be modified so as to maintain a push-down list of the files being loaded while they are loaded, and there should be a function (maybe even just load without arguments) that returns that list. Through this, generic code could be written to work out where "sibling" files are for the files being loaded while they are loaded.
I like this idea!
In addition to the possibility to write platform independent code, this would even allow to check for duplicated file loads, which usually are not wanted.
Another point at my wishlist is to have additional info about which (main-args)
index executed script has (interpreter knows, script not): this is good for a robust
getopts (robustness is very important for a good user (and developer, too!) experience, so I'm stressing this point here).
ralph.ronnquist wrote:But still, the benefit of having this might not outweigh the effort of doing that modification?
The interpreter (and its creator ;-) ) has all the knowledge needed; so this shouldn't be very hard: it feels wrong to create hackish workarounds, due to not having important info about script properties, which could be provided by simple interpreter queries. (***)
(*) There may be strong interdependencies between parts of code, nevertheless located in different files. It's not easy to refactor this to modules, standing each for itself.
(**) This may users let hesitate to just try out some unknown software.
(***) Meta: This is my technical
opinion, amongst others arising from praxis: on the other side I'm knowing very well, that even small changes can be impossible, if there is no time to do them.