Re: [Bug-apl] #!apl

[Juergen Sauermann]

Hi Kacper, I have not documented the aplscript trick because I see it more as a hack that helps in a specific situation than a fully supported feature. A general problem of symbolic links to the apl binary (which was the use case for introducing the aplscript hack) is that the apl binary computes the paths to other gnu apl components (for example APserver, Gtk_server, and some libraries) from the path to the gnu apl binary, i.e. from argv[0] of the gnu apl binary. If one starts apl via a symlink in a different directory then one has to symlink all the other components as well. If you don't (and who does ?) then gnu apl starts properly but some system variables will fail for non-obvious reasons. The case of apl being installed in a non-standard directory is better handled by setting prefix= in  ./configure than by symlinks, because that will result in a more consistent install. /// Jürgen On 08/21/2018 11:37 PM, Kacper Gutowski wrote: On Tue, Aug 21, 2018 at 04:54:52PM -0300, Hudson Flavio Meneses Lacerda wrote: I presume it works because apl binary is generated inside that directory (apl-1.7/src/), and "." is in your $PATH. So, "#!apl" calls "./apl" inside apl-1.7/src/. That is the case, #!apl will work only when called from directory where the apl interpreter is. Content of PATH is entirely irrelevant, but the "apl" path is resolved using usual rules and it equivalent to "./apl" starting from current working directory at the time you call it (not even relative to location of the file). The typical way to get it to resolve the name using PATH is, of course, to abuse /usr/bin/env, but that's not viable because only one argument may be passed and GNU APL unfortunately requires --script to behave reasonably. Now, using polyglot code is the usual way to get around this (for example tclsh manual recommends this instead of using env), and I like the succinctness of the ⎕EA approach in comparison with some other variants proposed earlier (in 2016), but it could be done much easier by making GNU APL a bit smarter about that. Looks like everyone forgot, but exactly for this reason, since r735, invoking apl as aplscript implies the --script option. $ ln -s "$(which apl)" "${PATH%%:*}/aplscript" $ cat > test.apl << EOF #!/usr/bin/env aplscript 'YOLO' )OFF EOF $ chmod +x test.apl $ ./test.apl YOLO $ Perhaps it should be documented, because it's not. -k

signature.asc
Description: OpenPGP digital signature