[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Encoding Windows reserved charactes

This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.

Andreas Rottmann scripsit:

> Additionally, and more annoyingly IMO, Windows disallows several
> perfectly innocent-looking names like "aux", "prn", "con" and "nul" (at
> least), with any extension (see also [0] for a story including some
> historical background). I wonder if SRFI 103 should mention this
> horrendous stupidity. 

I thought of mentioning it (it's referred to on the Microsoft page I
cited), but there's no authoritative list.  The doschk utility contains
the list nul, con, prn, aux, com1, com2, com3, com4, lpt1, lpt2, lpt3,
ms$mouse, emmxxxx0, xmsxxxx0, smartaar, setverxx.  However, doschk 1.1
has a bug: it notices these names only when  they are the whole of the
pathname component, so it misses cases like aux.c.

Note that c.aux is also, according to Cygwin, forbidden.  Cygwin gives
special handling to any pathname component containing nul, aux, prn,
con, conin$, conout$, com, lpt anywhere in it.

This is one of those things that's just too ugly to mention.  Why does
JSON require identifier-like keys to be quoted, when Javascript does not?
Because the alternative would be to mention all the Javascript reserved
words (most of them not even used in the language) in the JSON RFC, and
state that any identifier could be used unquoted *except* for these 63
words, and all parsers would have to know about them.

John Cowan  cowan@xxxxxxxx  http://ccil.org/~cowan
The competent programmer is fully aware of the strictly limited size of his own
skull; therefore he approaches the programming task in full humility, and among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra