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