www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Phobos bug - std.path.getDirName() - Windows

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
Under Windows, getDirName() returns incorrect results if you have a 
directory that uses forward slashes.  Here's the source of the function:

char[] getDirName(char[] fullname)
    out (result)
    {
 assert(result.length <= fullname.length);
    }
    body
    {
 uint i;

 for (i = fullname.length; i > 0; i--)
 {
     version(Win32)
     {
  if (fullname[i - 1] == ':')
      break;
  if (fullname[i - 1] == '\\')
  {   i--;
      break;
  }
     }
     version(linux)
     {
  if (fullname[i - 1] == '/')
  {   i--;
      break;
  }
     }
 }
 return fullname[0 .. i];
    }

The line

 if (fullname[i - 1] == '\\')

Should be

 if (fullname[i - 1] == '\\' || fullname[i - 1] == '/')

Looking through std.path, it looks like the problem could also occur with 
std.path.join().
Nov 15 2005
parent reply Tomás Rossi <Tomás_member pathlink.com> writes:
In article <dle8k6$1e6$1 digitaldaemon.com>, Jarrett Billingsley says...

Under Windows, getDirName() returns incorrect results if you have a 
directory that uses forward slashes.  Here's the source of the function:

char[] getDirName(char[] fullname)
    out (result)
    {
 assert(result.length <= fullname.length);
    }
    body
    {
 uint i;

 for (i = fullname.length; i > 0; i--)
 {
     version(Win32)
     {
  if (fullname[i - 1] == ':')
      break;
  if (fullname[i - 1] == '\\')
  {   i--;
      break;
  }
     }
     version(linux)
     {
  if (fullname[i - 1] == '/')
  {   i--;
      break;
  }
     }
 }
 return fullname[0 .. i];
    }

The line

 if (fullname[i - 1] == '\\')

Should be

 if (fullname[i - 1] == '\\' || fullname[i - 1] == '/')


Why? Is forward slash Windows path separator?
Maybe i'm missing your point, but it looks good to me. :D 

Tom
Nov 16 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 16 Nov 2005 13:14:02 +0000 (UTC), Tomás Rossi wrote:


 In article <dle8k6$1e6$1 digitaldaemon.com>, Jarrett Billingsley says...

Under Windows, getDirName() returns incorrect results if you have a 
directory that uses forward slashes.  Here's the source of the function:

char[] getDirName(char[] fullname)
    out (result)
    {
 assert(result.length <= fullname.length);
    }
    body
    {
 uint i;

 for (i = fullname.length; i > 0; i--)
 {
     version(Win32)
     {
  if (fullname[i - 1] == ':')
      break;
  if (fullname[i - 1] == '\\')
  {   i--;
      break;
  }
     }
     version(linux)
     {
  if (fullname[i - 1] == '/')
  {   i--;
      break;
  }
     }
 }
 return fullname[0 .. i];
    }

The line

 if (fullname[i - 1] == '\\')

Should be

 if (fullname[i - 1] == '\\' || fullname[i - 1] == '/')


 
 Why? Is forward slash Windows path separator?
 Maybe i'm missing your point, but it looks good to me. :D 


Yes it is. At least in the NT family.

Try this ...

  dir c:\

  dir c:/

  dir "c:/"

The first and third works, but the second fails.

The rule seems to be, that when an unambiguous path is used, the path
delimiter can be either '/' or '\'. However, the '\' is the preferred form.
Some DOS and Windows programs don't seem to recognise this so its best not
to output '/' in paths. 

-- 
Derek Parnell
Melbourne, Australia
17/11/2005 12:30:24 AM
Nov 16 2005
parent reply Tomás Rossi <Tomás_member pathlink.com> writes:
In article <4x0gom8gt8e7$.1jsl2jogqx0w$.dlg 40tude.net>, Derek Parnell says...

On Wed, 16 Nov 2005 13:14:02 +0000 (UTC), Tomás Rossi wrote:


 In article <dle8k6$1e6$1 digitaldaemon.com>, Jarrett Billingsley says...

Under Windows, getDirName() returns incorrect results if you have a 
directory that uses forward slashes.  Here's the source of the function:

char[] getDirName(char[] fullname)
    out (result)
    {
 assert(result.length <= fullname.length);
    }
    body
    {
 uint i;

 for (i = fullname.length; i > 0; i--)
 {
     version(Win32)
     {
  if (fullname[i - 1] == ':')
      break;
  if (fullname[i - 1] == '\\')
  {   i--;
      break;
  }
     }
     version(linux)
     {
  if (fullname[i - 1] == '/')
  {   i--;
      break;
  }
     }
 }
 return fullname[0 .. i];
    }

The line

 if (fullname[i - 1] == '\\')

Should be

 if (fullname[i - 1] == '\\' || fullname[i - 1] == '/')


 
 Why? Is forward slash Windows path separator?
 Maybe i'm missing your point, but it looks good to me. :D 


Yes it is. At least in the NT family.

Try this ...

  dir c:\

  dir c:/

  dir "c:/"

The first and third works, but the second fails.

The rule seems to be, that when an unambiguous path is used, the path
delimiter can be either '/' or '\'. However, the '\' is the preferred form.
Some DOS and Windows programs don't seem to recognise this so its best not
to output '/' in paths. 


Perhaps you're right though I don't think it's a pretty Windows-Standard path
separator. Don't work in many situations so I don't think it should be trated as
an accepted one and I wouldn't recomend its use. Not sure if it can be called
formally a bug, maybe just an D-unsupported Windows path separator. Despite
this, it'd be harmless and also useful to support it in this functions, as
Jarret suggests.

Tom
Nov 16 2005
next sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Tomás Rossi wrote:

 Perhaps you're right though I don't think it's a pretty Windows-Standard path
 separator. Don't work in many situations so I don't think it should be trated
as
 an accepted one and I wouldn't recomend its use. Not sure if it can be called
 formally a bug, maybe just an D-unsupported Windows path separator. Despite
 this, it'd be harmless and also useful to support it in this functions, as
 Jarret suggests.
 
 Tom


It would definitely make it easier to create more portable programs. No 
need to every time search'n'replace those. AFAIK most GNU-programs 
support both separators in Windows/DOS. I think even Java supports both 
syntaxes. Originally it was a stupid idea to make people use ; instead 
of : in path-variables and \ instead of /. I assume the only reason was 
to create a vendor lock-in?
Nov 16 2005
prev sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"Tomás Rossi" <Tomás_member pathlink.com> wrote in message 
news:dlffgl$17j9$1 digitaldaemon.com...

 In article <4x0gom8gt8e7$.1jsl2jogqx0w$.dlg 40tude.net>, Derek Parnell 
 says...

On Wed, 16 Nov 2005 13:14:02 +0000 (UTC), Tomás Rossi wrote:


 In article <dle8k6$1e6$1 digitaldaemon.com>, Jarrett Billingsley says...

Under Windows, getDirName() returns incorrect results if you have a
directory that uses forward slashes.  Here's the source of the function:

char[] getDirName(char[] fullname)
    out (result)
    {
 assert(result.length <= fullname.length);
    }
    body
    {
 uint i;

 for (i = fullname.length; i > 0; i--)
 {
     version(Win32)
     {
  if (fullname[i - 1] == ':')
      break;
  if (fullname[i - 1] == '\\')
  {   i--;
      break;
  }
     }
     version(linux)
     {
  if (fullname[i - 1] == '/')
  {   i--;
      break;
  }
     }
 }
 return fullname[0 .. i];
    }

The line

 if (fullname[i - 1] == '\\')

Should be

 if (fullname[i - 1] == '\\' || fullname[i - 1] == '/')


 Why? Is forward slash Windows path separator?
 Maybe i'm missing your point, but it looks good to me. :D


Yes it is. At least in the NT family.

Try this ...

  dir c:\

  dir c:/

  dir "c:/"

The first and third works, but the second fails.

The rule seems to be, that when an unambiguous path is used, the path
delimiter can be either '/' or '\'. However, the '\' is the preferred 
form.
Some DOS and Windows programs don't seem to recognise this so its best not
to output '/' in paths.


 Perhaps you're right though I don't think it's a pretty Windows-Standard 
 path
 separator. Don't work in many situations so I don't think it should be 
 trated as
 an accepted one and I wouldn't recomend its use. Not sure if it can be 
 called
 formally a bug, maybe just an D-unsupported Windows path separator. 
 Despite
 this, it'd be harmless and also useful to support it in this functions, as
 Jarret suggests.


I read somewhere that "/" has been standard in Windows since version 1.0. 
Therefore I'd say its omission in Phobos is a bug.


 Tom
Nov 16 2005
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"John C" <johnch_atms hotmail.com> wrote in message
news:dlfp25$1on7$1 digitaldaemon.com...

 I read somewhere that "/" has been standard in Windows since version 1.0.
 Therefore I'd say its omission in Phobos is a bug.


Using '/' as a path separator in windows works sometimes, and does not work
sometimes. It should be avoided.
Nov 16 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 
 Using '/' as a path separator in windows works sometimes, and does not work
 sometimes. It should be avoided.


Does anyone know why DOS used a '\' as a path separator to begin with? 
UNIX and C had been around for ages already--using the C escape 
signifier for a path separator instead of the established UNIX '/' 
convention just seems kind of silly.


Sean
Nov 16 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 16 Nov 2005 11:48:40 -0800, Sean Kelly wrote:


 Walter Bright wrote:

 
 Using '/' as a path separator in windows works sometimes, and does not work
 sometimes. It should be avoided.


 
 Does anyone know why DOS used a '\' as a path separator to begin with? 
 UNIX and C had been around for ages already--using the C escape 
 signifier for a path separator instead of the established UNIX '/' 
 convention just seems kind of silly.
 


DOS was based on an earlier operating system (CP/M) and that made the
decision for Gates. As to why *that* used a "/" is an exercise for the
reader.
 
-- 
Derek Parnell
Melbourne, Australia
17/11/2005 8:28:14 AM
Nov 16 2005
parent Derek Parnell <derek psych.ward> writes:
On Thu, 17 Nov 2005 08:29:20 +1100, Derek Parnell wrote:


 On Wed, 16 Nov 2005 11:48:40 -0800, Sean Kelly wrote:
 

 Walter Bright wrote:

 
 Using '/' as a path separator in windows works sometimes, and does not work
 sometimes. It should be avoided.


 
 Does anyone know why DOS used a '\' as a path separator to begin with? 
 UNIX and C had been around for ages already--using the C escape 
 signifier for a path separator instead of the established UNIX '/' 
 convention just seems kind of silly.
 


 
 DOS was based on an earlier operating system (CP/M) and that made the
 decision for Gates. As to why *that* used a "/" is an exercise for the
 reader.


What was I thinking (this was before breakfast)! The CP/M operating system
and MS-DOS 1.x didn't even support directories so there was no path
separator in those incarnations. The directory concept was borrowed from
Unix in MS-DOS 2.0 and "Microsoft decided to use backslashes as pathname
separators rather than slashes as on Unix apparently due to the latter
character being used as the switch character in most DOS and CP/M
programs." - to quote Wikipedia ( http://en.wikipedia.org/wiki/MS-DOS )

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
17/11/2005 9:10:53 AM
Nov 16 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:dlg2ep$23lb$1 digitaldaemon.com...

 Does anyone know why DOS used a '\' as a path separator to begin with?
 UNIX and C had been around for ages already--using the C escape
 signifier for a path separator instead of the established UNIX '/'
 convention just seems kind of silly.


DOS 1.x did not have the concept of subdirectories (that appeared first in
DOS 2.0). The '/' was commonly used to signify a switch (and still is).
Therefore, a different character needed to be used to separate paths.

It's as simple as that <g>.

DOS is based on CP/M, which is based on DEC's RT-11. A lot of DOS
conventions stem from RT-11. DEC's operating systems were dominant in the
1970's, so this was quite a reasonable set of conventions to follow. The
dominance of unix didn't come until much later, after DEC's fall from grace.
Nov 17 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 DOS is based on CP/M, which is based on DEC's RT-11. A lot of DOS
 conventions stem from RT-11. DEC's operating systems were dominant in the
 1970's, so this was quite a reasonable set of conventions to follow. The
 dominance of unix didn't come until much later, after DEC's fall from grace.


Bit before my time I guess.  I wasn't exposed to DEC systems until I got 
to college, and I don't think I used them for more than a bit of 
fiddling and the occasional game of Rogue.  My first experience with a 
PC was probably the 4k PETs my school managed to acquire, though I 
recall taking a BASIC programming course on the TRS-80 around the same 
time.  Hrm... now that I look at it, it appears the PET ran some version 
of CP/M so I guess I have used the OS before.  At the time, though, I 
was having too much fun with that text adventure game (Adventure?) to 
pay much attention to the command shell :-)


Sean
Nov 17 2005
parent "Kris" <fu bar.com> writes:
"Sean Kelly" <sean f4.ca> wrote ...

 Walter Bright wrote:

 DOS is based on CP/M, which is based on DEC's RT-11. A lot of DOS
 conventions stem from RT-11. DEC's operating systems were dominant in the
 1970's, so this was quite a reasonable set of conventions to follow. The
 dominance of unix didn't come until much later, after DEC's fall from 
 grace.


 Bit before my time I guess.  I wasn't exposed to DEC systems until I got 
 to college, and I don't think I used them for more than a bit of fiddling 
 and the occasional game of Rogue.  My first experience with a PC was 
 probably the 4k PETs my school managed to acquire, though I recall taking 
 a BASIC programming course on the TRS-80 around the same time.  Hrm... now 
 that I look at it, it appears the PET ran some version of CP/M so I guess 
 I have used the OS before.  At the time, though, I was having too much fun 
 with that text adventure game (Adventure?) to pay much attention to the 
 command shell :-)


command>open door
"You are in a room filled with trolls, with a shaft of light to the west 
..."
command>wield sword
"You have only a banana"
command>
Nov 17 2005
prev sibling next sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Walter Bright wrote:

 "Sean Kelly" <sean f4.ca> wrote in message
 news:dlg2ep$23lb$1 digitaldaemon.com...
 

Does anyone know why DOS used a '\' as a path separator to begin with?
UNIX and C had been around for ages already--using the C escape
signifier for a path separator instead of the established UNIX '/'
convention just seems kind of silly.


 
 
 DOS 1.x did not have the concept of subdirectories (that appeared first in
 DOS 2.0). The '/' was commonly used to signify a switch (and still is).
 Therefore, a different character needed to be used to separate paths.
 
 It's as simple as that <g>.


Actually it's not as simple as that. I remember very well that my old 
Amstrad PC (DR-DOS 1.2 & GEM Desktop) supported subdirectories. It even 
had FAT12 formatted disks. You probably mean that MS-DOS 1.x didn't 
support (sub)directories.

Here's a picture of that trusty old machine:

http://www.old-computers.com/museum/computer.asp?st=1&c=183

It's simply amazing that people used to have GUIs and stuff on a PC 
hardware 20 years ago!
Nov 17 2005
prev sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <dlil74$1r5k$1 digitaldaemon.com>, Walter Bright says...

DOS 1.x did not have the concept of subdirectories (that appeared first in
DOS 2.0). The '/' was commonly used to signify a switch (and still is).
Therefore, a different character needed to be used to separate paths.


True.
But since subdirectories and other features of DOS 2.0 were taken from Unix,
from the beginning the forward slash was accepted as a path separator. You could
change the default character for command line switches in config.sys (for
example '-') and get a quasi-unix environment.
Later in time (I think starting from DOS 4.0) this option was ignored by
command-line tools, so a path using forward slashes was no more recognized by
DOS shell and commands. 
But at the API level forward slashes are still recognized as path separators
today.

Ciao
Nov 18 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:dlk3j4$l8b$1 digitaldaemon.com...

 But at the API level forward slashes are still recognized as path


separators

 today.


The problem is it doesn't work consistently, and the seams show up in
unexpected and unanticipated places. The most robust practice is to not try
and use / as a path separator in Win32, use \.
Nov 25 2005
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dlfuvv$20uq$1 digitaldaemon.com...

 Using '/' as a path separator in windows works sometimes, and does not 
 work
 sometimes. It should be avoided.


Okay, I suppose that's good advice, _but_, there's still the issue of the 
std.path functions.  Although / isn't commonly used, it's still possible, 
and the functions should be able to handle it.  std.path even defines an 
altsep character in Windows, but the functions make no use of it.
Nov 16 2005
parent Derek Parnell <derek psych.ward> writes:
On Wed, 16 Nov 2005 19:54:48 -0500, Jarrett Billingsley wrote:


 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:dlfuvv$20uq$1 digitaldaemon.com...

 Using '/' as a path separator in windows works sometimes, and does not 
 work
 sometimes. It should be avoided.


 
 Okay, I suppose that's good advice, _but_, there's still the issue of the 
 std.path functions.  Although / isn't commonly used, it's still possible, 
 and the functions should be able to handle it.  std.path even defines an 
 altsep character in Windows, but the functions make no use of it.


For what its worth, the next release of Build caters for "/" as path
separators in Windows environments. The 'switch' leading character for
Build is the "-" rather than the MS-DOS standard "/". Of course, it doesn't
allow "\" as a path separator in Unix environments as that is a valid file
name character!

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
17/11/2005 2:33:01 PM
Nov 16 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Wed, 16 Nov 2005 17:08:19 -0000, John C wrote:


 "Tomás Rossi" <Tomás_member pathlink.com> wrote in message 
 news:dlffgl$17j9$1 digitaldaemon.com...

 In article <4x0gom8gt8e7$.1jsl2jogqx0w$.dlg 40tude.net>, Derek Parnell 
 says...

On Wed, 16 Nov 2005 13:14:02 +0000 (UTC), Tomás Rossi wrote:


 In article <dle8k6$1e6$1 digitaldaemon.com>, Jarrett Billingsley says...

Under Windows, getDirName() returns incorrect results if you have a
directory that uses forward slashes.  Here's the source of the function:

char[] getDirName(char[] fullname)
    out (result)
    {
 assert(result.length <= fullname.length);
    }
    body
    {
 uint i;

 for (i = fullname.length; i > 0; i--)
 {
     version(Win32)
     {
  if (fullname[i - 1] == ':')
      break;
  if (fullname[i - 1] == '\\')
  {   i--;
      break;
  }
     }
     version(linux)
     {
  if (fullname[i - 1] == '/')
  {   i--;
      break;
  }
     }
 }
 return fullname[0 .. i];
    }

The line

 if (fullname[i - 1] == '\\')

Should be

 if (fullname[i - 1] == '\\' || fullname[i - 1] == '/')


 Why? Is forward slash Windows path separator?
 Maybe i'm missing your point, but it looks good to me. :D


Yes it is. At least in the NT family.

Try this ...

  dir c:\

  dir c:/

  dir "c:/"

The first and third works, but the second fails.

The rule seems to be, that when an unambiguous path is used, the path
delimiter can be either '/' or '\'. However, the '\' is the preferred 
form.
Some DOS and Windows programs don't seem to recognise this so its best not
to output '/' in paths.


 Perhaps you're right though I don't think it's a pretty Windows-Standard 
 path
 separator. Don't work in many situations so I don't think it should be 
 trated as
 an accepted one and I wouldn't recomend its use. Not sure if it can be 
 called
 formally a bug, maybe just an D-unsupported Windows path separator. 
 Despite
 this, it'd be harmless and also useful to support it in this functions, as
 Jarret suggests.


 
 I read somewhere that "/" has been standard in Windows since version 1.0. 
 Therefore I'd say its omission in Phobos is a bug.


Not quite. There was a low level API (BIOS) call to set the Switch
delimiter from "/" to something else and that influenced the path separator
determination.

-- 
Derek Parnell
Melbourne, Australia
17/11/2005 8:26:44 AM
Nov 16 2005