From: Junio C Hamano <hidden> Date: 2016-06-15 23:07:45
Johannes Schindelin [off-list ref] writes:
The dirname() tests file were developed and tested on only the five
platforms available to the developer at the time, namely: Linux (both 32
and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
(i.e. the POSIX spec) says, in part:
If the string pointed to by path consists entirely of the '/'
character, basename() shall return a pointer to the string "/".
If the string pointed to by path is exactly "//", it is
implementation-defined whether "/" or "//" is returned.
The thinking behind testing precise, OS-dependent output values was to
document that different setups produce different values. However, as the
test failures on MacOSX illustrated eloquently: hardcoding pretty much each
and every setup's expectations is pretty fragile.
This is not limited to the "//" vs "/" case, of course, other inputs are
also allowed to produce multiple outpus by the POSIX specs.
So let's just test for all allowed values and be done with it. This still
documents that Git cannot rely on one particular output value in those
cases, so the intention of the original tests is still met.
Signed-off-by: Johannes Schindelin <redacted>
---
Sounds sensible. Thanks.
This is not a problem with this patch, but the resulting
basename_data[] array seems to test "C:/usr" going to "usr" twice
under _MSC_VER or __MINGW32__.
Also...
"C:" is still allowed to go to "."; is it still "clearly wrong",
or do we have a reason why we think it is not wrong at all?
I think the comment was written by Ramsay and also suspect that you
did not specifically agree or disagree with that particular
decision, so I'd understand if you do not have a strong opinion
either way, but I'd like to hear from Ramsay. Perhaps earlier we
thought it was clearly wrong but we no longer do?
"C:" is still allowed to go to "."; is it still "clearly wrong",
or do we have a reason why we think it is not wrong at all?
I think the comment was written by Ramsay and also suspect that you
did not specifically agree or disagree with that particular
decision, so I'd understand if you do not have a strong opinion
either way, but I'd like to hear from Ramsay. Perhaps earlier we
thought it was clearly wrong but we no longer do?
Yes, that comment was mine. The result is "clearly wrong" if you
follow the POSIX rules [1], but that may not translate exactly to
a dos like path. ;-)
I think the question is: does it make a difference if you call
chdir() on the result? Which brings up something which I have
been ignoring. Correct me if I'm wrong (quite possible), but
_each_ drive has a current working directory associated with
it in win32, so it's a bit difficult to use drive designators
with a relative path (eg. C:usr/lib).
Note: The test data in the test-libgen.c file was using Linux
as the 'benchmark' for the POSIX paths and IIRC MinGW-32 for
the dos paths. (Note that I said 'benchmark' _not_ 'correct'). :-P
ATB,
Ramsay Jones
[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html
From: Johannes Sixt <hidden> Date: 2016-06-15 23:07:45
Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
Correct me if I'm wrong (quite possible), but
_each_ drive has a current working directory associated with
it in win32, so it's a bit difficult to use drive designators
with a relative path (eg. C:usr/lib).
As far as it matters for Git, such a path is still an absolute path,
because it is not anchored at $(pwd).
-- Hannes
From: Ramsay Jones <hidden> Date: 2016-06-15 23:07:46
On 14/01/16 22:14, Johannes Sixt wrote:
Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
quoted
Correct me if I'm wrong (quite possible), but
_each_ drive has a current working directory associated with
it in win32, so it's a bit difficult to use drive designators
with a relative path (eg. C:usr/lib).
As far as it matters for Git, such a path is still an absolute path,
because it is not anchored at $(pwd).
I have been using cygwin on windows since beta-18 (about 1995), in order
to avoid most of the horrors of the windows command line, so I'm a little
rusty. ;-)
You know windows _much_ better than me, so could you please educate me
on this point. I tried this (on windows 8.1):
ramsay@satellite $ cmd
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\cygwin64\home\ramsay>cd junk
cd junk
C:\cygwin64\home\ramsay\junk>dir
dir
Volume in drive C is TI31255200A
Volume Serial Number is 0024-4AC0
Directory of C:\cygwin64\home\ramsay\junk
15/01/2016 00:23 <DIR> .
15/01/2016 00:23 <DIR> ..
15/01/2016 00:23 1 regular
15/01/2016 00:23 <DIR> sub-1
15/01/2016 00:24 <DIR> sub-2
1 File(s) 1 bytes
4 Dir(s) 800,988,291,072 bytes free
C:\cygwin64\home\ramsay\junk>dir C:
dir C:
Volume in drive C is TI31255200A
Volume Serial Number is 0024-4AC0
Directory of C:\cygwin64\home\ramsay\junk
15/01/2016 00:23 <DIR> .
15/01/2016 00:23 <DIR> ..
15/01/2016 00:23 1 regular
15/01/2016 00:23 <DIR> sub-1
15/01/2016 00:24 <DIR> sub-2
1 File(s) 1 bytes
4 Dir(s) 800,988,291,072 bytes free
C:\cygwin64\home\ramsay\junk>dir C:.
dir C:.
Volume in drive C is TI31255200A
Volume Serial Number is 0024-4AC0
Directory of C:\cygwin64\home\ramsay\junk
15/01/2016 00:23 <DIR> .
15/01/2016 00:23 <DIR> ..
15/01/2016 00:23 1 regular
15/01/2016 00:23 <DIR> sub-1
15/01/2016 00:24 <DIR> sub-2
1 File(s) 1 bytes
4 Dir(s) 800,988,291,072 bytes free
C:\cygwin64\home\ramsay\junk>dir C:\
dir C:\
Volume in drive C is TI31255200A
Volume Serial Number is 0024-4AC0
Directory of C:\
17/09/2015 15:52 <DIR> cygwin64
05/08/2015 10:10 383 ftconfig.ini
09/04/2014 05:41 <DIR> Intel
22/08/2013 15:22 <DIR> PerfLogs
06/10/2015 19:28 <DIR> Program Files
26/12/2015 14:09 <DIR> Program Files (x86)
18/05/2014 11:18 0 Recovery.txt
03/12/2013 17:02 <DIR> Toshiba
25/06/2014 18:15 <DIR> UBIOS
26/12/2015 14:09 <DIR> Users
27/08/2015 10:08 <DIR> Windows
2 File(s) 383 bytes
9 Dir(s) 800,988,299,264 bytes free
C:\cygwin64\home\ramsay\junk>dir C:sub-1
dir C:sub-1
Volume in drive C is TI31255200A
Volume Serial Number is 0024-4AC0
Directory of C:\cygwin64\home\ramsay\junk\sub-1
15/01/2016 00:23 <DIR> .
15/01/2016 00:23 <DIR> ..
15/01/2016 00:23 1 bill
15/01/2016 00:23 1 fred
2 File(s) 2 bytes
2 Dir(s) 800,988,299,264 bytes free
C:\cygwin64\home\ramsay\junk>exit
exit
ramsay@satellite $
... which seems to contradict what you say above.
What am I missing?
ATB,
Ramsay Jones
From: Johannes Schindelin <hidden> Date: 2016-06-15 23:07:46
Hi Ramsay,
On Fri, 15 Jan 2016, Ramsay Jones wrote:
On 14/01/16 22:14, Johannes Sixt wrote:
quoted
Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
quoted
Correct me if I'm wrong (quite possible), but _each_ drive has a
current working directory associated with it in win32, so it's a bit
difficult to use drive designators with a relative path (eg.
C:usr/lib).
As far as it matters for Git, such a path is still an absolute path,
because it is not anchored at $(pwd).
[...] seems to contradict what you say above.
What am I missing?
The missing bit is: while C:usr/lib is *not* anchored on $(pwd), it is
*still* not an absolute path because it is anchored on the current
directory of the C: drive (the entire idea that some drive state can
change the meaning of "C:usr/lib" makes it a non-absolute one).
Since this concept -- a path that is neither relative to $(pwd) nor
absolute -- does not exist on Linux, I do not think that Git for Windows
handles this case well at all.
Ciao,
Dscho
From: Johannes Sixt <hidden> Date: 2016-06-15 23:07:46
Am 15.01.2016 um 01:46 schrieb Ramsay Jones:
On 14/01/16 22:14, Johannes Sixt wrote:
quoted
Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
quoted
Correct me if I'm wrong (quite possible), but
_each_ drive has a current working directory associated with
it in win32, so it's a bit difficult to use drive designators
with a relative path (eg. C:usr/lib).
As far as it matters for Git, such a path is still an absolute path,
because it is not anchored at $(pwd).
I have been using cygwin on windows since beta-18 (about 1995), in order
to avoid most of the horrors of the windows command line, so I'm a little
rusty. ;-)
You know windows _much_ better than me, so could you please educate me
on this point. I tried this (on windows 8.1):
C:\cygwin64\home\ramsay\junk>dir C:sub-1
dir C:sub-1
Volume in drive C is TI31255200A
Volume Serial Number is 0024-4AC0
Directory of C:\cygwin64\home\ramsay\junk\sub-1
[...]
... which seems to contradict what you say above.
This example is not super-illuminating. You must cd to a directory on a
different drive, say D:\foo, then call dir C:sub-1. The result will be
the directory listing from somewhere deep inside the C: hierarchy, not
from inside D:\foo.
What am I missing?
Git assumes, given a path in $path that is declared to be relative, that
"$path" and "$(pwd)/$path" denote the same thing.
But that does not work when path="C:sub-1". Yeah, "C:sub-1" is relative
to something, but *in general* that something is not $(pwd).
-- Hannes
From: Ramsay Jones <hidden> Date: 2016-06-15 23:07:46
On 15/01/16 06:34, Johannes Schindelin wrote:
Hi Ramsay,
On Fri, 15 Jan 2016, Ramsay Jones wrote:
quoted
On 14/01/16 22:14, Johannes Sixt wrote:
quoted
Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
quoted
Correct me if I'm wrong (quite possible), but _each_ drive has a
current working directory associated with it in win32, so it's a bit
difficult to use drive designators with a relative path (eg.
C:usr/lib).
As far as it matters for Git, such a path is still an absolute path,
because it is not anchored at $(pwd).
[...] seems to contradict what you say above.
What am I missing?
The missing bit is: while C:usr/lib is *not* anchored on $(pwd), it is
*still* not an absolute path because it is anchored on the current
directory of the C: drive (the entire idea that some drive state can
change the meaning of "C:usr/lib" makes it a non-absolute one).
Since this concept -- a path that is neither relative to $(pwd) nor
absolute -- does not exist on Linux, I do not think that Git for Windows
handles this case well at all.
Yep, I may not have expressed it very well, but this is what I was trying
say! ;-)
ATB,
Ramsay Jones
From: Ramsay Jones <hidden> Date: 2016-06-15 23:07:46
On 15/01/16 06:54, Johannes Sixt wrote:
Am 15.01.2016 um 01:46 schrieb Ramsay Jones:
quoted
On 14/01/16 22:14, Johannes Sixt wrote:
quoted
Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
quoted
Correct me if I'm wrong (quite possible), but
_each_ drive has a current working directory associated with
it in win32, so it's a bit difficult to use drive designators
with a relative path (eg. C:usr/lib).
As far as it matters for Git, such a path is still an absolute path,
because it is not anchored at $(pwd).
I have been using cygwin on windows since beta-18 (about 1995), in order
to avoid most of the horrors of the windows command line, so I'm a little
rusty. ;-)
You know windows _much_ better than me, so could you please educate me
on this point. I tried this (on windows 8.1):
quoted
C:\cygwin64\home\ramsay\junk>dir C:sub-1
dir C:sub-1
Volume in drive C is TI31255200A
Volume Serial Number is 0024-4AC0
Directory of C:\cygwin64\home\ramsay\junk\sub-1
[...]
... which seems to contradict what you say above.
This example is not super-illuminating. You must cd to a directory on a different drive, say D:\foo, then call dir C:sub-1. The result will be the directory listing from somewhere deep inside the C: hierarchy, not from inside D:\foo.
quoted
What am I missing?
Git assumes, given a path in $path that is declared to be relative, that "$path" and "$(pwd)/$path" denote the same thing.
But that does not work when path="C:sub-1". Yeah, "C:sub-1" is relative to something, but *in general* that something is not $(pwd).
I obviously didn't express myself very well, but your answer seems to
be in violent agreement with what I wanted to say! ;-)
ATB,
Ramsay Jones