[r6rs-discuss] [Formal] "#! /usr/bin/env" is not "portable." It's Unix-specific. (fwd)

From: Per Bothner <per>
Date: Thu Nov 16 12:50:49 2006

Arthur A. Gleckler wrote:
> On Nov 16, 2006, at 8:38 AM, Per Bothner wrote:
>
>> I think it is useful that it be possible to write a conforming R6RS
>> program that is at the same time a valid Unix/Posix script. That
>> requires some minimal standardization in R6RS. Non-Unix implementations
>> need to not get confused by a Unix script header.
>
> It doesn't require standardization in R6RS.

As long as R6RS prohibits reader extensions, then yes it does.
It also requires standardization if you want a Windows implementation
to not barf on a Posix header.

> And why should Unix implementations own the top line of every script
> file? What happens when another operating system wants control over the
> top line?

In this context Unix is a misnomer. Posix is *the* standard for this
sort of thing. Posix is supported natively by almost every real
operating system out here, including Unix, BSD*, GNU/Linux, and
Max OS X. Probably IBM mainframes too these days. Posix
is required by various government purchasing requirements,
which is why even Microsoft sort-of-supports it. (At least Windows NT
had a "Posix environment", but it was intentionally useless, just to
satisfy purchasing requirements.) More realistically, Cygwin provides
a *useful* Posix environment for MS-Windows.

Of course Posix is actually a whole slew of standards. Microsoft
as long supported Posix.1 "natively" in the sense that it is
trivially available to C programs. I'm not sure what Posix standard
covers the "#!" syntax, but it is most definitely an established
formal standard. It is quite appropriate for R6RS to aim for
compatibility with other well-recognized standards. After all,
that is why we care about Unicode and IEEE floating-point.

>> It is also useful to have a standard header so a Scheme file can be
>> identified by content, rather than just file extension, which is
>> unreliable. But that requires a standard header for libraries as well,
>> though it need not and probably should not be the same header.
>
> Identification of file type by content is no more reliable than by
> extension, and almost certainly less so.

That is wrong. Most binary file formats have a unique magic number to
allow them to be identified, and many text format also have standard
headers. Extensions are definitely unreliable, because it is quite
common for many incompatible file formats to have the same extension.
A ".doc" file need not be an MS-Word file - even only using Microsoft
products. (It can be an rtf file, for example.)
-- 
	--Per Bothner
per_at_bothner.com   http://per.bothner.com/
Received on Thu Nov 16 2006 - 12:51:42 UTC

This archive was generated by hypermail 2.3.0 : Wed Oct 23 2024 - 09:15:00 UTC