Why?  The cost is negligible, the benefits substantial, and the
   alternative you propose is way baroque.

Baroque, to me, is firing up a whole interpreter simply to execute the
interpreter I orginally had in mind. That is applying way more resources to
the task than it needs, by orders of magnitude.

Note, again, that I'm not saying remove the ability to do so. I'm simply
saying that if you introduce one extra switch -- which is already implemented
in fairly portable code -- you can also support direct execution.

The meta-switch is simpler, not more baroque, because it works directly
with the semantics of the *operating system*. Unix. The kernel. The
exec() system call. It doesn't require a whole 'nother software system
to get in on the act in order to work. That is simple & pure.

Get /bin/sh out of the picture as a *required* component.

People actually do occasionally roll oddball reduced Unix systems based on
a kernel with an interestingly different init process & other selection of
binaries. It'd be nice if this scripting standard you are establishing had
no *required* dependencies beyond the Unix kernel.

   Olin>    Also, I'd suggest making the terminator be newline-bang-sharp, not
   Olin>    simply bang-sharp. Makes the possibility of a false positive even
   Olin>    less likely.

   I don't see a great likelihood for a false positive.

I don't either. It would not be a big deal if you went either way. On the
other hand, it would cost nothing to reduce that likelihood further. I think.
I can't think of a way in which newline-bang-sharp would *cost* you anything.
Can anybody else?

   Olin> 5. The draft says
   Olin>      In the case of -srfi7 all specifications of filenames
   Olin>      (marked by <filename> in the syntax of SRFI 7) are strings
   Olin>      containing Unix-style filenames relative to the directory
   Olin>      the script resides in.

   Olin>    Err... are you *sure* you want to do that?

   Yes.  If I'm not mistaken, scsh behaves in the exact same way.

Yeah, let me withdraw that.

   Olin>    This is problematic for other reasons, as well. What if I
   Olin>    want to load stuff in from some standard library directory,
   Olin>    regardless of where you might locate my script?  Are you
   Olin>    disallowing absolute pathnames?

   No, I'll be more explicit about that.

   Olin>    If you really want to do this relative-to-the-script pathname
   Olin>    resolution, you might be better off saying that *relative*
   Olin>    pathnames are interpreted this way, and absolute pathnames
   Olin>    are simply absolute filenames.

   OK.

Excellent.

What I'd really like is ways to specify multiple resolution strategies
for pathnames, something like ".." and <..> in cpp's #include directive.
Common Lisp's filename stuff lets you specify "logical directories". If
one had a syntax in Scheme for this, one could define a logical dir that
represented a host-specific search path of dirs. But that is far beyond
the scope of this SRFI; I'm just rambling.
    -Olin