The "\ filename" meta switch

[shivers@xxxxxxxxxxxxx]

    From: Martin Gasbichler <gasbichl@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 
    Adding / filename makes only sense if we have a standard location for
    scheme-script. But can you honestly imagine this will *ever* exist? I
    can't.

Globally, across all systems? No, it seems unlikely.

For a particular distribution or host? Yes, it seems quite likely. Suppose
next year the "Blue Hat" distribution of Linux decides to replace all the
scripts in /etc with winning Scheme scripts. Happy day. They have no trouble
with their #! trigger lines, because in the Blue Hat distribution,
scheme-script is required to live in /bin, just as Red Hat absolutely needs sh
to be in /bin.

George Hacker is building a rescue floppy for his Unix system. He's got 1.4Mb,
max, for his rescue file system. He'd like to fill it up with useful little
programs densely written as Scheme scripts, plus one, small Scheme
interpreter. You are going to require George to throw a copy of /bin/sh onto
his floppy, just to start up his Scheme interpreter? Boom, 26% of his
floppy... gone.

Beth wants to build a home-firewall floppy for *her* Unix system. Same
problem.

Fred is building a little widget with an embedded processor, running a tiny
Unix kernel. He programs everything in Scheme. But he has to throw a copy of
/bin/sh (or some other helper auxiliary) on his widget just to crank up his
programs? Why the unnecessary double indirection and dependence when one will
do? Seems like improper design -- "to run your program, you need an
interpreter *and some other third program*, whose job is just to start up your
intepreter (we could have done it with just the interpreter, but we didn't)."

But these decisions are not your worry. Provide the Unix *mechanism*, and let
people establish the *policy* they want. It is not required by the Unix kernel
that sh live in /bin, or even exist. Don't build in reliance on sh when you
don't *have* to.

    And adding / filename doesn't come for free as you suggested: It will
    complicate the SRFI and therefore be a potential source for
    confusion. The Most General Design (tm) doesn't imply best usability.

It will not confuse programmers who don't use it, since it doesn't interact
with any other switch or part of the system.

Allowing this single switch buys you a lightweight, pure Unix-kernel solution
without in any way affecting the other uses you had in mind. That seems like a
good thing.
    -Olin