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