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
> 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 www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk