Steven Penny <svnpenn@xxxxxxxxx> writes:
> If you strip the drive, you can still navigate within the same drive:
>
> $ cd 'C:\Users'
> $ pwd
> /cygdrive/c/Users
>
> $ cd '\Windows'
> $ pwd
> /cygdrive/c/Windows
>
> but you can no longer traverse drives:
>
> $ cd '\Testing'
> sh: cd: \Testing: No such file or directory
Sorry, but I fail to see the point the last example wants to make.
If it were
$ cd /cygdrive/d/Testing
$ cd /cygdrive/c/Users
$ cd ../../d/Testing
and the last step fails, then I would suspect it would make sense to
treat /cygdrive/$X exactly like how we would treat $C:, because
$ cd C:Users
$ cd ../D:Testing
would not make sense, either, which is an indication that these two
are quite similar. On the other hand, if "cd ../../d/Testing" above
does not fail and does what non-DOS users would expect, then that
strongly argues that treating /cygdrive/$X any specially is a mistake.
> So a good first question for me would be: why are we stripping "C:" or similar
> in the first place?
Sorry, but I do not see the connection to this question and the
above example. The reason why we strip C: is because the letter
that comes after that colon determines if we are talking about
absolute path (in other words, the current directory does not play a
role in determining which directory the path refers to), unlike the
POSIX codepath where it is always the first letter in the pathname.
C:\Users is a directory whose name is Users at the top level of the
C: drive. C0\Users tells us that in the current directory, there is
a directory whose name is C0 and in it, there is a filesystem entity
whose name is Users. So the colon that follows an alpha (in this
case, C:) is quite special, compared to other letters (in this
example, I used '0' to contrast its effect with ':'). So it is very
understandable why we want to have has_dos_prefix() and
skip_dos_prefix().
> I would say these could be merged into a "win.h" or similar. Cygwin typically
> leans toward the "/unix/style" while MINGW has been more tolerant of
> "C:\Windows\Style" and "C:/Mixed/Style" paths, i dont see that changing.
I'd defer to Windows folks to decide if a unified win.h is a good
idea.
Thanks.
