www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.path.getName(): Screwy by design?

reply "Nick Sabalausky" <a a.a> writes:
According to the docs, std.path.getName() "Returns the extensionless version 
of a filename or path."

But the doc also says that if the filename doesn't have a dot, then it 
returns null (and I've verified that on DMD 2.050). Isn't that a bit 
ridiculous? Shouldn't it still return the extensionless version even if it 
doesn't have an extension? Ie, return the original string.

I would expect all of the following to pass, but currently (by design) only 
the first two pass:

assert(getName(r"file.ext") == r"file");
assert(getName(r"/path/file.ext") == r"/path/file");

assert(getName(r"file") == r"file");
assert(getName(r"/path/file") == r"/path/file");

The current behavior seems useless.

Additionally, this also seems screwy:

// Currently passes:
assert(getName(r"/pa.th/file") == r"/pa");

WTF? The docs seem to suggest that's by design, but I can't imagine why. 
Even on Windows it's not as if filenames can contain forward slashes (and 
except for the command-line, accessing paths with forward-slash separators 
works fine on Windows).

Fortunately, the docs do seem to be wrong about this:

version(Windows)
     getName(r"d:\path.two\bar") => null

That currently returns r"d:\path.two\bar" as I would expect.

If those in charge agree with me on all of the this, I'd be glad to go 
through std.path, fix all of that, check for any other issues and submit a 
modified std.path with updated examples and unittests for approval.
Mar 01 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 01 March 2011 00:58:04 Nick Sabalausky wrote:
 According to the docs, std.path.getName() "Returns the extensionless
 version of a filename or path."
 
 But the doc also says that if the filename doesn't have a dot, then it
 returns null (and I've verified that on DMD 2.050). Isn't that a bit
 ridiculous? Shouldn't it still return the extensionless version even if it
 doesn't have an extension? Ie, return the original string.

I would agree. I would _think_ that it would return the file name minus the extension and that if there is no extension, then it would just return the file name.
 I would expect all of the following to pass, but currently (by design) only
 the first two pass:
 
 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");
 
 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");
 
 The current behavior seems useless.
 
 Additionally, this also seems screwy:
 
 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");

 WTF? The docs seem to suggest that's by design, but I can't imagine why.
 Even on Windows it's not as if filenames can contain forward slashes (and
 except for the command-line, accessing paths with forward-slash separators
 works fine on Windows).

That's a bug IMHO. Presumably, the implementation didn't take the possibility of directory names with dots in them into account. Now, it _does_ follow what it says in the docs quite exactly, but that definitely seems off to me.
 Fortunately, the docs do seem to be wrong about this:
 
 version(Windows)
      getName(r"d:\path.two\bar") => null
 
 That currently returns r"d:\path.two\bar" as I would expect.
 
 If those in charge agree with me on all of the this, I'd be glad to go
 through std.path, fix all of that, check for any other issues and submit a
 modified std.path with updated examples and unittests for approval.

I think that I agree with you on all counts. I can understand if the path stuff can't deal with / or \ in file names (that's probably not worth trying to get to work right), but it _should_ be able to handle directories with dots in them and files with no extension. Files without extension may be uncommon in Windows, but they're common enough on Linux. - Jonathan M Davis
Mar 01 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.2076.1298971012.4748.digitalmars-d puremagic.com...
 I think that I agree with you on all counts. I can understand if the path 
 stuff
 can't deal with / or \ in file names (that's probably not worth trying to 
 get to
 work right), but it _should_ be able to handle directories with dots in 
 them and
 files with no extension. Files without extension may be uncommon in 
 Windows, but
 they're common enough on Linux.

Due to the practical need for dealing with Unixy systems (for instance, an external web server) and cross-OS compatibility, etc, I deal with extension-less files (and filenames that start with a dot) quite frequently even on Windows, and even though I'm primarily a Windows user. That reminds me of something I've often wondered, though: Does unix consider a file named ".bashrc" to be a nameless file with an extension of "bashrc", or just an extentionless file named ".bashrc"? (I know unix doesn't typically have a concept of file extension, it's all just part of the name, but unix programs will often care about the extension portion of a filename.)
Mar 01 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 01.03.2011 10:31, schrieb Nick Sabalausky:
 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.2076.1298971012.4748.digitalmars-d puremagic.com...
 I think that I agree with you on all counts. I can understand if the path
 stuff
 can't deal with / or \ in file names (that's probably not worth trying to
 get to
 work right), but it _should_ be able to handle directories with dots in
 them and
 files with no extension. Files without extension may be uncommon in
 Windows, but
 they're common enough on Linux.

Due to the practical need for dealing with Unixy systems (for instance, an external web server) and cross-OS compatibility, etc, I deal with extension-less files (and filenames that start with a dot) quite frequently even on Windows, and even though I'm primarily a Windows user. That reminds me of something I've often wondered, though: Does unix consider a file named ".bashrc" to be a nameless file with an extension of "bashrc", or just an extentionless file named ".bashrc"? (I know unix doesn't typically have a concept of file extension, it's all just part of the name, but unix programs will often care about the extension portion of a filename.)

.bashrc doesn't have an extension and is not an extionsion either. The "." at the start is Unix convention to say "this is a hidden file/folder", this means "ls" (the unix equivalent to "dir") doesn't list them (ls -a does, though) and most file browsers only list them when you select something like "show hidden files" or "show dot files". Cheers, - Daniel
Mar 01 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ikij1r$e1i$1 digitalmars.com...
 The "." at the start is Unix convention to say "this is a hidden 
 file/folder", this means "ls" (the unix equivalent to "dir") doesn't list 
 them (ls -a does, though) and most file browsers only list them when you 
 select something like "show hidden files" or "show dot files".

I know. I was just wondering how the semantics of "name" and "extension" applied to them.
Mar 01 2011
parent "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vrn0zlu4eav7ka steve-laptop...
 On Tue, 01 Mar 2011 07:50:53 -0500, Nick Sabalausky <a a.a> wrote:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:ikij1r$e1i$1 digitalmars.com...
 The "." at the start is Unix convention to say "this is a hidden
 file/folder", this means "ls" (the unix equivalent to "dir") doesn't 
 list
 them (ls -a does, though) and most file browsers only list them when you
 select something like "show hidden files" or "show dot files".

I know. I was just wondering how the semantics of "name" and "extension" applied to them.

I would say it is not an extension, it is the filename. On unix only though.

As a windows guy, I would want windows builds to handle that however unix handles it. Filenames that start with a dot are not at all a windows thing, but on windows there *is* often a need to deal with unix files or unix tools. For instance, when using Apache or developing for an external Apache server even windows users still need to deal with .htaccess. And when they do, it needs to work right.
Mar 01 2011
prev sibling parent Jim <bitcirkel yahoo.com> writes:
Nick Sabalausky Wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
 news:mailman.2076.1298971012.4748.digitalmars-d puremagic.com...
 I think that I agree with you on all counts. I can understand if the path 
 stuff
 can't deal with / or \ in file names (that's probably not worth trying to 
 get to
 work right), but it _should_ be able to handle directories with dots in 
 them and
 files with no extension. Files without extension may be uncommon in 
 Windows, but
 they're common enough on Linux.

Due to the practical need for dealing with Unixy systems (for instance, an external web server) and cross-OS compatibility, etc, I deal with extension-less files (and filenames that start with a dot) quite frequently even on Windows, and even though I'm primarily a Windows user. That reminds me of something I've often wondered, though: Does unix consider a file named ".bashrc" to be a nameless file with an extension of "bashrc", or just an extentionless file named ".bashrc"? (I know unix doesn't typically have a concept of file extension, it's all just part of the name, but unix programs will often care about the extension portion of a filename.)

No, a filename that begins with a dot is just meant to be "invisible", but the dot is in all respects a part of the name. The whole idea of _not_ showing the extensions was probably conjured up in the Usability department at Microsoft? I don't remember if they were mandatory in DOS. In Unix extensions has simply been regarded as part of the name without a fuss. With modern GUIs it seems that this has shifted. But the invisibility dot should not be confused with the extension dot.
Mar 01 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 03/01/2011 10:31 AM, Nick Sabalausky wrote:
 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.2076.1298971012.4748.digitalmars-d puremagic.com...
 I think that I agree with you on all counts. I can understand if the path
 stuff
 can't deal with / or \ in file names (that's probably not worth trying to
 get to
 work right), but it _should_ be able to handle directories with dots in
 them and
 files with no extension. Files without extension may be uncommon in
 Windows, but
 they're common enough on Linux.

Due to the practical need for dealing with Unixy systems (for instance, an external web server) and cross-OS compatibility, etc, I deal with extension-less files (and filenames that start with a dot) quite frequently even on Windows, and even though I'm primarily a Windows user. That reminds me of something I've often wondered, though: Does unix consider a file named ".bashrc" to be a nameless file with an extension of "bashrc", or just an extentionless file named ".bashrc"? (I know unix doesn't typically have a concept of file extension, it's all just part of the name, but unix programs will often care about the extension portion of a filename.)

To be consistent with how things work on Unixes, file names starting with a '.' should be special-cased. This '.' is a conventional code just meaning normal users should not cope with such files/dirs during normal use (and thus such files do not appear on normal dir content lists). It definitely has nothing to do with the notion of extension (which as you say is not a primary notion on Unixes). Treating it as an extension would totally be buggy. I would thus approve assert( getName("/home/me/.foo" == "/home/me/.foo" ); assert( getName("/home/me/.foo.cfg" == "/home/me/.foo" ); on Unixes, provided this behaviour is well documented. Denis -- _________________ vita es estrany spir.wikidot.com
Mar 01 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vrn06uqneav7ka steve-laptop...
 On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis <jmdavisProg gmx.com> 
 wrote:

 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth trying 
 to get to
 work right), but it _should_ be able to handle directories with dots in 
 them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of.

Strictly speaking, most filesystems are perfectly capable of having any character in the filename, even control characters. I know that's definitely the case with FAT32 and NTFS. This has occasionally been used to create files that are a royal PITA to delete (either as a prank or as a malware technique). It's just that the software that interacts with the filesystem (possibly the filesystem driver itself) either can't always cope with certain characters or generally chooses to reject them before actually committing to the filesystem. That said, there's no reason to bend over backwards trying to support such characters that *shouldn't* exist in file/path names, unless you're making a tool specifically designed to deal with that sort of thing (in which case you might need to bypass the usual IO APIs anyway).
Mar 01 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vrn2pooteav7ka steve-laptop...
 On Tue, 01 Mar 2011 08:13:33 -0500, Lars T. Kyllingstad 
 <public kyllingen.nospamnet> wrote:

 On Tue, 01 Mar 2011 08:02:44 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:

 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth trying
 to get to
 work right), but it _should_ be able to handle directories with dots in
 them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve

On a *NIX machine, try touch "c:\\foo\\bar" You may be surprised. ;)

bleh... that seems useless :) I purposely checked FAT before posting, because I was sure Unix disallowed backslashes, I wanted to make sure FAT didn't allow slashes. Holy crap, something that DOS got right and Unix didn't!

Windows also handles files/paths with spaces a hell of a lot better than Unix. This, despite the fact that Unix technically allowed them long before Windows did. (I don't mean this as OS-bashing.)
 From this page: http://en.wikipedia.org/wiki/Filename, it appears that 
 really, the only disallowed character in unix filenames is '/'.  Even '*' 
 is allowed as a filename.  How... horrible.

I would actually feel very good to just simply not support such things. If some unix user is going to use such awful filenames they can just deal with the consequences. (And I'm *rarely* the kind of person to hold such a viewpoint on software development matters.)
Mar 01 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 01.03.2011 14:50, schrieb Nick Sabalausky:
 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message
 news:op.vrn2pooteav7ka steve-laptop...
 On Tue, 01 Mar 2011 08:13:33 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet>  wrote:

 On Tue, 01 Mar 2011 08:02:44 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis
 <jmdavisProg gmx.com>  wrote:

 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth trying
 to get to
 work right), but it _should_ be able to handle directories with dots in
 them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve

On a *NIX machine, try touch "c:\\foo\\bar" You may be surprised. ;)

bleh... that seems useless :) I purposely checked FAT before posting, because I was sure Unix disallowed backslashes, I wanted to make sure FAT didn't allow slashes. Holy crap, something that DOS got right and Unix didn't!

Windows also handles files/paths with spaces a hell of a lot better than Unix. This, despite the fact that Unix technically allowed them long before Windows did. (I don't mean this as OS-bashing.)

It does? In what ways? In Unix you just have to escape spaces with backslashes or put the filename in "" and you're done (bash autocompletion does this). Don't think it's much simpler in Windows. Filebrowsers (GUI or midnight commander etc) don't have any problems with spaces either.
  From this page: http://en.wikipedia.org/wiki/Filename, it appears that
 really, the only disallowed character in unix filenames is '/'.  Even '*'
 is allowed as a filename.  How... horrible.

I would actually feel very good to just simply not support such things. If some unix user is going to use such awful filenames they can just deal with the consequences. (And I'm *rarely* the kind of person to hold such a viewpoint on software development matters.)

Mar 01 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ikivql$mbh$1 digitalmars.com...
 Am 01.03.2011 14:50, schrieb Nick Sabalausky:
 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message
 news:op.vrn2pooteav7ka steve-laptop...
 On Tue, 01 Mar 2011 08:13:33 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet>  wrote:

 On Tue, 01 Mar 2011 08:02:44 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis
 <jmdavisProg gmx.com>  wrote:

 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth 
 trying
 to get to
 work right), but it _should_ be able to handle directories with dots 
 in
 them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve

On a *NIX machine, try touch "c:\\foo\\bar" You may be surprised. ;)

bleh... that seems useless :) I purposely checked FAT before posting, because I was sure Unix disallowed backslashes, I wanted to make sure FAT didn't allow slashes. Holy crap, something that DOS got right and Unix didn't!

Windows also handles files/paths with spaces a hell of a lot better than Unix. This, despite the fact that Unix technically allowed them long before Windows did. (I don't mean this as OS-bashing.)

It does? In what ways? In Unix you just have to escape spaces with backslashes or put the filename in "" and you're done (bash autocompletion does this). Don't think it's much simpler in Windows. Filebrowsers (GUI or midnight commander etc) don't have any problems with spaces either.

There's a long, seemingly-unending history of unix programs choking on paths with spaces in them *even* when you give them the paths properly escaped. Not all unix apps, but enough. I suppose maybe my experience or memory on this is skewed, but I can't remember that ever happening to me on windows except for apps that were ported from unix. Maybe things have changed within the last few years, but try taking the source tree for some large unix program, sticking it in a directory that has a space in the name, and compiling it from there. I've had problems with that. I think the main source of trouble is apps failing to properly escape spaces when they, for instance, generate a script that acts on specific files or when they send the filenames to another app via the commandline.
Mar 01 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 01.03.2011 22:42, schrieb Nick Sabalausky:
 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:ikivql$mbh$1 digitalmars.com...
 Am 01.03.2011 14:50, schrieb Nick Sabalausky:
 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message
 news:op.vrn2pooteav7ka steve-laptop...
 On Tue, 01 Mar 2011 08:13:33 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet>  wrote:

 On Tue, 01 Mar 2011 08:02:44 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis
 <jmdavisProg gmx.com>  wrote:

 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth 
 trying
 to get to
 work right), but it _should_ be able to handle directories with dots 
 in
 them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve

On a *NIX machine, try touch "c:\\foo\\bar" You may be surprised. ;)

bleh... that seems useless :) I purposely checked FAT before posting, because I was sure Unix disallowed backslashes, I wanted to make sure FAT didn't allow slashes. Holy crap, something that DOS got right and Unix didn't!

Windows also handles files/paths with spaces a hell of a lot better than Unix. This, despite the fact that Unix technically allowed them long before Windows did. (I don't mean this as OS-bashing.)

It does? In what ways? In Unix you just have to escape spaces with backslashes or put the filename in "" and you're done (bash autocompletion does this). Don't think it's much simpler in Windows. Filebrowsers (GUI or midnight commander etc) don't have any problems with spaces either.

There's a long, seemingly-unending history of unix programs choking on paths with spaces in them *even* when you give them the paths properly escaped. Not all unix apps, but enough. I suppose maybe my experience or memory on this is skewed, but I can't remember that ever happening to me on windows except for apps that were ported from unix. Maybe things have changed within the last few years, but try taking the source tree for some large unix program, sticking it in a directory that has a space in the name, and compiling it from there. I've had problems with that. I think the main source of trouble is apps failing to properly escape spaces when they, for instance, generate a script that acts on specific files or when they send the filenames to another app via the commandline.

This is a problem of *programs* not dealing properly with spaces in dir/file-names, but not of Unix itself. I guess Windows developers just take more care of these issues than Unix developers did, because spaces in file/dir-names are much more common in the windows world. Cheers, - Daniel
Mar 01 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ikjqaf$2e9r$2 digitalmars.com...
 Am 01.03.2011 22:42, schrieb Nick Sabalausky:
 There's a long, seemingly-unending history of unix programs choking on 
 paths
 with spaces in them *even* when you give them the paths properly escaped.
 Not all unix apps, but enough. I suppose maybe my experience or memory on
 this is skewed, but I can't remember that ever happening to me on windows
 except for apps that were ported from unix. Maybe things have changed 
 within
 the last few years, but try taking the source tree for some large unix
 program, sticking it in a directory that has a space in the name, and
 compiling it from there. I've had problems with that.

 I think the main source of trouble is apps failing to properly escape 
 spaces
 when they, for instance, generate a script that acts on specific files or
 when they send the filenames to another app via the commandline.

This is a problem of *programs* not dealing properly with spaces in dir/file-names, but not of Unix itself. I guess Windows developers just take more care of these issues than Unix developers did, because spaces in file/dir-names are much more common in the windows world.

Unix is nothing more than a kernel + programs anyway (or at least Linux). But at this point I think we're just splitting semantic hairs.
Mar 01 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 01.03.2011 23:45, schrieb Nick Sabalausky:
 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:ikjqaf$2e9r$2 digitalmars.com...
 Am 01.03.2011 22:42, schrieb Nick Sabalausky:
 There's a long, seemingly-unending history of unix programs choking on 
 paths
 with spaces in them *even* when you give them the paths properly escaped.
 Not all unix apps, but enough. I suppose maybe my experience or memory on
 this is skewed, but I can't remember that ever happening to me on windows
 except for apps that were ported from unix. Maybe things have changed 
 within
 the last few years, but try taking the source tree for some large unix
 program, sticking it in a directory that has a space in the name, and
 compiling it from there. I've had problems with that.

 I think the main source of trouble is apps failing to properly escape 
 spaces
 when they, for instance, generate a script that acts on specific files or
 when they send the filenames to another app via the commandline.

This is a problem of *programs* not dealing properly with spaces in dir/file-names, but not of Unix itself. I guess Windows developers just take more care of these issues than Unix developers did, because spaces in file/dir-names are much more common in the windows world.

Unix is nothing more than a kernel + programs anyway (or at least Linux). But at this point I think we're just splitting semantic hairs.

Yeah. My point was that it's not because of shortcomings of APIs in Unix (that winapi handles better or something), but it's just because Unix coders aren't (or at least weren't) as aware of possible problems with spaces. Your original statement was "Windows also handles files/paths with spaces a hell of a lot better than Unix." so I thought you were talking about the OS (or APIs that are very close to the OS) and not about applications :-) Cheers, - Daniel
Mar 01 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/1/11 3:42 PM, Nick Sabalausky wrote:
 There's a long, seemingly-unending history of unix programs choking on paths
 with spaces in them *even* when you give them the paths properly escaped.
 Not all unix apps, but enough.

make and latex are prime examples. I have made an executive decision to never even attempt to use spaces with these programs. Andrei
Mar 01 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 On 3/1/11 3:42 PM, Nick Sabalausky wrote:
 There's a long, seemingly-unending history of unix programs choking on 
 paths
 with spaces in them *even* when you give them the paths properly escaped.
 Not all unix apps, but enough.

make and latex are prime examples. I have made an executive decision to never even attempt to use spaces with these programs.

Similarly, never use / as a path separator in Windows. Sure, it works sometimes. But it often fails in random ways, even with Windows system programs. For example, / doesn't work with the COPY command. I've always hated the Windows "Documents and Settings" subdirectory. Arggh. Always a pain to use on the command line.
Mar 01 2011
parent reply Bekenn <leaveme alone.com> writes:
On 3/1/11 3:27 PM, Walter Bright wrote:
 I've always hated the Windows "Documents and Settings" subdirectory.
 Arggh. Always a pain to use on the command line.

No kidding. Thank goodness that's gone post-XP. Now if only they'd do the same for Program Files...
Mar 01 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 02.03.2011 00:37, schrieb Bekenn:
 On 3/1/11 3:27 PM, Walter Bright wrote:
 I've always hated the Windows "Documents and Settings" subdirectory.
 Arggh. Always a pain to use on the command line.

No kidding. Thank goodness that's gone post-XP. Now if only they'd do the same for Program Files...

Or "My Documents", "My Pictures" and whatnot (or is that gone post-XP?)
Mar 01 2011
parent reply Bekenn <leaveme alone.com> writes:
On 3/1/11 3:40 PM, Daniel Gibson wrote:
 Or "My Documents", "My Pictures" and whatnot (or is that gone post-XP?)

Yes, those are gone. "My Documents" is just "Documents", "My Pictures" is just "Pictures", etc. Windows 7 (sadly) still displays the "My" prefix (Vista doesn't), but the directory names don't have it.
Mar 01 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Bekenn wrote:
 On 3/1/11 3:40 PM, Daniel Gibson wrote:
 Or "My Documents", "My Pictures" and whatnot (or is that gone post-XP?)

Yes, those are gone. "My Documents" is just "Documents", "My Pictures" is just "Pictures", etc. Windows 7 (sadly) still displays the "My" prefix (Vista doesn't), but the directory names don't have it.

Let's hope "My" got severance pay for its years of meaningless service!
Mar 01 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Bekenn wrote:
 On 3/1/11 3:27 PM, Walter Bright wrote:
 I've always hated the Windows "Documents and Settings" subdirectory.
 Arggh. Always a pain to use on the command line.

No kidding. Thank goodness that's gone post-XP. Now if only they'd do the same for Program Files...

<oldguyrant> Yeah, one wonders what's wrong with the word "Programs". And why directories had to be renamed "folders". </oldguyrant>
Mar 01 2011
parent reply Bekenn <leaveme alone.com> writes:
On 3/1/11 5:26 PM, Walter Bright wrote:
 <oldguyrant>

 Yeah, one wonders what's wrong with the word "Programs". And why
 directories had to be renamed "folders".

 </oldguyrant>

Ah, this one (folders) I actually have a response for. Or, rather, Raymond Chen does: http://blogs.msdn.com/b/oldnewthing/archive/2011/02/16/10129908.aspx Absolutely agreed re: "Programs".
Mar 01 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Bekenn wrote:
 Ah, this one (folders) I actually have a response for.  Or, rather, 
 Raymond Chen does: 
 http://blogs.msdn.com/b/oldnewthing/archive/2011/02/16/10129908.aspx

I didn't know that. Thanks for the link!
Mar 01 2011
parent Bekenn <leaveme alone.com> writes:
On 3/1/2011 7:32 PM, Walter Bright wrote:
 I didn't know that. Thanks for the link!

No problem.
Mar 01 2011
prev sibling parent reply Kagamin <spam here.lot> writes:
Bekenn Wrote:

 On 3/1/11 3:27 PM, Walter Bright wrote:
 I've always hated the Windows "Documents and Settings" subdirectory.
 Arggh. Always a pain to use on the command line.

No kidding. Thank goodness that's gone post-XP. Now if only they'd do the same for Program Files...

Did both on my xp, have /home and /programs.
Mar 02 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Kagamin" <spam here.lot> wrote in message 
news:ikl9vq$b0$1 digitalmars.com...
 Bekenn Wrote:

 On 3/1/11 3:27 PM, Walter Bright wrote:
 I've always hated the Windows "Documents and Settings" subdirectory.
 Arggh. Always a pain to use on the command line.

No kidding. Thank goodness that's gone post-XP. Now if only they'd do the same for Program Files...

Did both on my xp, have /home and /programs.

I moved my pictures and music folders to the root of a secondary drive. Kept the same names, athough I don't know why. Maybe I'm just used to it. Now if only I could get programs to quit cluttering "My Documents" with their misc junk, instead of "My Documents/.." where all that crap belongs, *that* would make me happy...(In the meantime, I've created a "My Docs" subdir of "My Documents" that I use as my *real* documents dir - an annoying kludge).
Mar 02 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 02/03/2011 11:34, Kagamin wrote:
 Bekenn Wrote:

 On 3/1/11 3:27 PM, Walter Bright wrote:
 I've always hated the Windows "Documents and Settings" subdirectory.
 Arggh. Always a pain to use on the command line.

No kidding. Thank goodness that's gone post-XP. Now if only they'd do the same for Program Files...

Did both on my xp, have /home and /programs.

Me too, have been doing that for several years, ever since I found out it was possible to do it in a clean, non-hacky way. And the nLite customization tool makes it very easy to do that. It's a shame Windows 7 doesn't support that anymore. Although they have renamed "Documents and Settings" to "Users", so it's not too bad, it's much better than the XP defaults. -- Bruno Medeiros - Software Engineer
Mar 08 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 01.03.2011 15:31, schrieb Lars T. Kyllingstad:
 On Tue, 01 Mar 2011 08:50:29 -0500, Nick Sabalausky wrote:

 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message
 news:op.vrn2pooteav7ka steve-laptop...
 On Tue, 01 Mar 2011 08:13:33 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet>  wrote:

 On Tue, 01 Mar 2011 08:02:44 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis
 <jmdavisProg gmx.com>  wrote:

 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth
 trying to get to
 work right), but it _should_ be able to handle directories with dots
 in them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve

On a *NIX machine, try touch "c:\\foo\\bar" You may be surprised. ;)

bleh... that seems useless :) I purposely checked FAT before posting, because I was sure Unix disallowed backslashes, I wanted to make sure FAT didn't allow slashes. Holy crap, something that DOS got right and Unix didn't!

Windows also handles files/paths with spaces a hell of a lot better than Unix. This, despite the fact that Unix technically allowed them long before Windows did. (I don't mean this as OS-bashing.)

I really don't understand what you guys are talking about. If you encounter a filename with spaces, just enclose it in quotes or escape the spaces. If you encounter a filename with characters like *, \, etc, just escape them or enclose the filename in single quotes. And you only have to do the above when using a command-line shell. I just tried renaming a file to "c:\foo bar\*.baz" using the GNOME file manager and it worked perfectly, just like any other name.
  From this page: http://en.wikipedia.org/wiki/Filename, it appears that
 really, the only disallowed character in unix filenames is '/'.  Even
 '*' is allowed as a filename.  How... horrible.


Yeah, the only illegal filename characters are '/' and null.
 I would actually feel very good to just simply not support such things.
 If some unix user is going to use such awful filenames they can just
 deal with the consequences. (And I'm *rarely* the kind of person to hold
 such a viewpoint on software development matters.)

If you have a bunch of "reserved characters", that means more special cases to worry about in code. I say it's better to allow as many characters as possible. -Lars

There are some fun special cases in Windows (originating in DOS): http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.asp #naming_conventions (reserved device names). I think even CON.txt etc (a reserved name with an extension) is illegal. Cheers, - Daniel
Mar 01 2011
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ikj0cb$mbh$2 digitalmars.com...
 Am 01.03.2011 15:31, schrieb Lars T. Kyllingstad:
 On Tue, 01 Mar 2011 08:50:29 -0500, Nick Sabalausky wrote:

 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message
 news:op.vrn2pooteav7ka steve-laptop...
 On Tue, 01 Mar 2011 08:13:33 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet>  wrote:

 On Tue, 01 Mar 2011 08:02:44 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis
 <jmdavisProg gmx.com>  wrote:

 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth
 trying to get to
 work right), but it _should_ be able to handle directories with dots
 in them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve

On a *NIX machine, try touch "c:\\foo\\bar" You may be surprised. ;)

bleh... that seems useless :) I purposely checked FAT before posting, because I was sure Unix disallowed backslashes, I wanted to make sure FAT didn't allow slashes. Holy crap, something that DOS got right and Unix didn't!

Windows also handles files/paths with spaces a hell of a lot better than Unix. This, despite the fact that Unix technically allowed them long before Windows did. (I don't mean this as OS-bashing.)

I really don't understand what you guys are talking about. If you encounter a filename with spaces, just enclose it in quotes or escape the spaces. If you encounter a filename with characters like *, \, etc, just escape them or enclose the filename in single quotes. And you only have to do the above when using a command-line shell. I just tried renaming a file to "c:\foo bar\*.baz" using the GNOME file manager and it worked perfectly, just like any other name.
  From this page: http://en.wikipedia.org/wiki/Filename, it appears that
 really, the only disallowed character in unix filenames is '/'.  Even
 '*' is allowed as a filename.  How... horrible.


Yeah, the only illegal filename characters are '/' and null.
 I would actually feel very good to just simply not support such things.
 If some unix user is going to use such awful filenames they can just
 deal with the consequences. (And I'm *rarely* the kind of person to hold
 such a viewpoint on software development matters.)

If you have a bunch of "reserved characters", that means more special cases to worry about in code. I say it's better to allow as many characters as possible. -Lars

There are some fun special cases in Windows (originating in DOS): http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.asp #naming_conventions (reserved device names). I think even CON.txt etc (a reserved name with an extension) is illegal.

My interpretation of that is: Those are all under "Naming Conventions", so it's not so much "illegal names" as it is "names that your programs shouldn't allow". Although, my interpretation might be wrong...Some interesting little experiments I just tried (WinXP): - In Explorer, rename a file to "CON": Nothing happens. The filename remains unchanged and no message occurs. Same result with "con". - In Explorer, rename a file to "CON.txt". Error message: "A file with the name you specified already exists." Same result with "con.txt". - Some of the commandline apps I've written in D2/Phobos take an output filename on the comand line. Using one of them to try to create a file named either "CON", "CON.txt", "con", or "con.txt" results in the file's content being displayed to the screen (and a whole hell of a lot of beeping, since it's a binary file ;) ). No actual file was created as far as I could tell. But I woudn't be surprised if there's some API other than whatever Phobos uses that might allow it. In any case, score one for unix including special names like that as part of the filesystem.
Mar 01 2011
prev sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
The best part is taking the file name issue and combining it with the
shell expansion design unix has.

mkdir something
touch something/test
touch -- -R
touch test
rm *


Every file will be destroyed, including subdirectories....except the
murderous -R file!
Mar 01 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Adam Ruppe wrote:
 The best part is taking the file name issue and combining it with the
 shell expansion design unix has.
=20
 mkdir something
 touch something/test
 touch -- -R
 touch test
 rm *
=20
 Every file will be destroyed, including subdirectories....except the
 murderous -R file!

Well, you *did* ask for everything to be removed! So the only issue is that this does not remove the -R file... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Mar 01 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 01 March 2011 01:31:52 Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.2076.1298971012.4748.digitalmars-d puremagic.com...
 
 I think that I agree with you on all counts. I can understand if the path
 stuff
 can't deal with / or \ in file names (that's probably not worth trying to
 get to
 work right), but it _should_ be able to handle directories with dots in
 them and
 files with no extension. Files without extension may be uncommon in
 Windows, but
 they're common enough on Linux.

Due to the practical need for dealing with Unixy systems (for instance, an external web server) and cross-OS compatibility, etc, I deal with extension-less files (and filenames that start with a dot) quite frequently even on Windows, and even though I'm primarily a Windows user. That reminds me of something I've often wondered, though: Does unix consider a file named ".bashrc" to be a nameless file with an extension of "bashrc", or just an extentionless file named ".bashrc"? (I know unix doesn't typically have a concept of file extension, it's all just part of the name, but unix programs will often care about the extension portion of a filename.)

If a program were trying to treat .bashrc like it had an extension, I would expect it to be treated as a file with no name and bashrc as its extension. I don't think that anything else mould make sense. However, it's a prime example of a situation where extensions make no sense. In general, Linux isn't big on extensions. The DEs generally use MIME types to determine the type of a file rather than its extension, and most programs follow suit. But in the rare case where a program would care about extensions, I would expect it to be looking for _specific_ extensions (like mp3 or flac or pdf or whatever), so it wouldn't be looking for a .bashrc file and it wouldn't really matter if it treated its extension as bashrc. - Jonathan M Davis
Mar 01 2011
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 03:58:04 -0500, Nick Sabalausky wrote:

 According to the docs, std.path.getName() "Returns the extensionless
 version of a filename or path."
 
 But the doc also says that if the filename doesn't have a dot, then it
 returns null (and I've verified that on DMD 2.050). Isn't that a bit
 ridiculous? Shouldn't it still return the extensionless version even if
 it doesn't have an extension? Ie, return the original string.
 
 I would expect all of the following to pass, but currently (by design)
 only the first two pass:
 
 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");
 
 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");
 
 The current behavior seems useless.
 
 Additionally, this also seems screwy:
 
 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");
 
 WTF? The docs seem to suggest that's by design, but I can't imagine why.
 Even on Windows it's not as if filenames can contain forward slashes
 (and except for the command-line, accessing paths with forward-slash
 separators works fine on Windows).
 
 Fortunately, the docs do seem to be wrong about this:
 
 version(Windows)
      getName(r"d:\path.two\bar") => null
 
 That currently returns r"d:\path.two\bar" as I would expect.
 
 If those in charge agree with me on all of the this, I'd be glad to go
 through std.path, fix all of that, check for any other issues and submit
 a modified std.path with updated examples and unittests for approval.

I've also found a few cases like that. In general, I think std.path takes the KISS approach, probably because it's the most efficient and works in most cases, but I'd rather it did the Right Thing (TM) that works in all cases. Searching for the "extension dot" is one such case. The simplest thing is of course to search for a '.' character. std.path does that, and also stops (I hope) at a dir separator. However, it doesn't take into account the fact that Windows has two types of dir separator, nor that a dir separator immediately followed by a dot denotes a hidden file on POSIX. Another problem with std.path is the horribly inconsistent naming scheme. I mean, rel2abs? Come on! A while ago I started working on a rewrite of std.path, but it's only halfway done because I got derailed by other things. Perhaps it's time to pick up on it again? http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d -Lars
Mar 01 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 01 March 2011 02:30:56 Lars T. Kyllingstad wrote:
 On Tue, 01 Mar 2011 03:58:04 -0500, Nick Sabalausky wrote:
 According to the docs, std.path.getName() "Returns the extensionless
 version of a filename or path."
 
 But the doc also says that if the filename doesn't have a dot, then it
 returns null (and I've verified that on DMD 2.050). Isn't that a bit
 ridiculous? Shouldn't it still return the extensionless version even if
 it doesn't have an extension? Ie, return the original string.
 
 I would expect all of the following to pass, but currently (by design)
 only the first two pass:
 
 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");
 
 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");
 
 The current behavior seems useless.
 
 Additionally, this also seems screwy:
 
 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");
 
 WTF? The docs seem to suggest that's by design, but I can't imagine why.
 Even on Windows it's not as if filenames can contain forward slashes
 (and except for the command-line, accessing paths with forward-slash
 separators works fine on Windows).
 
 Fortunately, the docs do seem to be wrong about this:
 
 version(Windows)
 
      getName(r"d:\path.two\bar") => null
 
 That currently returns r"d:\path.two\bar" as I would expect.
 
 If those in charge agree with me on all of the this, I'd be glad to go
 through std.path, fix all of that, check for any other issues and submit
 a modified std.path with updated examples and unittests for approval.

I've also found a few cases like that. In general, I think std.path takes the KISS approach, probably because it's the most efficient and works in most cases, but I'd rather it did the Right Thing (TM) that works in all cases. Searching for the "extension dot" is one such case. The simplest thing is of course to search for a '.' character. std.path does that, and also stops (I hope) at a dir separator. However, it doesn't take into account the fact that Windows has two types of dir separator, nor that a dir separator immediately followed by a dot denotes a hidden file on POSIX. Another problem with std.path is the horribly inconsistent naming scheme. I mean, rel2abs? Come on! A while ago I started working on a rewrite of std.path, but it's only halfway done because I got derailed by other things. Perhaps it's time to pick up on it again? http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d

Obviously it's a work in process and not something that you're looking to have reviewed at the moment, but I'd point out that if you're reworking std.path like that, you should really make sure that the function names are properly camelcased. And I honestly prefer sep to dirSeparator, since it's a lot shorter. But given that you have pathSeparator, I guess that that makes sense (though perhaps both should be shorted to end in Sep). In any case, if you want to rework std.path a bit, I certainly have no problem with it. Overall, std.path is fairly good, but it does have some rough corners. - Jonathan M Davis
Mar 01 2011
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 02:37:27 -0800, Jonathan M Davis wrote:

 On Tuesday 01 March 2011 02:30:56 Lars T. Kyllingstad wrote:
 On Tue, 01 Mar 2011 03:58:04 -0500, Nick Sabalausky wrote:
 According to the docs, std.path.getName() "Returns the extensionless
 version of a filename or path."
 
 But the doc also says that if the filename doesn't have a dot, then
 it returns null (and I've verified that on DMD 2.050). Isn't that a
 bit ridiculous? Shouldn't it still return the extensionless version
 even if it doesn't have an extension? Ie, return the original string.
 
 I would expect all of the following to pass, but currently (by
 design) only the first two pass:
 
 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");
 
 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");
 
 The current behavior seems useless.
 
 Additionally, this also seems screwy:
 
 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");
 
 WTF? The docs seem to suggest that's by design, but I can't imagine
 why. Even on Windows it's not as if filenames can contain forward
 slashes (and except for the command-line, accessing paths with
 forward-slash separators works fine on Windows).
 
 Fortunately, the docs do seem to be wrong about this:
 
 version(Windows)
 
      getName(r"d:\path.two\bar") => null
 
 That currently returns r"d:\path.two\bar" as I would expect.
 
 If those in charge agree with me on all of the this, I'd be glad to
 go through std.path, fix all of that, check for any other issues and
 submit a modified std.path with updated examples and unittests for
 approval.

I've also found a few cases like that. In general, I think std.path takes the KISS approach, probably because it's the most efficient and works in most cases, but I'd rather it did the Right Thing (TM) that works in all cases. Searching for the "extension dot" is one such case. The simplest thing is of course to search for a '.' character. std.path does that, and also stops (I hope) at a dir separator. However, it doesn't take into account the fact that Windows has two types of dir separator, nor that a dir separator immediately followed by a dot denotes a hidden file on POSIX. Another problem with std.path is the horribly inconsistent naming scheme. I mean, rel2abs? Come on! A while ago I started working on a rewrite of std.path, but it's only halfway done because I got derailed by other things. Perhaps it's time to pick up on it again? http://kyllingen.net/code/ltk/doc/path.html https://github.com/kyllingstad/ltk/blob/master/ltk/path.d

Obviously it's a work in process and not something that you're looking to have reviewed at the moment, but I'd point out that if you're reworking std.path like that, you should really make sure that the function names are properly camelcased. And I honestly prefer sep to dirSeparator, since it's a lot shorter. But given that you have pathSeparator, I guess that that makes sense (though perhaps both should be shorted to end in Sep). In any case, if you want to rework std.path a bit, I certainly have no problem with it. Overall, std.path is fairly good, but it does have some rough corners.

It's definitely a work in progress, and therefore I'm not going to debate the naming scheme yet. First I'll need to get the functionality in place. ;) I would like to say, however, that I think 'sep' is almost up there with rel2abs in terms of bad naming. If you just see 'sep' in a piece of code, maybe you understand it is a separator, but I don't think everyone will conclude it is a directory separator. Using the fully qualified name 'std.path.sep' isn't good either, because now it looks like it's a path separator. -Lars
Mar 01 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:ikiktf$2vba$3 digitalmars.com...
 I would like to say, however, that I think 'sep' is almost up there with
 rel2abs in terms of bad naming.  If you just see 'sep' in a piece of
 code, maybe you understand it is a separator, but I don't think everyone
 will conclude it is a directory separator.  Using the fully qualified
 name 'std.path.sep' isn't good either, because now it looks like it's a
 path separator.

Speaking of sep, I've never been entirely happy with std.path's tendency to encourage the use of platform-specific directory separators. Windows generally handles forward-slash just fine, so I've always felt it best to always just use forward-slash, and then convert to backslash as-needed in the very rare cases where it actually matters. Doing either std.path.join("..", "dir", "subdir", "file") or ".."~sep~"dir"~sep~"subdir"~sep~"file" is fucking butt-ugly, and it's useless anyway since "../dir/subdir/file" works just fine on all OSes including Windows. (Obviously sep should still exist, regardless of what it's named. But, at least judging by the docs, std.path just seems to rely on it too much.)
Mar 01 2011
parent "Nick Sabalausky" <a a.a> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:ikir9v$14ci$1 digitalmars.com...
 On Tue, 01 Mar 2011 07:48:56 -0500, Nick Sabalausky wrote:

 "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message
 news:ikiktf$2vba$3 digitalmars.com...
 I would like to say, however, that I think 'sep' is almost up there
 with rel2abs in terms of bad naming.  If you just see 'sep' in a piece
 of code, maybe you understand it is a separator, but I don't think
 everyone will conclude it is a directory separator.  Using the fully
 qualified name 'std.path.sep' isn't good either, because now it looks
 like it's a path separator.

to encourage the use of platform-specific directory separators. Windows generally handles forward-slash just fine, so I've always felt it best to always just use forward-slash, and then convert to backslash as-needed in the very rare cases where it actually matters. Doing either std.path.join("..", "dir", "subdir", "file") or ".."~sep~"dir"~sep~"subdir"~sep~"file" is fucking butt-ugly, and it's useless anyway since "../dir/subdir/file" works just fine on all OSes including Windows. (Obviously sep should still exist, regardless of what it's named. But, at least judging by the docs, std.path just seems to rely on it too much.)

This was discussed on the Phobos mailing list a while ago, and Walter said that using forward-slash often doesn't work on Windows: http://lists.puremagic.com/pipermail/phobos/2010-April/000309.html I don't use Windows much myself, so I don't know.

*shrug* The only problems I've ever had with forward-slash on Windows is with cmd.exe and some of the old-school MS-DOS cmdline apps. At the very least, all the stuff in std.file (and Tango, for that matter) handles forward slashes just fine. I suppose there might be some MS APIs that expect a backslash, but I'm still convinced that should be handled as close to the "must be backslash" point as possible rather than needlessly infecting *all* path-handling code.
Mar 01 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 07:48:56 -0500, Nick Sabalausky wrote:

 "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message
 news:ikiktf$2vba$3 digitalmars.com...
 I would like to say, however, that I think 'sep' is almost up there
 with rel2abs in terms of bad naming.  If you just see 'sep' in a piece
 of code, maybe you understand it is a separator, but I don't think
 everyone will conclude it is a directory separator.  Using the fully
 qualified name 'std.path.sep' isn't good either, because now it looks
 like it's a path separator.

to encourage the use of platform-specific directory separators. Windows generally handles forward-slash just fine, so I've always felt it best to always just use forward-slash, and then convert to backslash as-needed in the very rare cases where it actually matters. Doing either std.path.join("..", "dir", "subdir", "file") or ".."~sep~"dir"~sep~"subdir"~sep~"file" is fucking butt-ugly, and it's useless anyway since "../dir/subdir/file" works just fine on all OSes including Windows. (Obviously sep should still exist, regardless of what it's named. But, at least judging by the docs, std.path just seems to rely on it too much.)

This was discussed on the Phobos mailing list a while ago, and Walter said that using forward-slash often doesn't work on Windows: http://lists.puremagic.com/pipermail/phobos/2010-April/000309.html I don't use Windows much myself, so I don't know. -Lars
Mar 01 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:ikiht0$2vba$2 digitalmars.com...
 I've also found a few cases like that.  In general, I think std.path
 takes the KISS approach, probably because it's the most efficient and
 works in most cases, but I'd rather it did the Right Thing (TM) that
 works in all cases.

 Searching for the "extension dot" is one such case.  The simplest thing
 is of course to search for a '.' character.  std.path does that, and also
 stops (I hope) at a dir separator.  However, it doesn't take into account
 the fact that Windows has two types of dir separator, nor that a dir
 separator immediately followed by a dot denotes a hidden file on POSIX.

 Another problem with std.path is the horribly inconsistent naming
 scheme.  I mean, rel2abs?  Come on!

 A while ago I started working on a rewrite of std.path, but it's only
 halfway done because I got derailed by other things.  Perhaps it's time
 to pick up on it again?

  http://kyllingen.net/code/ltk/doc/path.html
  https://github.com/kyllingstad/ltk/blob/master/ltk/path.d

Just took a look at the doc page. I know it's not finished, but my comments based on how it is ATM: - toCanonical is something that std.path desperately needs. Without it, it's impossible to compare paths. I found the lack of it to be a big pain when I switched from Tango to Phobos2. - Like I've said in other posts, I strongly believe that if posix considers ".foo" to be an extensionless file named ".foo", then it should definitely be treated the *same way* on windows too, since the only times windows ever has such files is things like ".htaccess" or ".svn" that are already born of unix anyway. (Optlink's stray ".exe" junk files notwithstanding.) - Not sure what the point of currentDirSymbol and parentDirSymbol would be. But it's not as if their existence hurts anything. And I honestly don't care what sep/dirSeparator/etc is named (I'd just avoid using it in favor of / anyway. Yea, there may be some places in Windows where you need backslashes, but those should be wrapped in functions that convert to backslashes at the last minute as-needed. It shouldn't be allowed to obfuscate/infect the rest of the code). - Still some casing inconsistencies: basename, dirname, drivename still aren't camel-cased, but should be. - It needs a function to remove the extension (while keeping the filename *and* path). Basically, it needs something that's akin to std.path.getName(), but actually works right. - An admittedly minor issue, but the name of std.path.join() always bugged me because of the conflict with std.array.join(). I know D's module system is designed to handle exactly this kind of thing fine, and normally I find D's handling of it perfectly acceptable (except that it destroys universal member call syntax, but that's not really useful for join() anyway). But std.array.join() is such a commonly-useful thing, that it seems a bit much to require all uses of it to become fully-qualified as soon as std.path gets imported. Plus, even if std.array isn't imported, join(somePathVar, anotherPathVar) doesn't exactly scream "yes, this actually *is* correct". I think pathJoin(), joinPaths(), dirJoin() etc are perfectly good names that neatly sidestep all of those issues. Everything else about it looks great. Overall, I'd love to see that module finished and used as the new std.path. The current std.path makes me REALLY nervous and I'm getting tired of tip-toeing my way through it.
Mar 01 2011
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 20:45:15 -0500, Nick Sabalausky wrote:

 "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message
 news:ikiht0$2vba$2 digitalmars.com...
 I've also found a few cases like that.  In general, I think std.path
 takes the KISS approach, probably because it's the most efficient and
 works in most cases, but I'd rather it did the Right Thing (TM) that
 works in all cases.

 Searching for the "extension dot" is one such case.  The simplest thing
 is of course to search for a '.' character.  std.path does that, and
 also stops (I hope) at a dir separator.  However, it doesn't take into
 account the fact that Windows has two types of dir separator, nor that
 a dir separator immediately followed by a dot denotes a hidden file on
 POSIX.

 Another problem with std.path is the horribly inconsistent naming
 scheme.  I mean, rel2abs?  Come on!

 A while ago I started working on a rewrite of std.path, but it's only
 halfway done because I got derailed by other things.  Perhaps it's time
 to pick up on it again?

  http://kyllingen.net/code/ltk/doc/path.html
  https://github.com/kyllingstad/ltk/blob/master/ltk/path.d

comments based on how it is ATM: - toCanonical is something that std.path desperately needs. Without it, it's impossible to compare paths. I found the lack of it to be a big pain when I switched from Tango to Phobos2. - Like I've said in other posts, I strongly believe that if posix considers ".foo" to be an extensionless file named ".foo", then it should definitely be treated the *same way* on windows too, since the only times windows ever has such files is things like ".htaccess" or ".svn" that are already born of unix anyway. (Optlink's stray ".exe" junk files notwithstanding.)

I agree. I changed this yesterday, and now it does the same on Windows and POSIX.
 - Not sure what the point of currentDirSymbol and parentDirSymbol  would
 be. But it's not as if their existence hurts anything. And I honestly
 don't care what sep/dirSeparator/etc is named (I'd just avoid using it
 in favor of / anyway. Yea, there may be some places in Windows where you
 need backslashes, but those should be wrapped in functions that convert
 to backslashes at the last minute as-needed. It shouldn't be allowed to
 obfuscate/infect the rest of the code).

Actually, in my experience, all of the strings defined at the top of std.path are next to useless. Most of the time I need to check "is this character a dir separator?", and then I have to do if (path[i] == sep[0] || path[i] == altsep[0]) ... So I wrote an isDirSeparator() function that performs these tests, and I've ended up using that almost exclusively. The only place I expect to be using the predefined strings is in the join() function.
 - Still some casing inconsistencies: basename, dirname, drivename still
 aren't camel-cased, but should be.

I know. The naming scheme is by no means set in stone, I'm saving that for last.
 - It needs a function to remove the extension (while keeping the
 filename *and* path). Basically, it needs something that's akin to
 std.path.getName(), but actually works right.

I added stripExtension(), setExtension() and defaultExtension() yesterday. Haven't pushed anything to GitHub yet, though.
 - An admittedly minor issue, but the name of std.path.join() always
 bugged me because of the conflict with std.array.join(). I know D's
 module system is designed to handle exactly this kind of thing fine, and
 normally I find D's handling of it perfectly acceptable (except that it
 destroys universal member call syntax, but that's not really useful for
 join() anyway). But std.array.join() is such a commonly-useful thing,
 that it seems a bit much to require all uses of it to become
 fully-qualified as soon as std.path gets imported. Plus, even if
 std.array isn't imported, join(somePathVar, anotherPathVar) doesn't
 exactly scream "yes, this actually *is* correct". I think pathJoin(),
 joinPaths(), dirJoin() etc are perfectly good names that neatly sidestep
 all of those issues.

I agree.
 Everything else about it looks great.

Thanks! :)
 Overall, I'd love to see that module finished and used as the new
 std.path. The current std.path makes me REALLY nervous and I'm getting
 tired of tip-toeing my way through it.

Well, this discussion got me working on it again, and I discovered there isn't that much left to do. I expect it to be done relatively soon. -Lars
Mar 02 2011
parent "Nick Sabalausky" <a a.a> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:ikl3m2$2i6s$1 digitalmars.com...
 On Tue, 01 Mar 2011 20:45:15 -0500, Nick Sabalausky wrote:

 "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message
 news:ikiht0$2vba$2 digitalmars.com...
 I've also found a few cases like that.  In general, I think std.path
 takes the KISS approach, probably because it's the most efficient and
 works in most cases, but I'd rather it did the Right Thing (TM) that
 works in all cases.

 Searching for the "extension dot" is one such case.  The simplest thing
 is of course to search for a '.' character.  std.path does that, and
 also stops (I hope) at a dir separator.  However, it doesn't take into
 account the fact that Windows has two types of dir separator, nor that
 a dir separator immediately followed by a dot denotes a hidden file on
 POSIX.

 Another problem with std.path is the horribly inconsistent naming
 scheme.  I mean, rel2abs?  Come on!

 A while ago I started working on a rewrite of std.path, but it's only
 halfway done because I got derailed by other things.  Perhaps it's time
 to pick up on it again?

  http://kyllingen.net/code/ltk/doc/path.html
  https://github.com/kyllingstad/ltk/blob/master/ltk/path.d

comments based on how it is ATM: - toCanonical is something that std.path desperately needs. Without it, it's impossible to compare paths. I found the lack of it to be a big pain when I switched from Tango to Phobos2. - Like I've said in other posts, I strongly believe that if posix considers ".foo" to be an extensionless file named ".foo", then it should definitely be treated the *same way* on windows too, since the only times windows ever has such files is things like ".htaccess" or ".svn" that are already born of unix anyway. (Optlink's stray ".exe" junk files notwithstanding.)

I agree. I changed this yesterday, and now it does the same on Windows and POSIX.
 - Not sure what the point of currentDirSymbol and parentDirSymbol  would
 be. But it's not as if their existence hurts anything. And I honestly
 don't care what sep/dirSeparator/etc is named (I'd just avoid using it
 in favor of / anyway. Yea, there may be some places in Windows where you
 need backslashes, but those should be wrapped in functions that convert
 to backslashes at the last minute as-needed. It shouldn't be allowed to
 obfuscate/infect the rest of the code).

Actually, in my experience, all of the strings defined at the top of std.path are next to useless. Most of the time I need to check "is this character a dir separator?", and then I have to do if (path[i] == sep[0] || path[i] == altsep[0]) ... So I wrote an isDirSeparator() function that performs these tests, and I've ended up using that almost exclusively. The only place I expect to be using the predefined strings is in the join() function.
 - Still some casing inconsistencies: basename, dirname, drivename still
 aren't camel-cased, but should be.

I know. The naming scheme is by no means set in stone, I'm saving that for last.
 - It needs a function to remove the extension (while keeping the
 filename *and* path). Basically, it needs something that's akin to
 std.path.getName(), but actually works right.

I added stripExtension(), setExtension() and defaultExtension() yesterday. Haven't pushed anything to GitHub yet, though.
 - An admittedly minor issue, but the name of std.path.join() always
 bugged me because of the conflict with std.array.join(). I know D's
 module system is designed to handle exactly this kind of thing fine, and
 normally I find D's handling of it perfectly acceptable (except that it
 destroys universal member call syntax, but that's not really useful for
 join() anyway). But std.array.join() is such a commonly-useful thing,
 that it seems a bit much to require all uses of it to become
 fully-qualified as soon as std.path gets imported. Plus, even if
 std.array isn't imported, join(somePathVar, anotherPathVar) doesn't
 exactly scream "yes, this actually *is* correct". I think pathJoin(),
 joinPaths(), dirJoin() etc are perfectly good names that neatly sidestep
 all of those issues.

I agree.
 Everything else about it looks great.

Thanks! :)
 Overall, I'd love to see that module finished and used as the new
 std.path. The current std.path makes me REALLY nervous and I'm getting
 tired of tip-toeing my way through it.

Well, this discussion got me working on it again, and I discovered there isn't that much left to do. I expect it to be done relatively soon.

Hooray! That all sounds fantastic.
Mar 02 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 03/01/2011 09:58 AM, Nick Sabalausky wrote:
 According to the docs, std.path.getName() "Returns the extensionless version
 of a filename or path."

 But the doc also says that if the filename doesn't have a dot, then it
 returns null (and I've verified that on DMD 2.050). Isn't that a bit
 ridiculous? Shouldn't it still return the extensionless version even if it
 doesn't have an extension? Ie, return the original string.

 I would expect all of the following to pass, but currently (by design) only
 the first two pass:

 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");

 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");

 The current behavior seems useless.

 Additionally, this also seems screwy:

 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");

 WTF? The docs seem to suggest that's by design, but I can't imagine why.
 Even on Windows it's not as if filenames can contain forward slashes (and
 except for the command-line, accessing paths with forward-slash separators
 works fine on Windows).

 Fortunately, the docs do seem to be wrong about this:

 version(Windows)
       getName(r"d:\path.two\bar") =>  null

 That currently returns r"d:\path.two\bar" as I would expect.

 If those in charge agree with me on all of the this, I'd be glad to go
 through std.path, fix all of that, check for any other issues and submit a
 modified std.path with updated examples and unittests for approval.

+++ Denis -- _________________ vita es estrany spir.wikidot.com
Mar 01 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 01.03.2011 09:58, schrieb Nick Sabalausky:
 According to the docs, std.path.getName() "Returns the extensionless version
 of a filename or path."

 But the doc also says that if the filename doesn't have a dot, then it
 returns null (and I've verified that on DMD 2.050). Isn't that a bit
 ridiculous? Shouldn't it still return the extensionless version even if it
 doesn't have an extension? Ie, return the original string.

 I would expect all of the following to pass, but currently (by design) only
 the first two pass:

 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");

 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");

 The current behavior seems useless.

 Additionally, this also seems screwy:

 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");

 WTF? The docs seem to suggest that's by design, but I can't imagine why.
 Even on Windows it's not as if filenames can contain forward slashes (and
 except for the command-line, accessing paths with forward-slash separators
 works fine on Windows).

 Fortunately, the docs do seem to be wrong about this:

 version(Windows)
       getName(r"d:\path.two\bar") =>  null

 That currently returns r"d:\path.two\bar" as I would expect.

 If those in charge agree with me on all of the this, I'd be glad to go
 through std.path, fix all of that, check for any other issues and submit a
 modified std.path with updated examples and unittests for approval.

And what about "foo.tar.gz"? Does it return "foo" or "foo.tar"? And what should be returned? Cheers, - Daniel
Mar 01 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 01 March 2011 02:49:31 Daniel Gibson wrote:
 Am 01.03.2011 09:58, schrieb Nick Sabalausky:
 According to the docs, std.path.getName() "Returns the extensionless
 version of a filename or path."
 
 But the doc also says that if the filename doesn't have a dot, then it
 returns null (and I've verified that on DMD 2.050). Isn't that a bit
 ridiculous? Shouldn't it still return the extensionless version even if
 it doesn't have an extension? Ie, return the original string.
 
 I would expect all of the following to pass, but currently (by design)
 only the first two pass:
 
 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");
 
 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");
 
 The current behavior seems useless.
 
 Additionally, this also seems screwy:
 
 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");
 
 WTF? The docs seem to suggest that's by design, but I can't imagine why.
 Even on Windows it's not as if filenames can contain forward slashes (and
 except for the command-line, accessing paths with forward-slash
 separators works fine on Windows).
 
 Fortunately, the docs do seem to be wrong about this:
 
 version(Windows)
 
       getName(r"d:\path.two\bar") =>  null
 
 That currently returns r"d:\path.two\bar" as I would expect.
 
 If those in charge agree with me on all of the this, I'd be glad to go
 through std.path, fix all of that, check for any other issues and submit
 a modified std.path with updated examples and unittests for approval.

And what about "foo.tar.gz"? Does it return "foo" or "foo.tar"? And what should be returned?

I'd definitely argue that everything to the right of the first dot in the file name is the extension, but I don't know how that's generally handled by programs or OSes that actually care about extensions. - Jonathan M Davis
Mar 01 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/1/11 4:54 AM, Jonathan M Davis wrote:
 On Tuesday 01 March 2011 02:49:31 Daniel Gibson wrote:
 Am 01.03.2011 09:58, schrieb Nick Sabalausky:
 According to the docs, std.path.getName() "Returns the extensionless
 version of a filename or path."

 But the doc also says that if the filename doesn't have a dot, then it
 returns null (and I've verified that on DMD 2.050). Isn't that a bit
 ridiculous? Shouldn't it still return the extensionless version even if
 it doesn't have an extension? Ie, return the original string.

 I would expect all of the following to pass, but currently (by design)
 only the first two pass:

 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");

 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");

 The current behavior seems useless.

 Additionally, this also seems screwy:

 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");

 WTF? The docs seem to suggest that's by design, but I can't imagine why.
 Even on Windows it's not as if filenames can contain forward slashes (and
 except for the command-line, accessing paths with forward-slash
 separators works fine on Windows).

 Fortunately, the docs do seem to be wrong about this:

 version(Windows)

        getName(r"d:\path.two\bar") =>   null

 That currently returns r"d:\path.two\bar" as I would expect.

 If those in charge agree with me on all of the this, I'd be glad to go
 through std.path, fix all of that, check for any other issues and submit
 a modified std.path with updated examples and unittests for approval.

And what about "foo.tar.gz"? Does it return "foo" or "foo.tar"? And what should be returned?

I'd definitely argue that everything to the right of the first dot in the file name is the extension, but I don't know how that's generally handled by programs or OSes that actually care about extensions. - Jonathan M Davis

If we want to stick with the notion of the extension, it should be the thing after the last dot (if the dot isn't the first character of the name). Thus .bashrc has no extension and foo.tar.gz has extension gz. That facilitates asking questions such as "was this file gz-compressed?" Andrei
Mar 01 2011
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 11:49:31 +0100, Daniel Gibson wrote:

 Am 01.03.2011 09:58, schrieb Nick Sabalausky:
 According to the docs, std.path.getName() "Returns the extensionless
 version of a filename or path."

 But the doc also says that if the filename doesn't have a dot, then it
 returns null (and I've verified that on DMD 2.050). Isn't that a bit
 ridiculous? Shouldn't it still return the extensionless version even if
 it doesn't have an extension? Ie, return the original string.

 I would expect all of the following to pass, but currently (by design)
 only the first two pass:

 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");

 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");

 The current behavior seems useless.

 Additionally, this also seems screwy:

 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");

 WTF? The docs seem to suggest that's by design, but I can't imagine
 why. Even on Windows it's not as if filenames can contain forward
 slashes (and except for the command-line, accessing paths with
 forward-slash separators works fine on Windows).

 Fortunately, the docs do seem to be wrong about this:

 version(Windows)
       getName(r"d:\path.two\bar") =>  null

 That currently returns r"d:\path.two\bar" as I would expect.

 If those in charge agree with me on all of the this, I'd be glad to go
 through std.path, fix all of that, check for any other issues and
 submit a modified std.path with updated examples and unittests for
 approval.

should be returned?

That's a good question. And what about "foo-1.0.4.tar.gz"? I say only the last extension should be returned. foo.tar.gz is a gzip file, not a tar file. The fact that you can pass one directly to tar is simply a convenience. -Lars
Mar 01 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:ikilpg$2vba$4 digitalmars.com...
 On Tue, 01 Mar 2011 11:49:31 +0100, Daniel Gibson wrote:

 Am 01.03.2011 09:58, schrieb Nick Sabalausky:
 According to the docs, std.path.getName() "Returns the extensionless
 version of a filename or path."

 But the doc also says that if the filename doesn't have a dot, then it
 returns null (and I've verified that on DMD 2.050). Isn't that a bit
 ridiculous? Shouldn't it still return the extensionless version even if
 it doesn't have an extension? Ie, return the original string.

 I would expect all of the following to pass, but currently (by design)
 only the first two pass:

 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");

 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");

 The current behavior seems useless.

 Additionally, this also seems screwy:

 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");

 WTF? The docs seem to suggest that's by design, but I can't imagine
 why. Even on Windows it's not as if filenames can contain forward
 slashes (and except for the command-line, accessing paths with
 forward-slash separators works fine on Windows).

 Fortunately, the docs do seem to be wrong about this:

 version(Windows)
       getName(r"d:\path.two\bar") =>  null

 That currently returns r"d:\path.two\bar" as I would expect.

 If those in charge agree with me on all of the this, I'd be glad to go
 through std.path, fix all of that, check for any other issues and
 submit a modified std.path with updated examples and unittests for
 approval.

should be returned?

That's a good question. And what about "foo-1.0.4.tar.gz"? I say only the last extension should be returned. foo.tar.gz is a gzip file, not a tar file. The fact that you can pass one directly to tar is simply a convenience.

I agree. I've always seen the ".tar" in "xxxx.tar.gz" as merely a convention indicating what the content of the ".gz" file is. I've even been getting into a similar habit with other file types. For instance, if I have a file "file.foo" using binary format "foo", and then dump some of its data into readable text, I'll name the resulting file "file.foo.txt" instead of "file.txt". It ain't a "foo" file at all, it just helps me know exactly what the txt file is describing.
Mar 01 2011
prev sibling parent reply Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Tue, 01 Mar 2011 09:01:49 -0500, Nick Sabalausky <a a.a> wrote:
 
 "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message
 news:ikis59$14ci$3 digitalmars.com...
 On Tue, 01 Mar 2011 14:10:58 +0100, Jens Mueller wrote:
 I don't know whether this is useful but why not look at what is already
 there. Linux has a command called basename. For removing the extension
 it is a bit useless. Because you need to provide the extension as a
 second argument in that case. But maybe it is like this for a good
 reason. There is also dirname.

I have used Linux's basename and dirname commands as the model for my versions. basename takes a suffix argument because Linux formally doesn't have the notion of a file extension. A dot is a part of the name just like any other character.

People don't always realize it, but Windows really is the same way. It's really only the user-level applications like Explorer that ever care about "extension", and even then the extension is always just "everything after the last dot in the filename". Anything beyond that is merely tradition and convention. The only real difference is that windows has no standard mechanism for looking at the content of the file to help determine its type.


No, it tries hard to make it look that way, but it's evolved from a system where extensions were fundamental. Even now, an 8.3 filename still exists for every file.
 
 Didn't the FAT16 filesystem require something in the name portion of the 
 8.3 filename?

And the dot was not stored anywhere. Only 11 characters were stored. This was still true in Windows 3.1, and I think it wasn't even completely gone in Win95/98.
Mar 01 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:ikj7n9$1sg2$1 digitalmars.com...
 Steven Schveighoffer wrote:
 On Tue, 01 Mar 2011 09:01:49 -0500, Nick Sabalausky <a a.a> wrote:
 People don't always realize it, but Windows really is the same way. It's
 really only the user-level applications like Explorer that ever care 
 about
 "extension", and even then the extension is always just "everything 
 after
 the last dot in the filename". Anything beyond that is merely tradition 
 and
 convention. The only real difference is that windows has no standard
 mechanism for looking at the content of the file to help determine its 
 type.


No, it tries hard to make it look that way, but it's evolved from a system where extensions were fundamental. Even now, an 8.3 filename still exists for every file.

The existence of an 8.3 fallback doesn't really have any bearing on it. And neither does pedigree. If there is still a fundamental distinction with extension, it's nothing more than a detail of how the filesystem spec defines its data storage and completely abstracted away by the filesystem driver. Name one case in windows where some sort of distinction between filename and extension actually makes a real tangible difference versus unix, that doesn't merely amount to convention (there's zero technical hurdle in the way of a windows program considering ".bashrc" to be extensionless) or manually re-implementing part of the filesystem spec (heck, unix has FAT32 and NTFS drivers, too).
Mar 01 2011
parent reply Don <nospam nospam.com> writes:
Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:ikj7n9$1sg2$1 digitalmars.com...
 Steven Schveighoffer wrote:
 On Tue, 01 Mar 2011 09:01:49 -0500, Nick Sabalausky <a a.a> wrote:
 People don't always realize it, but Windows really is the same way. It's
 really only the user-level applications like Explorer that ever care 
 about
 "extension", and even then the extension is always just "everything 
 after
 the last dot in the filename". Anything beyond that is merely tradition 
 and
 convention. The only real difference is that windows has no standard
 mechanism for looking at the content of the file to help determine its 
 type.


where extensions were fundamental. Even now, an 8.3 filename still exists for every file.

The existence of an 8.3 fallback doesn't really have any bearing on it. And neither does pedigree. If there is still a fundamental distinction with extension, it's nothing more than a detail of how the filesystem spec defines its data storage and completely abstracted away by the filesystem driver. Name one case in windows where some sort of distinction between filename and extension actually makes a real tangible difference versus unix, that doesn't merely amount to convention (there's zero technical hurdle in the way of a windows program considering ".bashrc" to be extensionless) or manually re-implementing part of the filesystem spec (heck, unix has FAT32 and NTFS drivers, too).

?????? It ALWAYS makes a difference. For example, only .exe and .com files are executable. On unix, the filename is just a name. Nothing more. By contrast, the Windows extension actually matters. They're completely different. No, it's not "just a convention". It's completely enforced. You cannot execute a file if it has the wrong extension. On Windows, the extension is used to identify the file. Just as unix uses the magic number at the start of the file.
Mar 03 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:iknnq3$1neu$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:ikj7n9$1sg2$1 digitalmars.com...
 Steven Schveighoffer wrote:
 On Tue, 01 Mar 2011 09:01:49 -0500, Nick Sabalausky <a a.a> wrote:
 People don't always realize it, but Windows really is the same way. 
 It's
 really only the user-level applications like Explorer that ever care 
 about
 "extension", and even then the extension is always just "everything 
 after
 the last dot in the filename". Anything beyond that is merely 
 tradition and
 convention. The only real difference is that windows has no standard
 mechanism for looking at the content of the file to help determine its 
 type.


system where extensions were fundamental. Even now, an 8.3 filename still exists for every file.

The existence of an 8.3 fallback doesn't really have any bearing on it. And neither does pedigree. If there is still a fundamental distinction with extension, it's nothing more than a detail of how the filesystem spec defines its data storage and completely abstracted away by the filesystem driver. Name one case in windows where some sort of distinction between filename and extension actually makes a real tangible difference versus unix, that doesn't merely amount to convention (there's zero technical hurdle in the way of a windows program considering ".bashrc" to be extensionless) or manually re-implementing part of the filesystem spec (heck, unix has FAT32 and NTFS drivers, too).

?????? It ALWAYS makes a difference. For example, only .exe and .com files are executable. On unix, the filename is just a name. Nothing more. By contrast, the Windows extension actually matters. They're completely different. No, it's not "just a convention". It's completely enforced. You cannot execute a file if it has the wrong extension. On Windows, the extension is used to identify the file. Just as unix uses the magic number at the start of the file.

Because windows occasionally cares about the extention doesn't imply it isn't part of the filename.
Mar 03 2011
prev sibling parent reply Kagamin <spam here.lot> writes:
Don Wrote:

 ??????
 It ALWAYS makes a difference. For example, only .exe and .com files are 
 executable.
 On unix, the filename is just a name. Nothing more. By contrast, the 
 Windows extension actually matters. They're completely different.

What do you mean? You can run .js and .vbs files as well. It was posted here already, you can rename an .exe to .txt and run it from console.
Mar 03 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Kagamin wrote:
 Don Wrote:
=20
 ??????
 It ALWAYS makes a difference. For example, only .exe and .com files ar=


 executable.
 On unix, the filename is just a name. Nothing more. By contrast, the=20
 Windows extension actually matters. They're completely different.

What do you mean? You can run .js and .vbs files as well.

No you cannot. What happens is that you *open* them with the default application, which just happens to be an interpreter whose default action is to run the script. Try renaming a .exe into .js and it will not run, whereas on Unix it would. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Mar 03 2011
next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Denis Koroskin Wrote:

 	No you cannot. What happens is that you *open* them with the
 default application, which just happens to be an interpreter whose
 default action is to run the script. Try renaming a .exe into .js
 and it will not run, whereas on Unix it would.

 		Jerome

Double-click? Yes. Running from console? No. Didn't believe it until I tried it myself, too.

Hmm, I get an error from the MS Javascript interpreter.
Mar 03 2011
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Denis Koroskin Wrote:

 On Fri, 04 Mar 2011 00:10:28 +0300, Jesse Phillips  
 <jessekphillips+D gmail.com> wrote:
 
 Denis Koroskin Wrote:
 Double-click? Yes. Running from console? No.

 Didn't believe it until I tried it myself, too.

Hmm, I get an error from the MS Javascript interpreter.

Checked again with .js extension. Works like a charm (Windows 7). Are you sure you running it from console and not using double-click? Start->Run doesn't work either, but launching CMD and typing test.js works.

Oh, I was confused on your original post. Yes double-click fails, but the console works. Interestingly enough, gvim will open if I change the extension to txt and am using powershell.
Mar 03 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
On Thu, 03 Mar 2011 21:47:54 +0300, Jérôme M. Berger <jeberger free.fr>
wrote:
 Kagamin wrote:
 Don Wrote:

 ??????
 It ALWAYS makes a difference. For example, only .exe and .com files are
 executable.
 On unix, the filename is just a name. Nothing more. By contrast, the
 Windows extension actually matters. They're completely different.

What do you mean? You can run .js and .vbs files as well. It was posted here already, you can rename an .exe to .txt and run it from console.


I just tried that and it does work. Weird.
 No you cannot. What happens is that you *open* them with the
 default application, which just happens to be an interpreter whose
 default action is to run the script.

That still doesn't imply that the dot and extention aren't part of the filename on windows. Which was my original point: the dot and extension ARE part of the filename on *both* unix and windows. Might not have been the case back on MS-DOS 6, but something like XP, yea. The fact that sometimes parts of the system actually pay attention to that particular *part of the filename* doesn't change the fact that it's still part of the filename. And besides, from what I've heard, even in unix there are times when the extension does get checked.
 Try renaming a .exe into .js
 and it will not run, whereas on Unix it would.

Works for me from the console.
Mar 03 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Lars T. Kyllingstad wrote:
 On Tue, 01 Mar 2011 11:49:31 +0100, Daniel Gibson wrote:
 
 Am 01.03.2011 09:58, schrieb Nick Sabalausky:
 According to the docs, std.path.getName() "Returns the extensionless
 version of a filename or path."

 But the doc also says that if the filename doesn't have a dot, then it
 returns null (and I've verified that on DMD 2.050). Isn't that a bit
 ridiculous? Shouldn't it still return the extensionless version even if
 it doesn't have an extension? Ie, return the original string.

 I would expect all of the following to pass, but currently (by design)
 only the first two pass:

 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");

 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");

 The current behavior seems useless.

 Additionally, this also seems screwy:

 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");

 WTF? The docs seem to suggest that's by design, but I can't imagine
 why. Even on Windows it's not as if filenames can contain forward
 slashes (and except for the command-line, accessing paths with
 forward-slash separators works fine on Windows).

 Fortunately, the docs do seem to be wrong about this:

 version(Windows)
       getName(r"d:\path.two\bar") =>  null

 That currently returns r"d:\path.two\bar" as I would expect.

 If those in charge agree with me on all of the this, I'd be glad to go
 through std.path, fix all of that, check for any other issues and
 submit a modified std.path with updated examples and unittests for
 approval.

should be returned?

That's a good question. And what about "foo-1.0.4.tar.gz"? I say only the last extension should be returned. foo.tar.gz is a gzip file, not a tar file. The fact that you can pass one directly to tar is simply a convenience.

I don't know whether this is useful but why not look at what is already there. Linux has a command called basename. For removing the extension it is a bit useless. Because you need to provide the extension as a second argument in that case. But maybe it is like this for a good reason. There is also dirname. The almost identical C functions are part of POSIX.1-2001 according to the man page. Though I have to admit I have no idea whether Windows has similar calls. Jens
Mar 01 2011
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 14:10:58 +0100, Jens Mueller wrote:

 Lars T. Kyllingstad wrote:
 On Tue, 01 Mar 2011 11:49:31 +0100, Daniel Gibson wrote:
 
 Am 01.03.2011 09:58, schrieb Nick Sabalausky:
 According to the docs, std.path.getName() "Returns the extensionless
 version of a filename or path."

 But the doc also says that if the filename doesn't have a dot, then
 it returns null (and I've verified that on DMD 2.050). Isn't that a
 bit ridiculous? Shouldn't it still return the extensionless version
 even if it doesn't have an extension? Ie, return the original
 string.

 I would expect all of the following to pass, but currently (by
 design) only the first two pass:

 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");

 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");

 The current behavior seems useless.

 Additionally, this also seems screwy:

 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");

 WTF? The docs seem to suggest that's by design, but I can't imagine
 why. Even on Windows it's not as if filenames can contain forward
 slashes (and except for the command-line, accessing paths with
 forward-slash separators works fine on Windows).

 Fortunately, the docs do seem to be wrong about this:

 version(Windows)
       getName(r"d:\path.two\bar") =>  null

 That currently returns r"d:\path.two\bar" as I would expect.

 If those in charge agree with me on all of the this, I'd be glad to
 go through std.path, fix all of that, check for any other issues and
 submit a modified std.path with updated examples and unittests for
 approval.

what should be returned?

That's a good question. And what about "foo-1.0.4.tar.gz"? I say only the last extension should be returned. foo.tar.gz is a gzip file, not a tar file. The fact that you can pass one directly to tar is simply a convenience.

I don't know whether this is useful but why not look at what is already there. Linux has a command called basename. For removing the extension it is a bit useless. Because you need to provide the extension as a second argument in that case. But maybe it is like this for a good reason. There is also dirname.

I have used Linux's basename and dirname commands as the model for my versions. basename takes a suffix argument because Linux formally doesn't have the notion of a file extension. A dot is a part of the name just like any other character. -Lars
Mar 01 2011
parent "Nick Sabalausky" <a a.a> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:ikis59$14ci$3 digitalmars.com...
 On Tue, 01 Mar 2011 14:10:58 +0100, Jens Mueller wrote:
 I don't know whether this is useful but why not look at what is already
 there. Linux has a command called basename. For removing the extension
 it is a bit useless. Because you need to provide the extension as a
 second argument in that case. But maybe it is like this for a good
 reason. There is also dirname.

I have used Linux's basename and dirname commands as the model for my versions. basename takes a suffix argument because Linux formally doesn't have the notion of a file extension. A dot is a part of the name just like any other character.

People don't always realize it, but Windows really is the same way. It's really only the user-level applications like Explorer that ever care about "extension", and even then the extension is always just "everything after the last dot in the filename". Anything beyond that is merely tradition and convention. The only real difference is that windows has no standard mechanism for looking at the content of the file to help determine its type. Now, the Apple II's ProDOS and such, *those* had separate notions of filename and "extension" (not that it was called "extension" though).
Mar 01 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 09:01:49 -0500, Nick Sabalausky <a a.a> wrote:

 "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message
 news:ikis59$14ci$3 digitalmars.com...
 On Tue, 01 Mar 2011 14:10:58 +0100, Jens Mueller wrote:
 I don't know whether this is useful but why not look at what is already
 there. Linux has a command called basename. For removing the extension
 it is a bit useless. Because you need to provide the extension as a
 second argument in that case. But maybe it is like this for a good
 reason. There is also dirname.

I have used Linux's basename and dirname commands as the model for my versions. basename takes a suffix argument because Linux formally doesn't have the notion of a file extension. A dot is a part of the name just like any other character.

People don't always realize it, but Windows really is the same way. It's really only the user-level applications like Explorer that ever care about "extension", and even then the extension is always just "everything after the last dot in the filename". Anything beyond that is merely tradition and convention. The only real difference is that windows has no standard mechanism for looking at the content of the file to help determine its type.

Didn't the FAT16 filesystem require something in the name portion of the 8.3 filename? Note, special care will need to be taken with the special directories '.' and '..' to avoid some weird bugs. -Steve
Mar 01 2011
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 03 Mar 2011 21:47:54 +0300, J=C3=A9r=C3=B4me M. Berger <jeberger=
 free.fr>  =

wrote:

 Kagamin wrote:
 Don Wrote:

 ??????
 It ALWAYS makes a difference. For example, only .exe and .com files =



 executable.
 On unix, the filename is just a name. Nothing more. By contrast, the=



 Windows extension actually matters. They're completely different.

What do you mean? You can run .js and .vbs files as well.

No you cannot. What happens is that you *open* them with the default application, which just happens to be an interpreter whose default action is to run the script. Try renaming a .exe into .js and it will not run, whereas on Unix it would. Jerome

Double-click? Yes. Running from console? No. Didn't believe it until I tried it myself, too.
Mar 03 2011
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 04 Mar 2011 00:10:28 +0300, Jesse Phillips  
<jessekphillips+D gmail.com> wrote:

 Denis Koroskin Wrote:

 	No you cannot. What happens is that you *open* them with the
 default application, which just happens to be an interpreter whose
 default action is to run the script. Try renaming a .exe into .js
 and it will not run, whereas on Unix it would.

 		Jerome

Double-click? Yes. Running from console? No. Didn't believe it until I tried it myself, too.

Hmm, I get an error from the MS Javascript interpreter.

Checked again with .js extension. Works like a charm (Windows 7). Are you sure you running it from console and not using double-click? Start->Run doesn't work either, but launching CMD and typing test.js works.
Mar 03 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 07:50:53 -0500, Nick Sabalausky <a a.a> wrote:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:ikij1r$e1i$1 digitalmars.com...
 The "." at the start is Unix convention to say "this is a hidden
 file/folder", this means "ls" (the unix equivalent to "dir") doesn't  
 list
 them (ls -a does, though) and most file browsers only list them when you
 select something like "show hidden files" or "show dot files".

I know. I was just wondering how the semantics of "name" and "extension" applied to them.

I would say it is not an extension, it is the filename. On unix only though. And as to my opinion on files with multiple dots, the last one is the extension, the others are part of the filename. FYI In addition to ls not listing them, the shell doesn't consider them in * expansion. so echo * does not show hidden files. -Steve
Mar 01 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth trying  
 to get to
 work right), but it _should_ be able to handle directories with dots in  
 them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve
Mar 01 2011
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 08:02:44 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:
 
 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth trying
 to get to
 work right), but it _should_ be able to handle directories with dots in
 them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve

On a *NIX machine, try touch "c:\\foo\\bar" You may be surprised. ;) -Lars
Mar 01 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 01 March 2011 05:35:38 Steven Schveighoffer wrote:
 On Tue, 01 Mar 2011 08:13:33 -0500, Lars T. Kyllingstad
 
 <public kyllingen.nospamnet> wrote:
 On Tue, 01 Mar 2011 08:02:44 -0500, Steven Schveighoffer wrote:
 On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis
 
 <jmdavisProg gmx.com> wrote:
 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth trying
 to get to
 work right), but it _should_ be able to handle directories with dots in
 them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve

On a *NIX machine, try touch "c:\\foo\\bar" You may be surprised. ;)

bleh... that seems useless :) I purposely checked FAT before posting, because I was sure Unix disallowed backslashes, I wanted to make sure FAT didn't allow slashes. Holy crap, something that DOS got right and Unix didn't! From this page: http://en.wikipedia.org/wiki/Filename, it appears that really, the only disallowed character in unix filenames is '/'. Even '*' is allowed as a filename. How... horrible.

Actually, a number of unix file systems allow / in the name too. The extX file systems don't, but reiserFS, btrfs, and XFS are some of those which do. The only character which is _certain_ that it can't be valid in a file name, I believe is NUL. However, given how much of a royal pain it would be to handle / correctly in file names and how so few programs are able to handle files with / in their name, I don't think that it's worth trying to make std.path handle file names with / in them correctly. _Maybe_ it should handle \ correctly on Linux, but even then, I'd argue that it shouldn't be trying to special case it. Now, as for other characters like * or :, I've found it to be _very_ useful to be able to put those in file names - particularly when ripping music - and the fact that Windows is far more restrictive in what it allows in file names is highly annoying. I _like_ the fact that Linux lets you put pretty much any character in a file name. I do think that trying to fully support / and \ is pushing it however - particularly since it's highly unlikely that they'll be handled correctly by other programs anyway. Too many programmers have already assumed that they aren't legal characters in file names. - Jonathan M Davis
Mar 01 2011
prev sibling next sibling parent Johannes Pfau <spam example.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Steven Schveighoffer wrote:
On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis
<jmdavisProg gmx.com> wrote:

 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth
 trying to get to
 work right), but it _should_ be able to handle directories with dots
 in them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve

Just tested it on ubuntu/ext4 and '\' in a filename works. ----------------- File names in Linux can contain any characters other than (1) a forward slash ( / ), which is reserved for use as the name of the root directory (i.e., the directory that contains all other directories and files) and as a directory separator, and (2) the null character (which is used to terminate segments of text). Spaces are permitted, although they are best avoided because they can be incompatible with legacy software in some cases. ----------------- http://www.linfo.org/file_name.html --=20 Johannes Pfau
Mar 01 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 08:13:33 -0500, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:

 On Tue, 01 Mar 2011 08:02:44 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:

 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth trying
 to get to
 work right), but it _should_ be able to handle directories with dots in
 them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve

On a *NIX machine, try touch "c:\\foo\\bar" You may be surprised. ;)

bleh... that seems useless :) I purposely checked FAT before posting, because I was sure Unix disallowed backslashes, I wanted to make sure FAT didn't allow slashes. Holy crap, something that DOS got right and Unix didn't! From this page: http://en.wikipedia.org/wiki/Filename, it appears that really, the only disallowed character in unix filenames is '/'. Even '*' is allowed as a filename. How... horrible. -Steve
Mar 01 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 08:50:29 -0500, Nick Sabalausky wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vrn2pooteav7ka steve-laptop...
 On Tue, 01 Mar 2011 08:13:33 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:

 On Tue, 01 Mar 2011 08:02:44 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:

 I can understand if the path stuff
 can't deal with / or \ in file names (that's probably not worth
 trying to get to
 work right), but it _should_ be able to handle directories with dots
 in them and
 files with no extension.

/ and \ are not legal in names on any filesystem that I know of. -Steve

On a *NIX machine, try touch "c:\\foo\\bar" You may be surprised. ;)

bleh... that seems useless :) I purposely checked FAT before posting, because I was sure Unix disallowed backslashes, I wanted to make sure FAT didn't allow slashes. Holy crap, something that DOS got right and Unix didn't!

Windows also handles files/paths with spaces a hell of a lot better than Unix. This, despite the fact that Unix technically allowed them long before Windows did. (I don't mean this as OS-bashing.)

I really don't understand what you guys are talking about. If you encounter a filename with spaces, just enclose it in quotes or escape the spaces. If you encounter a filename with characters like *, \, etc, just escape them or enclose the filename in single quotes. And you only have to do the above when using a command-line shell. I just tried renaming a file to "c:\foo bar\*.baz" using the GNOME file manager and it worked perfectly, just like any other name.
 From this page: http://en.wikipedia.org/wiki/Filename, it appears that
 really, the only disallowed character in unix filenames is '/'.  Even
 '*' is allowed as a filename.  How... horrible.


Yeah, the only illegal filename characters are '/' and null.
 I would actually feel very good to just simply not support such things.
 If some unix user is going to use such awful filenames they can just
 deal with the consequences. (And I'm *rarely* the kind of person to hold
 such a viewpoint on software development matters.)

If you have a bunch of "reserved characters", that means more special cases to worry about in code. I say it's better to allow as many characters as possible. -Lars
Mar 01 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 09:31:18 -0500, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:

 On Tue, 01 Mar 2011 08:50:29 -0500, Nick Sabalausky wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message


 From this page: http://en.wikipedia.org/wiki/Filename, it appears that
 really, the only disallowed character in unix filenames is '/'.  Even
 '*' is allowed as a filename.  How... horrible.

If some unix user is going to use such awful filenames they can just deal with the consequences. (And I'm *rarely* the kind of person to hold such a viewpoint on software development matters.)

If you have a bunch of "reserved characters", that means more special cases to worry about in code. I say it's better to allow as many characters as possible.

You still have to worry about them, because the shell treats them specially. If there is a file named '*.d', and you type in rm *.d on the command line, guess what happens? To make it really simple to accidentally create these things can cause big problems. On the other hand, to not allow code that deals with filenames like that would mean you have to pull out a special toolkit to deal with them, or deal with the system calls directly. I'm not sure that's the right approach either. It would be nice to have a configuration that allows dealing with 'risky' characters, which is by default off. -Steve
Mar 01 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 09:52:50 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 09:31:18 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:
 
 On Tue, 01 Mar 2011 08:50:29 -0500, Nick Sabalausky wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message


 From this page: http://en.wikipedia.org/wiki/Filename, it appears
 that really, the only disallowed character in unix filenames is '/'. 
 Even '*' is allowed as a filename.  How... horrible.

things. If some unix user is going to use such awful filenames they can just deal with the consequences. (And I'm *rarely* the kind of person to hold such a viewpoint on software development matters.)

If you have a bunch of "reserved characters", that means more special cases to worry about in code. I say it's better to allow as many characters as possible.

You still have to worry about them, because the shell treats them specially. If there is a file named '*.d', and you type in rm *.d on the command line, guess what happens?

If you are using a command line shell you ought to know better than typing "rm *.d". :) If you are using a GUI shell, you right-click and select "Delete file", and nothing bad happens. -Lars
Mar 01 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 10:08:14 -0500, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:

 On Tue, 01 Mar 2011 09:52:50 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 09:31:18 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:

 On Tue, 01 Mar 2011 08:50:29 -0500, Nick Sabalausky wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message


 From this page: http://en.wikipedia.org/wiki/Filename, it appears
 that really, the only disallowed character in unix filenames is '/'.
 Even '*' is allowed as a filename.  How... horrible.

things. If some unix user is going to use such awful filenames they can just deal with the consequences. (And I'm *rarely* the kind of person to hold such a viewpoint on software development matters.)

If you have a bunch of "reserved characters", that means more special cases to worry about in code. I say it's better to allow as many characters as possible.

You still have to worry about them, because the shell treats them specially. If there is a file named '*.d', and you type in rm *.d on the command line, guess what happens?

If you are using a command line shell you ought to know better than typing "rm *.d". :) If you are using a GUI shell, you right-click and select "Delete file", and nothing bad happens.

"should have known better" is an unsatisfying response to "I just *accidentally* deleted all my work." You could tell that to someone who drives off a cliff, but isn't it also good to put up guard rails? very very smart, experienced people sometimes do things without thinking. If we can do something really small to prevent catastrophic errors, I think it's worth it. I think in close to 100% of cases, one never wants a file with \ or * in it, so the library disallowing it will not cause any issues. One time, I was unpacking a program that wanted to be unpacked in /, so it could put files in bin, lib, etc. I accidentally unpacked it in the current directory. Wanting to remove it and go to / in order to unpack, I typed rm -rf /. Bad things happened :) This is obviously not an example that could have been prevented, but it goes to show that sometimes we just type commands without thinking, and the less chance we have to make mistakes, the better. -Steve
Mar 01 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 10:27:49 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 10:08:14 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:
 
 On Tue, 01 Mar 2011 09:52:50 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 09:31:18 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:

 On Tue, 01 Mar 2011 08:50:29 -0500, Nick Sabalausky wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message


 From this page: http://en.wikipedia.org/wiki/Filename, it appears
 that really, the only disallowed character in unix filenames is
 '/'. Even '*' is allowed as a filename.  How... horrible.

things. If some unix user is going to use such awful filenames they can just deal with the consequences. (And I'm *rarely* the kind of person to hold such a viewpoint on software development matters.)

If you have a bunch of "reserved characters", that means more special cases to worry about in code. I say it's better to allow as many characters as possible.

You still have to worry about them, because the shell treats them specially. If there is a file named '*.d', and you type in rm *.d on the command line, guess what happens?

If you are using a command line shell you ought to know better than typing "rm *.d". :) If you are using a GUI shell, you right-click and select "Delete file", and nothing bad happens.

"should have known better" is an unsatisfying response to "I just *accidentally* deleted all my work." You could tell that to someone who drives off a cliff, but isn't it also good to put up guard rails?

I know. I was being a smartass. :)
 very very smart, experienced people sometimes do things without
 thinking. If we can do something really small to prevent catastrophic
 errors, I think it's worth it.  I think in close to 100% of cases, one
 never wants a file with \ or * in it, so the library disallowing it will
 not cause any issues.

Wait... are we still discussing the merits of various file systems, or are we now debating how Phobos should handle weird filenames?
 One time, I was unpacking a program that wanted to be unpacked in /, so
 it could put files in bin, lib, etc.  I accidentally unpacked it in the
 current directory.  Wanting to remove it and go to / in order to unpack,
 I typed rm -rf /.  Bad things happened :)  This is obviously not an
 example that could have been prevented, but it goes to show that
 sometimes we just type commands without thinking, and the less chance we
 have to make mistakes, the better.

Yeah, I remember typing "rm *" in the wrong directory once, and completely erasing a paper I'd been working on. :( Back then I was using bash. Now I use zsh, which warns me when I try to do foolish things like that. -Lars
Mar 01 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 10:52:43 -0500, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:

 On Tue, 01 Mar 2011 10:27:49 -0500, Steven Schveighoffer wrote:

 very very smart, experienced people sometimes do things without
 thinking. If we can do something really small to prevent catastrophic
 errors, I think it's worth it.  I think in close to 100% of cases, one
 never wants a file with \ or * in it, so the library disallowing it will
 not cause any issues.

Wait... are we still discussing the merits of various file systems, or are we now debating how Phobos should handle weird filenames?

The point of this whole discussion is how should phobos' std.path deal with filenames. I thought that was implied. -Steve
Mar 01 2011
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Since we're on the topic of std.path, does anyone have an opinion as to 
how it should handle the various string types?  Currently, it only deals 
with string, i.e. immutable(char)[], but should it also be able to handle 
the other permutations of mutable/const/immutable and char/wchar/dchar?

-Lars
Mar 01 2011
parent "Nick Sabalausky" <a a.a> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:ikj54r$14ci$7 digitalmars.com...
 Since we're on the topic of std.path, does anyone have an opinion as to
 how it should handle the various string types?  Currently, it only deals
 with string, i.e. immutable(char)[], but should it also be able to handle
 the other permutations of mutable/const/immutable and char/wchar/dchar?

I see no reason why not. Or at least, once 'inout' works.
Mar 01 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 10:39:35 -0500, Adam Ruppe <destructionator gmail.com>  
wrote:

 The best part is taking the file name issue and combining it with the
 shell expansion design unix has.

 mkdir something
 touch something/test
 touch -- -R
 touch test
 rm *


 Every file will be destroyed, including subdirectories....except the
 murderous -R file!

ooooh, that is NASTY. -Steve
Mar 01 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 10:55:57 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 10:52:43 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:
 
 On Tue, 01 Mar 2011 10:27:49 -0500, Steven Schveighoffer wrote:

 very very smart, experienced people sometimes do things without
 thinking. If we can do something really small to prevent catastrophic
 errors, I think it's worth it.  I think in close to 100% of cases, one
 never wants a file with \ or * in it, so the library disallowing it
 will not cause any issues.

Wait... are we still discussing the merits of various file systems, or are we now debating how Phobos should handle weird filenames?

The point of this whole discussion is how should phobos' std.path deal with filenames. I thought that was implied.

But std.path doesn't have to deal with these issues. std.path is basically a bunch of functions that search for '/', '\' or '.' in some string. The only special case it needs to worry about is that '\' is an ordinary character on POSIX and a dir separator on Windows. If you want to disallow creating files named "-rf *", that'll have to be done in std.stdio and std.file. -Lars
Mar 01 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 11:04:52 -0500, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:

 On Tue, 01 Mar 2011 10:55:57 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 10:52:43 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:

 On Tue, 01 Mar 2011 10:27:49 -0500, Steven Schveighoffer wrote:

 very very smart, experienced people sometimes do things without
 thinking. If we can do something really small to prevent catastrophic
 errors, I think it's worth it.  I think in close to 100% of cases, one
 never wants a file with \ or * in it, so the library disallowing it
 will not cause any issues.

Wait... are we still discussing the merits of various file systems, or are we now debating how Phobos should handle weird filenames?

The point of this whole discussion is how should phobos' std.path deal with filenames. I thought that was implied.

But std.path doesn't have to deal with these issues. std.path is basically a bunch of functions that search for '/', '\' or '.' in some string. The only special case it needs to worry about is that '\' is an ordinary character on POSIX and a dir separator on Windows. If you want to disallow creating files named "-rf *", that'll have to be done in std.stdio and std.file.

Well, then that's probably where it should be disallowed then. You are right, path shouldn't care about the contents, because looking at a path does not cause problem, it's only creating a file based on the given path that causes problems. -Steve
Mar 01 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 01 March 2011 08:15:35 Lars T. Kyllingstad wrote:
 On Tue, 01 Mar 2011 11:07:15 -0500, Steven Schveighoffer wrote:
 On Tue, 01 Mar 2011 11:04:52 -0500, Lars T. Kyllingstad
 
 <public kyllingen.nospamnet> wrote:
 On Tue, 01 Mar 2011 10:55:57 -0500, Steven Schveighoffer wrote:
 The point of this whole discussion is how should phobos' std.path deal
 with filenames.  I thought that was implied.

But std.path doesn't have to deal with these issues. std.path is basically a bunch of functions that search for '/', '\' or '.' in some string. The only special case it needs to worry about is that '\' is an ordinary character on POSIX and a dir separator on Windows. If you want to disallow creating files named "-rf *", that'll have to be done in std.stdio and std.file.

Well, then that's probably where it should be disallowed then. You are right, path shouldn't care about the contents, because looking at a path does not cause problem, it's only creating a file based on the given path that causes problems.

std.path *could*, however, contain an isSafePath() function that checks whether a given path contains special characters. And if we define "special characters" as "characters not allowed in Windows filenames" it would double as a Windows filename validator.

I previously suggested that we have a function which converts a file name so that it's valid on Windows (replacing invalid characters with valid ones), and IIRC Andrei was against it, because it was file system specific or somesuch. I definitely do that in at least one of my programs though. Another function that I find highly useful is one which escapes file names so that they're safe to use in a shell (the one I have wraps the file name in ' and then turn and 's in the file into '\''), but that could easily be shell-specific and might not be reasonable either. I do like the idea of both functions however. I use them all the time. - Jonathan M Davis
Mar 01 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 11:07:15 -0500, Steven Schveighoffer wrote:

 On Tue, 01 Mar 2011 11:04:52 -0500, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:
 
 On Tue, 01 Mar 2011 10:55:57 -0500, Steven Schveighoffer wrote:

 The point of this whole discussion is how should phobos' std.path deal
 with filenames.  I thought that was implied.

But std.path doesn't have to deal with these issues. std.path is basically a bunch of functions that search for '/', '\' or '.' in some string. The only special case it needs to worry about is that '\' is an ordinary character on POSIX and a dir separator on Windows. If you want to disallow creating files named "-rf *", that'll have to be done in std.stdio and std.file.

Well, then that's probably where it should be disallowed then. You are right, path shouldn't care about the contents, because looking at a path does not cause problem, it's only creating a file based on the given path that causes problems.

std.path *could*, however, contain an isSafePath() function that checks whether a given path contains special characters. And if we define "special characters" as "characters not allowed in Windows filenames" it would double as a Windows filename validator. -Lars
Mar 01 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, March 01, 2011 06:54:27 Andrei Alexandrescu wrote:
 On 3/1/11 4:54 AM, Jonathan M Davis wrote:
 On Tuesday 01 March 2011 02:49:31 Daniel Gibson wrote:
 Am 01.03.2011 09:58, schrieb Nick Sabalausky:
 According to the docs, std.path.getName() "Returns the extensionless
 version of a filename or path."
 
 But the doc also says that if the filename doesn't have a dot, then it
 returns null (and I've verified that on DMD 2.050). Isn't that a bit
 ridiculous? Shouldn't it still return the extensionless version even if
 it doesn't have an extension? Ie, return the original string.
 
 I would expect all of the following to pass, but currently (by design)
 only the first two pass:
 
 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");
 
 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");
 
 The current behavior seems useless.
 
 Additionally, this also seems screwy:
 
 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");
 
 WTF? The docs seem to suggest that's by design, but I can't imagine
 why. Even on Windows it's not as if filenames can contain forward
 slashes (and except for the command-line, accessing paths with
 forward-slash separators works fine on Windows).
 
 Fortunately, the docs do seem to be wrong about this:
 
 version(Windows)
 
        getName(r"d:\path.two\bar") =>   null
 
 That currently returns r"d:\path.two\bar" as I would expect.
 
 If those in charge agree with me on all of the this, I'd be glad to go
 through std.path, fix all of that, check for any other issues and
 submit a modified std.path with updated examples and unittests for
 approval.

And what about "foo.tar.gz"? Does it return "foo" or "foo.tar"? And what should be returned?

I'd definitely argue that everything to the right of the first dot in the file name is the extension, but I don't know how that's generally handled by programs or OSes that actually care about extensions. - Jonathan M Davis

If we want to stick with the notion of the extension, it should be the thing after the last dot (if the dot isn't the first character of the name). Thus .bashrc has no extension and foo.tar.gz has extension gz. That facilitates asking questions such as "was this file gz-compressed?"

Yeah, you're probably right. I definitely think of file.tar.gz as having the extension tar.gz, not gz, but it makes far more sense from a processing point of view to treat gz as the extension. You can then get the extension of the remainder if you want, whereas if you treated tar.gz as the extension, that wouldn't work all that well (particularly since std.path treats the dot as part of the extension instead of as a separator). - Jonathan M Davis
Mar 01 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Tue, 01 Mar 2011 11:04:53 -0800, Jonathan M Davis wrote:

 On Tuesday, March 01, 2011 06:54:27 Andrei Alexandrescu wrote:
 On 3/1/11 4:54 AM, Jonathan M Davis wrote:
 On Tuesday 01 March 2011 02:49:31 Daniel Gibson wrote:
 Am 01.03.2011 09:58, schrieb Nick Sabalausky:
 According to the docs, std.path.getName() "Returns the
 extensionless version of a filename or path."
 
 But the doc also says that if the filename doesn't have a dot, then
 it returns null (and I've verified that on DMD 2.050). Isn't that a
 bit ridiculous? Shouldn't it still return the extensionless version
 even if it doesn't have an extension? Ie, return the original
 string.
 
 I would expect all of the following to pass, but currently (by
 design) only the first two pass:
 
 assert(getName(r"file.ext") == r"file");
 assert(getName(r"/path/file.ext") == r"/path/file");
 
 assert(getName(r"file") == r"file");
 assert(getName(r"/path/file") == r"/path/file");
 
 The current behavior seems useless.
 
 Additionally, this also seems screwy:
 
 // Currently passes:
 assert(getName(r"/pa.th/file") == r"/pa");
 
 WTF? The docs seem to suggest that's by design, but I can't imagine
 why. Even on Windows it's not as if filenames can contain forward
 slashes (and except for the command-line, accessing paths with
 forward-slash separators works fine on Windows).
 
 Fortunately, the docs do seem to be wrong about this:
 
 version(Windows)
 
        getName(r"d:\path.two\bar") =>   null
 
 That currently returns r"d:\path.two\bar" as I would expect.
 
 If those in charge agree with me on all of the this, I'd be glad to
 go through std.path, fix all of that, check for any other issues
 and submit a modified std.path with updated examples and unittests
 for approval.

And what about "foo.tar.gz"? Does it return "foo" or "foo.tar"? And what should be returned?

I'd definitely argue that everything to the right of the first dot in the file name is the extension, but I don't know how that's generally handled by programs or OSes that actually care about extensions. - Jonathan M Davis

If we want to stick with the notion of the extension, it should be the thing after the last dot (if the dot isn't the first character of the name). Thus .bashrc has no extension and foo.tar.gz has extension gz. That facilitates asking questions such as "was this file gz-compressed?"

Yeah, you're probably right. I definitely think of file.tar.gz as having the extension tar.gz, not gz, but it makes far more sense from a processing point of view to treat gz as the extension. You can then get the extension of the remainder if you want, whereas if you treated tar.gz as the extension, that wouldn't work all that well (particularly since std.path treats the dot as part of the extension instead of as a separator).

In the *nix land most common extensions of this sort are .tar.gz, .tar.bz2, .tgz, .ps.gz, .pds.gz, and .svgz. The files are gzip or bzip2 packed single files, nothing more. Some tools only manage to open them if the extension is correct and otherwise treat them as black box archives. For example GNOME's pdf viewer refuses to open document.gz, but renaming it to document.ps.gz makes it viewable, assuming the file is a gzipped postscript document.
Mar 01 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Tue, 01 Mar 2011 19:25:57 +0000, retard wrote:

 .pds.gz,

Sorry about the typo, .pdf.gz
Mar 01 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 02 Mar 2011 16:27:59 -0500, Nick Sabalausky <a a.a> wrote:

 "Kagamin" <spam here.lot> wrote in message
 news:ikl9vq$b0$1 digitalmars.com...
 Bekenn Wrote:

 On 3/1/11 3:27 PM, Walter Bright wrote:
 I've always hated the Windows "Documents and Settings" subdirectory.
 Arggh. Always a pain to use on the command line.

No kidding. Thank goodness that's gone post-XP. Now if only they'd do the same for Program Files...

Did both on my xp, have /home and /programs.

I moved my pictures and music folders to the root of a secondary drive. Kept the same names, athough I don't know why. Maybe I'm just used to it. Now if only I could get programs to quit cluttering "My Documents" with their misc junk, instead of "My Documents/.." where all that crap belongs, *that* would make me happy...(In the meantime, I've created a "My Docs" subdir of "My Documents" that I use as my *real* documents dir - an annoying kludge).

With windows 7, the notion of storing in subdirectories is mostly pointless. It gives you instant search of all your documents, no matter what directory they are in. -Steve
Mar 03 2011