[boost] Re: defined(__CYGWIN__) test in boost.filesystem

From: David Abrahams (dave_at_[hidden])
Date: 2003-11-29 20:33:02

Jeremy Maitin-Shepard <jbms_at_[hidden]> writes:

> Beman Dawes <bdawes_at_[hidden]> writes:
>
>> At 02:52 PM 11/28/2003, Jeremy Maitin-Shepard wrote:
>>> The filesystem library seems to treat CYGWIN as a "Windows" platform
>>> rather than a POSIX platform.  It seems this is incorrect behavior.
>
>> Hum... I'm not sure I understand your concern. We still want Windows behavior
>> like "c:/foo" being considered a valid native path, even though the compile
>> happened to be gcc/cygwin.
>
>> Or are you saying that there is some use case on Windows, such as when running
>> under bash, where you wouldn't want "c:/foo" to be considered a valid native
>> path?
>
> I suppose it is partially a matter of user preferences.  

I'd put it more strongly than that.

> My impression though was that one of the purposes of cygwin is to
> provide some amount of POSIX support, and that c: can by accessed at
> /cygdrive/c, for example.
>
> With Windows paths, calling "complete" on a cygwin path like
> "/cygdrive/c" will bring unexpected results.
>
> It seems though that at least some Windows users use cygwin for
> development purposes primarily for a better shell, rather than for
> POSIX support, and thus expect to use standard Windows paths.

In fact, the cygwin filesystem view, with the drives at
/cygdrive/[a-z], is its primary way of dealing with paths.  All of the
cygwin tools support it.  Some additionally support Windows paths, but
not all - that should be considered a secondary/optional approach.
For example, scp needs colons as part of its syntax for remote access,
so:

       $ scp c:/tmp/fu .
       ssh: c: no address associated with name

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com