Xah Lee's Unixism

jmfbahciv at aol.com jmfbahciv at aol.com
Thu Sep 2 13:56:01 CEST 2004


In article <1599.740T867T6683932 at kltpzyxm.invalid>,
   "Charlie Gibbs" <cgibbs at kltpzyxm.invalid> wrote:
>In article <Yb6Zc.32434$Es2.12983421 at news4.srv.hcvlny.cv.net>,
>jwkenne at attglobal.net (John W. Kennedy) writes:
>
>>Craig A. Finseth wrote:
>>
>>> Wrong.  The / was chosen as the command line option separator
>>> because whoever wrote MSDOS was looking to CP/M, who modelled
>>> their commands after a PDP-11 operating system (RT-11?).  Consider
>>> the "PIP" command.
>
>At least PIP would copy zero-length files.

Until I started using this braindead OS, I hadn't realized
how spoiled I was w.r.t. combining listed files into one.  
>
>>> When they went to MS/DOS 2.0 and needed path separators, they
>>> found that "/" was already taken, so they used "\".  But there
>>> was a hidden way to tell the command interpreter that it could
>>> use "-" for options.
>>
>>Except, of course, that it was useless, because 99% of programs did
>>their own option parsing, and still do.  The hidden option only lasted
>>one .1 subrelease, as I recall.
>
>Yes, my programs indeed do their own parsing.  And they insist on
>"-", no matter which OS they're running on.  :-)

<GRIN>  And everybody had to invent their own continuation 
characters.

>
>>> And in all systems starting with 2.0, the system calls have taken "/"
>>> and "\" interchangably.
>>
>>...which is /one/ thing that the FLOSS community can honestly thank them
>>for.
>
>Now, do you trust Microsoft to keep it that way?  I don't.  That's why
>my programs are full of things like:
>
>#ifdef DOSWIN
>    strcat (filespec, "\\");
>#else
>    strcat (filespec, "/");
>#endif
>
>Yes, it's bulky and ugly.  But it's also future-proof.
>
Well, it is until code substitution at execution time 
is provided as a service.

/BAH

Subtract a hundred and four for e-mail.



More information about the Python-list mailing list