On Thu, Jul 08, 2021 at 11:49:11AM -0700, [email protected] wrote:
> I think that there is an omission in the new poplog script. Toward the end,
> PATH is set to $popsys\:$PATH\:$popcom, but $popcom hasn't been defined.
> Harmless, but probably not what was intended.
Yes, good catch.
> > Well, if we want this as install for many users then we need to
> > look for conflicts. Currently there is Lisp implementation
> > called 'clisp', trying to hijack this name may meet fierce
> > resistance from 'clisp' users. I am not sure about 'prolog',
> > but I suspect that in Debian it is used to point to user
> > prefferred Prolog system, which may be different from Poplog.
> > So some diplomacy may be useful here. 'pop11' and 'xved'
> > are probably safe (only used for Poplog).
>
> How about adopting the busybox idea of having several symbolic links to the
> same program, which behaves slightly differently depending on the name by
> which it has been called.
We can do this. More generally, possiblity of using different
names for different behaviours is desirable. There are many
ways to do it:
- aliases in user shell (not all shells have them, but most do)
- wrapper scripts (duplicating poplog script with small tweaks)
- wrapper binaries
- modification do poplog script similar to what you propose
- having table of defaults in basepop11
- having defaults in config scripts, read before loading saved
image
Shell aliases has disadvantage that they would not work from
programs, I am not sure is this is serious problem. Also, each
user needs to set them, which is less desirable than systemwide
installation.
In current times wrapper scripts seem to be accepted method,
but there is cost in execution time (double startup) and
small space cost. There is also disadvantage that scripts
can not be interpreters for #! scripts. Advantage is that
wrappers are easily customized using tekst tools.
Binary wrappers can lower execution cost and may serve
as interpreters for #! scripts. But to change them
one needs to recompile.
Doing "dispatch" in single script whould save hassle and
space of mulitiple wrapper scripts. OTOH multiple
wrappers decouple behaviour from name, which some
folks find desirable. For example users may wish to
rename Poplog "clisp" to "pclisp" or "poplisp"
(with single wrapper one would need to edit wrapper
changing internal logic to a nore complicated one).
Defaults in basepop11 means that to add new defaults user would
have to relink or add wrappers.
With config files one needs to decide where to put them.
In particular, in case of multiple versions of Poplog on
a single machine there is need to avoid conflicts between
configs for different versions.
> Putting the lines
>
> name=`basename ${0}`
> [ $name == 'poplog' ] && [ $# == 1 ] || set $name
>
> near the top of the script would not change its behaviour when called with
> "poplog pop11", nor would it hijack any name not linked to the script. But
> if the user did make the name pop11 be a link to the script, calling just
> "pop11" would have the effect of "poplog pop11".
I think that somewhat different code is needed. For me '==' raises
error. I am not sure of role of "$# = 1". Namely, pop11 (and other
commands) may be run both with and without arguments. But it is
clear that if desired we can implement needed logic.
> A user who wanted prolog
> or clisp to be the poplog version could link those names to the poplog
> script, but a user who wanted other versions wouldn't have to.
>
> This manuever depends on the basename command being present on the user's
> system. I think it's pretty common, but maybe not universal.
> The syntax ${0##*/} does the same thing in bash, but I don't know about
> other shells. Maybe test for the presence of basename in configure and only
> insert the lines if it is found.
I would not worry about "basename", it is pretty standard command.
--
Waldek Hebisch
