>> Yeah, it's not meant to be executed. Just to identify the program.
>> Assume a third-party program knows how to use the interface of Gambit's
>> "gsc" command for example. Then it can find an executable like
>> "gsc-gambit" or whatever the name is on some system, and be confident
>> that since the version info says (command "gsc") it can use that command
>> with the "gsc" interface. Likewise, "csi" can be installed as "csi",
>> "csi4", "csi5", "chicken-csi" or something else; all of them would have
>> (command "csi").
>
> While that's able and ingenious special pleading, I'm not sure it makes any
> sense.  Externally, you already know what the command is because you
> executed it with the -V argument; what you need is "scheme-id" to figure
> out what Scheme it is.  Internally, you don't care how to run yourself in
> 99% of cases.

I mean that the command or filename you used to execute the program can
be something weird that isn't the standard name, or even any obvious
derivative of the standard name.

For lila, I intend to have it scan all known command names, but also to
let users tell it about non-standard Scheme commands by symlinking
executables into ~/.config/lila. It's a lot easier if people can make
symlinks by whatever name they like and lila can just run the executable
and have it tell who it is (which Scheme implementation, and whether it
is the interpreter or the compiler or some other tool; of course in
addition to all the other info like the version and such).

(It's generally simplest when executables are as self-contained as
possible. I've long wondered why programs don't store their manual pages
in a special section of their ELF executable. It wouldn't be hard and
would solve the common problem of missing or out-of-sync manual pages.)

So the point of the "scheme-id" and "command" properties in this SRFI is
that the executable name can be any gibberish the user dreamed up, and
the executable will still who it is ;-)

I can also put a carefully curated table of command mappings into lila,
but I'd rather just auto-detect from some output :) I imagine other
tool-smiths would also come to find it easier over time.

> There's going to be a lot of ad hoc things.  For example, I have a script
> "iron" on my system for executing IronScheme (whose command is
> "IronScheme.Console") with certain important switches; it passes all its
> arguments to the executable.  But it could have arguments of its own, which
> would mean that knowing how to talk to IronScheme just isn't enough.

Good point, but it seems these issues are unavoidable with any approach.
If a user has an executable that generally conforms to a standard
interface but has a few booby traps, there's no way for a tool to steer
clear of that apart from things like storing known-good hashes of
standard builds and verifying each executable before running it; or
running a comprehensive test suite.

So if people make wrapper scripts for standard command names, it has to
be their responsibility to make sure each wrapper has standard behavior
to the extent that they care about its behavior. I mean, if I replaced
"find" or "cp" with a non-standard wrapper how could I complain to
anybody if lots of shell scripts broke?

The best solution is to improve the standard executables and scripts
used to invoke each Scheme so that they serve as many use cases as
possible. User wrappers with non-standard behavior need non-standard
names (as your "iron" does). In the case of IronScheme, I don't think
there is currently a standard command to start it on Unix/Mono.

>> Those can be done, but it's only half the battle. Userland ABI values
>> are not as standardized as CPU architectures or OS names. Would GNU
>> tuples have something we could go on? And GNU and BSD do not always like
>> each other's identifiers so there may have to be translation :-| Fun times.
>
> Inevitably so.  The results may not always be what you want them to be.

I'm pretty determined about bringing order to messy problems like this.
It's generally much easier than people think, now that we can search the
web instead of scavenging for old manuals and disks in the physical
world like people used to do. But even with determination, the expected
result is sub-par. "What is a userland ABI" is not a philosophical
question with an immutable answer, but a convenient term whose meaning
changes with what's available.

>> As a separate issue, `uname -a` contains the machine name (uname -n)
>> which is mildly sensitive/personal/organizational information compared
>> to the other stuff. I deliberately left the username and computer name
>> out of the spec, though I'm not sure that's the right call.
>
> Good point.  Never mind uname, then.

Uname still has all the other stuff (uname -s -r -m -p -v) that only
identifies the CPU and OS. But it's probably better to specify those
using a more standardized mapping, since the info from uname varies a
lot by OS.

Unless you have some use cases where the particular values from uname
are important to know, and not just that general kind of information.
Then we can add those uname fields to the SRFI. All properties are
optional, so an extra uname property doesn't do any particular harm.