[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Encoding Windows reserved charactes
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  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
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