Re: Windows/Cygwin directory name stuff

[Bob McGowan <Robert dot McGowan at veritas dot com>]

"McCunney, Dennis" wrote:
> 
> > -----Original Message-----
> > From: Earnie Boyd [mailto:earnie_boyd@yahoo.com]
> > Sent: Thursday, December 16, 1999 1:55 PM
> > To: Bob McGowan; Paul Bailey
> > Cc: cygwin@sourceware.cygnus.com
> > Subject: Re: Windows/Cygwin directory name stuff
> >
> > > To round out this discussion, there is ONLY ONE character
> > that UNIX (the
> > > kernel) and therefor cygwin (the DLL) really cares about as
> > "special"
> > > and that is the forward slash (/).  This is the delimiter in a path
> > > between the various names.  You _cannot_ have a name that contains a
> > > literal forward slash.  Otherwise, any character is legal.
> > >
> > > The interpretation of other characters, as special or not,
> > depends on
> > > the application being used, as mentioned in other posts to this
> > > discussion.
> >
> > To further "round out this discussion": What Bob says is true
> > of UNIX but not
> > Win32.  Win32 does have other characters that it doesn't like
> > in the filenames.
> >  I don't remember off the top of my head what they are, though.

True.  I was trying to get too literal in translating "mimic", here. 
And if I had tried it, I would have seen error messages like "file not
found" for attempts to create a name like "*".

> 
> Off the top of my head, "<", ">", "\", "*", "?", and "|", for fairly
> obvious reasons.  UNIX will have similar problems unless you escape
> the characters.  UNIX will also ley you create file names with non-
> printing characters, which can cause all manner of fun when you try
> to _do_ something with them.  (I just _love_ typing "ls | od -c | less"
> to figure out what is occuring when one of my users manages this feat...)

When I tried to make an illegal name in Explorer, it added ":", "/" and
""" (that is the double quote itself), to your list.

I'm not so sure the reasons are "obvious", though.  It is certainly not
the same reason that there are "similar problems" for UNIX.  As I
remember, the processing method used by DOS is to handle the wild card
interpretation via a "system/function call", so wild cards are handled
outside of the specific application.  An application wanting wild card
processing would need to use the supplied API.  I'm not so sure here
about exact names, but the sequence was to prepare to read names
specified by wild cards, call a "get first matching name" function, then
a "get next matching name" function and continue the get next until a no
match condition was returned.  If the application did not use the API,
the name with wild card characters would be taken literally by it, so
the underlying system needed to protect itself, by checking for and not
allowing invalid characters.

This is not the case on UNIX.  Wild card processing is done at the
application level, by the shell (and others, such as 'find').  If I
should want to, I could write a shell that uses a completely different
set of characters (or none at all), and have it co-exist with a
"standard" shell on any UNIX system available.

This concept also applies to the I/O re-direction symbols you mentioned
in your list.

> 
> Once upon a time, DOS had an undocumented system call that would let
> you change the option delimiter character from "/" to something else
> like "-".  Once you had done that, you could use "\" _or_ "/" in DOS
> path names.  The MKS Toolkit used to use that trick to support UNIX
> style path names in their product.  DOS 5.0 removed the call that let
> you change the option delimiter, but _retained_ the one that let you
> query what it is.  (I don't understand MS at all.)
> 
> 

I had forgotten about this "wonderful" feature.  Ain't DOS great! !-(

-- 
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan@veritas.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com