Absolute file-path under bash (cygwin32)

Hawkeye hawkeye@tcp.com
Wed Apr 16 19:43:00 GMT 1997

Paul Prescod wrote:
> Hawkeye wrote:
> > That could only ever work partially, at best.  Filenames aren't
> > necessarily distinct words in the argument list (consider an option
> > like "-I/usr/local/include"), and every word in the argument list
> > shouldn't necessarily be interpeted as a cygwin filename (consider
> > "echo dir /w >foo.bat").  
> Either of these problems are easily fixed. How do you recognize variable
> names so that they can be replaced? With a special character. I don't
> know bash enough to know what character or character combination is left
> over, though. Maybe $/ as in $/foo/bar.com . Do variable names ever
> start with $/?

I suppose that would work, but what's the point?  Now you have to
remember to type "$/" instead of "C:\".

> > The only "right" place to interpret filenames is in the API calls made by 
> > an application.
> It is already too late for that. We can't fix all of the Windows
> software in the world, and we can't fix all of the Unix source code in
> the world. We must either manually convert pathnames forever or we must
> have a way of letting the computer differentiate them. I prefer the
> latter.

How about this instead:  the internal cygwin function that maps a name
to a location in the filesystem (namei?) could handle both unix-style
and dos-style names.  This solution is not perfect, but it would allow
all unix code compiled with cygwin to accept both kinds of names
without modifying any code.  So users could always give dos-style names
on the command line, without having to think about whether the
application is dos or cygwin; and the unix code would still work with
any hard coded unix names.  (You may prefer unix-style names, as I do,
but I think a consistent ugly style is better than an inconsistent
half-ugly/half-pretty style).  It could work like this:

o Names starting with "/" are interpeted as absolute unix names, no

o Names starting with letter-colon-backslash are interpreted as absolute
  dos names.  The only problem here is unix apps that try to determine
  if a path is absolute by checking for an initial "/", but such cases
  may be rare enough that it's worth having it fail on dos names for the
  sake of this dual naming system.

o What should it do with names starting with letter-colon-nonbackslash?
  Remembering a current-directory per drive doesn't work well with unix
  naming concepts, so maybe cygwin should reject this case as an illegal
  name (with errno=ENOENT, I guess).

o "/" already separates path components in unix names, and is illegal
  in path components in dos names, so cygwin could always interpret it
  as a separator.

o Interpreting "\" is a little more tricky.  Maybe cygwin should interpret
  "\" as a separator only if the name does not contain any "/"s.  Or maybe
  it could always interpret "\" as a separator, with the assumption that
  nobody in their right mind uses "\" in a unix file name.... Say, doesn't
  cygwin already disallow "\" in file names?  In that case, it can always
  interpret "\" as a separator, without losing anything.

This proposal would not break any existing cygwin functionality, but
would add the ability to accept most dos-style names, without the need
to change code in any unix/cygwin apps (including bash).  And it would
allow users to consistently use the same (dos) naming style with all
dos and cygwin apps.

Ken Keys            hawkeye@tcp.com            http://tf.tcp.com/~hawkeye/
TinyFugue info: http://tf.tcp.com/~hawkeye/tf/
TF version 3.5 beta 4 for UNIX and OS/2 is available at:
  ftp://tf.tcp.com/pub/tinyfugue/ and ftp://ftp.tcp.com/pub/mud/Clients/tf/
TF mailing list: mail to majordomo@tcp.com, with body "subscribe tinyfugue"
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

More information about the Cygwin mailing list