public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Bob McGowan <Robert.McGowan@veritas.com>
To: "McCunney, Dennis" <DMcCunney@roper.com>
Cc: Cygwin <cygwin@sourceware.cygnus.com>
Subject: Re: Windows/Cygwin directory name stuff
Date: Thu, 16 Dec 1999 14:55:00 -0000	[thread overview]
Message-ID: <38596E63.7809D994@veritas.com> (raw)
In-Reply-To: <65CAA822B707D211AD430008C7F40FED748770@EXCHANGERSW2>

"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

WARNING: multiple messages have this Message-ID
From: Bob McGowan <Robert.McGowan@veritas.com>
To: "McCunney, Dennis" <DMcCunney@roper.com>
Cc: Cygwin <cygwin@sourceware.cygnus.com>
Subject: Re: Windows/Cygwin directory name stuff
Date: Fri, 31 Dec 1999 13:28:00 -0000	[thread overview]
Message-ID: <38596E63.7809D994@veritas.com> (raw)
Message-ID: <19991231132800.TCWAHh2C5JrBWzvyAo2JeF7vNET8t1Fu-Psh6nNFUmA@z> (raw)
In-Reply-To: <65CAA822B707D211AD430008C7F40FED748770@EXCHANGERSW2>

"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

       reply	other threads:[~1999-12-16 14:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <65CAA822B707D211AD430008C7F40FED748770@EXCHANGERSW2>
1999-12-16 14:55 ` Bob McGowan [this message]
1999-12-31 13:28   ` Bob McGowan
1999-12-16 10:55 Earnie Boyd
1999-12-31 13:28 ` Earnie Boyd
  -- strict thread matches above, loose matches on Subject: below --
1999-12-16  9:18 Earnie Boyd
1999-12-31 13:28 ` Earnie Boyd
1999-12-16  9:05 Halim, Salman
1999-12-31 13:28 ` Halim, Salman
1999-12-16  9:02 Paul Bailey
1999-12-16  9:25 ` Andre Oliveira da Costa
1999-12-16 10:30   ` Bob McGowan
1999-12-31 13:28     ` Bob McGowan
1999-12-31 13:28   ` Andre Oliveira da Costa
1999-12-16  9:30 ` Doug Wyatt
1999-12-31 13:28   ` Doug Wyatt
1999-12-31 13:28 ` Paul Bailey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38596E63.7809D994@veritas.com \
    --to=robert.mcgowan@veritas.com \
    --cc=DMcCunney@roper.com \
    --cc=cygwin@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).