Boost logo

Boost :

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,

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

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at