"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.

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

"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.)

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

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

"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.

"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

"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.

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.

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

"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

"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

"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

"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.)

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.)

"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.

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

"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.

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

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

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.

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...

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?)

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.

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!

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>

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".

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!

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.

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.

"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).

"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

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

"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

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

"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.

"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.

 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.

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

"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.

 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.

 
 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

"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.

 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.

 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

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!

"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

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

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

"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.

 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.

 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

"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

"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

"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

"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

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

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

Johannes Pfau <spam example.com> writes:

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

"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).

"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

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

"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

"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.)

"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.

 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.)

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

"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.

 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.)

 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.

"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.

"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

 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.)

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

"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

 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.)

 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.

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

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

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

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

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

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.

retard <re tard.com.invalid> writes:

Tue, 01 Mar 2011 19:25:57 +0000, retard wrote:

 .pds.gz,

Sorry about the typo, .pdf.gz 

"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.

 And what about "foo.tar.gz"? Does it return "foo" or "foo.tar"? And 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.

-Lars

"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.

 And what about "foo.tar.gz"? Does it return "foo" or "foo.tar"? And 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 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.

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.

 And what about "foo.tar.gz"? Does it return "foo" or "foo.tar"? And 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.
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

"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.

 And what about "foo.tar.gz"? Does it return "foo" or "foo.tar"? And
 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

"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).

"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

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.

"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).

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.


 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).

??????
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.

"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.


 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).

 ??????
 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.

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.

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

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


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

=20
 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

"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 =



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.

 	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.

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.

"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.

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.

"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.

Jesse Phillips <jessekphillips+D gmail.com> writes:

Daniel Gibson Wrote:

 .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 

I don't like this description, it is a configuration file which just so happens
to have the convention of not being shown. Linux doesn't have "hidden" files.

But I agree that is the name of the file and not the extension. I'm not sure if
it matters how the library actually deals with it. What scares me is calling
getName on it would return:

assert("/home/user/.bashrc" == "/home/user/");

How am I supposed to interpret that, it is a directory, what happens when I
call getName again?

I think the behavior for getName is different in Linux then in Windows. And in
Windows I have added extensions to a file so a could get the file name (use
getBaseName or whatever it is called, with getName.)

So I agree with every thing Nick has said.

 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

"Nick Sabalausky" <a a.a> writes:

"Jesse Phillips" <jessekphillips+D gmail.com> wrote in message 
news:ikj3nf$1l0v$1 digitalmars.com...
 Daniel Gibson Wrote:

 .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

 I don't like this description, it is a configuration file which just so 
 happens to have the convention of not being shown.

That's the exact same thing. "not being shown" == "hidden" What else could 
"not being shown" mean, if not "hidden"? Obstructed view?

 Linux doesn't have "hidden" files.

That's just like saying "Windows doesn't have hidden files, it just has some 
files with a flag that happen to have the convention of not being shown". 
Six of one, half-dozen of the other. I'm not a fan of duck typing, but if it 
walks like a duck, quacks like a duck and has the DNA of a duck...it 
certainly ain't no elephant.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Tuesday, March 01, 2011 14:27:38 Nick Sabalausky wrote:
 "Jesse Phillips" <jessekphillips+D gmail.com> wrote in message
 news:ikj3nf$1l0v$1 digitalmars.com...
 
 Daniel Gibson Wrote:
 .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

 
 I don't like this description, it is a configuration file which just so
 happens to have the convention of not being shown.

 
 That's the exact same thing. "not being shown" == "hidden" What else could
 "not being shown" mean, if not "hidden"? Obstructed view?
 
 Linux doesn't have "hidden" files.

 
 That's just like saying "Windows doesn't have hidden files, it just has
 some files with a flag that happen to have the convention of not being
 shown". Six of one, half-dozen of the other. I'm not a fan of duck typing,
 but if it walks like a duck, quacks like a duck and has the DNA of a
 duck...it certainly ain't no elephant.

No. It's a cat. :)

- Jonathan M Davis


P.S. At least it is if you've seen B5...

"Nick Sabalausky" <a a.a> writes:

"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.2104.1299019810.4748.digitalmars-d puremagic.com...
 On Tuesday, March 01, 2011 14:27:38 Nick Sabalausky wrote:
 "Jesse Phillips" <jessekphillips+D gmail.com> wrote in message
 news:ikj3nf$1l0v$1 digitalmars.com...

 Daniel Gibson Wrote:
 .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

 I don't like this description, it is a configuration file which just so
 happens to have the convention of not being shown.

 That's the exact same thing. "not being shown" == "hidden" What else 
 could
 "not being shown" mean, if not "hidden"? Obstructed view?

 Linux doesn't have "hidden" files.

 That's just like saying "Windows doesn't have hidden files, it just has
 some files with a flag that happen to have the convention of not being
 shown". Six of one, half-dozen of the other. I'm not a fan of duck 
 typing,
 but if it walks like a duck, quacks like a duck and has the DNA of a
 duck...it certainly ain't no elephant.

 No. It's a cat. :)

 - Jonathan M Davis


 P.S. At least it is if you've seen B5...

OMG, I completely forgot about the whole cat thing in Babylon 5 (I assume 
you mean Babylon 5). It's been far too long. Actually, I still haven't 
gotten any further then about halfway through season 4. I really need to 
finish that sometime.

Wait, are you sure that wasn't Andromeda?

Bekenn <leaveme alone.com> writes:

On 3/1/11 2:56 PM, Nick Sabalausky wrote:
 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 No. It's a cat. :)

 - Jonathan M Davis


 P.S. At least it is if you've seen B5...

 OMG, I completely forgot about the whole cat thing in Babylon 5 (I assume
 you mean Babylon 5). It's been far too long. Actually, I still haven't
 gotten any further then about halfway through season 4. I really need to
 finish that sometime.

 Wait, are you sure that wasn't Andromeda?

Definitely Babylon 5.  Brilliant show, despite some unfortunate dialogue 
here and there (of which "being nibbled to death by cats" is *not* an 
example).

"Nick Sabalausky" <a a.a> writes:

"Bekenn" <leaveme alone.com> wrote in message 
news:ikk0ko$a2u$1 digitalmars.com...
 On 3/1/11 2:56 PM, Nick Sabalausky wrote:
 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 No. It's a cat. :)

 - Jonathan M Davis


 P.S. At least it is if you've seen B5...

 OMG, I completely forgot about the whole cat thing in Babylon 5 (I assume
 you mean Babylon 5). It's been far too long. Actually, I still haven't
 gotten any further then about halfway through season 4. I really need to
 finish that sometime.

 Wait, are you sure that wasn't Andromeda?

 Definitely Babylon 5.  Brilliant show, despite some unfortunate dialogue 
 here and there (of which "being nibbled to death by cats" is *not* an 
 example).

Oh, geez, I had *really* forgotten about that, I even had to google it and 
watch a clip before I finally remembered. What I was thinking of was on some 
other scifi show (I think Andromeda) there's a thing about cats being 
extinct, but every once in a while one will just appear on the ship anyway 
(which obviously has no connection to ducks, though).

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Tuesday, March 01, 2011 14:56:20 Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.2104.1299019810.4748.digitalmars-d puremagic.com...
 
 On Tuesday, March 01, 2011 14:27:38 Nick Sabalausky wrote:
 "Jesse Phillips" <jessekphillips+D gmail.com> wrote in message
 news:ikj3nf$1l0v$1 digitalmars.com...
 
 Daniel Gibson Wrote:
 .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

 
 I don't like this description, it is a configuration file which just
 so happens to have the convention of not being shown.

 
 That's the exact same thing. "not being shown" == "hidden" What else
 could
 "not being shown" mean, if not "hidden"? Obstructed view?
 
 Linux doesn't have "hidden" files.

 
 That's just like saying "Windows doesn't have hidden files, it just has
 some files with a flag that happen to have the convention of not being
 shown". Six of one, half-dozen of the other. I'm not a fan of duck
 typing,
 but if it walks like a duck, quacks like a duck and has the DNA of a
 duck...it certainly ain't no elephant.

 
 No. It's a cat. :)
 
 - Jonathan M Davis
 
 
 P.S. At least it is if you've seen B5...

 
 OMG, I completely forgot about the whole cat thing in Babylon 5 (I assume
 you mean Babylon 5). It's been far too long. Actually, I still haven't
 gotten any further then about halfway through season 4. I really need to
 finish that sometime.
 
 Wait, are you sure that wasn't Andromeda?

No. It was Babylon 5. Londo couldn't remember the word for duck and described 
the animal to Vir. And Vir thought that the animal was called a cat (and Londo 
agreed with him). So, instead of talking about being nibbled to death by ducks, 
Londo says that it's like being nibbled to death by cats...

- Jonathan M Davis

Kagamin <spam here.lot> writes:

Nick Sabalausky Wrote:

 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.)

.Net treats it as a nameless file with extension.

Daniel Gibson <metalcaedes gmail.com> writes:

Am 01.03.2011 16:38, schrieb Kagamin:
 Nick Sabalausky Wrote:

 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.)

 .Net treats it as a nameless file with extension.

.Net is designed for windows, obviously.
The right thing to do is to treat a dot at the beginning differently and 
in all other cases define everything behind the last dot as the extension.

Cheers,
- Daniel

"Nick Sabalausky" <a a.a> writes:

"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ikj45k$mbh$3 digitalmars.com...
 Am 01.03.2011 16:38, schrieb Kagamin:
 Nick Sabalausky Wrote:

 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.)

 .Net treats it as a nameless file with extension.

 .Net is designed for windows, obviously.
 The right thing to do is to treat a dot at the beginning differently and 
 in all other cases define everything behind the last dot as the extension.

Yea, the only time you ever have a "nameless file with an extension" on 
windows is if it's a file that just happens to *be* either ".htaccess" or 
".svn" or something else that's already using it in the unix sense (...or if 
OPTLINK errors out...but I'm not sure that's worth counting ;) ). So I don't 
think it makes any sense to have the windows build of an app handle the 
"name vs extension" semantics any differently then it would handle it on 
unix.

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

Kagamin wrote:
 Nick Sabalausky Wrote:
=20
 or just an extentionless file named ".bashrc"? (I know unix doesn't=20
 typically have a concept of file extension, it's all just part of the =


name,=20
 but unix programs will often care about the extension portion of a=20
 filename.)

=20
 .Net treats it as a nameless file with extension.

	Python treats it as a file named =E2=80=9C.bashrc=E2=80=9D with no exten=
sion.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

"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

"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.

Kagamin <spam here.lot> writes:

Nick Sabalausky Wrote:

 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

You can pass program path to CreateProcess without extension, .exe is assumed.

"Nick Sabalausky" <a a.a> writes:

"Kagamin" <spam here.lot> wrote in message 
news:iklanl$1qg$1 digitalmars.com...
 Nick Sabalausky Wrote:

 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

 You can pass program path to CreateProcess without extension, .exe is 
 assumed.

I really don't think that indicates that Windows doesn't consider extension 
part of the filename. It just expects the filename to have an extension for 
certain file types. It's basically just a shortcut for:

if(tryingToRunAProgram && !hasExt(filename))
    filenameRegex = filename~"\.(exe|com|bat)";

Kagamin <spam here.lot> writes:

Nick Sabalausky Wrote:

 "Kagamin" <spam here.lot> wrote in message 
 news:iklanl$1qg$1 digitalmars.com...
 Nick Sabalausky Wrote:

 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

 You can pass program path to CreateProcess without extension, .exe is 
 assumed.

 
 I really don't think that indicates that Windows doesn't consider extension 
 part of the filename. It just expects the filename to have an extension for 
 certain file types. It's basically just a shortcut for:
 
 if(tryingToRunAProgram && !hasExt(filename))
     filenameRegex = filename~"\.(exe|com|bat)";

This indicates that windows is quite smart regarding extensions.

Kagamin <spam here.lot> writes:

Nick Sabalausky Wrote:

 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...

Whether that's a crap is debatable. Sometimes you would want to backup or
manage that crap, say, game saves.

"Nick Sabalausky" <a a.a> writes:

"Kagamin" <spam here.lot> wrote in message 
news:ikntvs$23rr$1 digitalmars.com...
 Nick Sabalausky Wrote:

 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...

 Whether that's a crap is debatable. Sometimes you would want to backup or 
 manage that crap, say, game saves.

I didn't say it shouldn't exist, I just said it shouldn't be in the user's 
documents directory. 

Kagamin <spam here.lot> writes:

Nick Sabalausky Wrote:

 Whether that's a crap is debatable. Sometimes you would want to backup or 
 manage that crap, say, game saves.

 
 I didn't say it shouldn't exist, I just said it shouldn't be in the user's 
 documents directory. 

If they're in "My Documents/Local Settings" you can't navigate there easily
from explorer so you can't copy/backup them or share with your friend.

Kagamin <spam here.lot> writes:

Kagamin Wrote:

 Nick Sabalausky Wrote:
 
 Whether that's a crap is debatable. Sometimes you would want to backup or 
 manage that crap, say, game saves.

 
 I didn't say it shouldn't exist, I just said it shouldn't be in the user's 
 documents directory. 

 
 If they're in "My Documents/Local Settings" you can't navigate there easily
from explorer so you can't copy/backup them or share with your friend.

oops
"My Documents/../Local Settings"

"Nick Sabalausky" <a a.a> writes:

"Kagamin" <spam here.lot> wrote in message 
news:ikohfp$8go$1 digitalmars.com...
 Kagamin Wrote:

 Nick Sabalausky Wrote:

 Whether that's a crap is debatable. Sometimes you would want to 
 backup or
 manage that crap, say, game saves.

 I didn't say it shouldn't exist, I just said it shouldn't be in the 
 user's
 documents directory.

 If they're in "My Documents/Local Settings" you can't navigate there 
 easily from explorer so you can't copy/backup them or share with your 
 friend.

 oops
 "My Documents/../Local Settings"

It's not as if that's a hidden directory.

Kagamin <spam here.lot> writes:

Jérôme M. Berger 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.

 
 	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.

I think, the same happens on unix. Is the script to be flagged executable to be
run, just like any other runnable file?

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday 04 March 2011 00:08:25 Kagamin wrote:
 J=C3=A9r=C3=B4me M. Berger 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.

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

 =09
 	No you cannot. What happens is that you *open* them with the
=20
 default application, which just happens to be an interpreter whose
 default action is to run the script.

=20
 I think, the same happens on unix. Is the script to be flagged executable
 to be run, just like any other runnable file?

The only way _anything_ is executable in *nix is if its executable flag is =
set.=20
Extensions mean _nothing_ as far as executability goes.

=2D Jonathan M Davis

Kagamin <spam here.lot> writes:

Jonathan M Davis Wrote:

 On Friday 04 March 2011 00:08:25 Kagamin wrote:
 Jérôme M. Berger 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.

 	
 	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.

 
 I think, the same happens on unix. Is the script to be flagged executable
 to be run, just like any other runnable file?

 
 The only way _anything_ is executable in *nix is if its executable flag is
set. 
 Extensions mean _nothing_ as far as executability goes.

As you can see, there's an ambiguity here: script is not executed directly in
the same sense as machine code, so it may be not called an execution and not
require executable flag to be interpreted. Actual application beign executed is
interpreter. So the question is whether a script have to be flagged executable
in order to run interpreter on it.

Daniel Gibson <metalcaedes gmail.com> writes:

Am 04.03.2011 09:56, schrieb Kagamin:
 Jonathan M Davis Wrote:
 
 On Friday 04 March 2011 00:08:25 Kagamin wrote:
 Jérôme M. Berger 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.

 	
 	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.

 I think, the same happens on unix. Is the script to be flagged executable
 to be run, just like any other runnable file?

 The only way _anything_ is executable in *nix is if its executable flag is
set. 
 Extensions mean _nothing_ as far as executability goes.

 
 As you can see, there's an ambiguity here: script is not executed directly in
the same sense as machine code, so it may be not called an execution and not
require executable flag to be interpreted. Actual application beign executed is
interpreter. So the question is whether a script have to be flagged executable
in order to run interpreter on it.

On *nix: Yes. Scripts have to be flagged executable. (Of course you can start a
non-executable script with e.g. bash foo.sh)

Kagamin <spam here.lot> writes:

Daniel Gibson Wrote:

 The only way _anything_ is executable in *nix is if its executable flag is
set. 
 Extensions mean _nothing_ as far as executability goes.

 
 As you can see, there's an ambiguity here: script is not executed directly in
the same sense as machine code, so it may be not called an execution and not
require executable flag to be interpreted. Actual application beign executed is
interpreter. So the question is whether a script have to be flagged executable
in order to run interpreter on it.

 
 On *nix: Yes. Scripts have to be flagged executable. (Of course you can start a
 non-executable script with e.g. bash foo.sh)

I suppose, the flag on a script is checked "manually" by the shell, and on a
binary - by the OS.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday 04 March 2011 02:02:45 Kagamin wrote:
 Daniel Gibson Wrote:
 The only way _anything_ is executable in *nix is if its executable
 flag is set. Extensions mean _nothing_ as far as executability goes.

 
 As you can see, there's an ambiguity here: script is not executed
 directly in the same sense as machine code, so it may be not called an
 execution and not require executable flag to be interpreted. Actual
 application beign executed is interpreter. So the question is whether
 a script have to be flagged executable in order to run interpreter on
 it.

 
 On *nix: Yes. Scripts have to be flagged executable. (Of course you can
 start a non-executable script with e.g. bash foo.sh)

 
 I suppose, the flag on a script is checked "manually" by the shell, and on
 a binary - by the OS.

The "OS" means next to nothing in unix land. What's the OS? The kernel? The set 
of common utilities? The whole environment? What matters is how the command
line 
shell is implemented and how file permissions work. Per how file permissions
work, 
a file must have the executable flag set either for all or for the group that
the 
user is in, or it must be set for the owner of the file and the user running
the 
file must be the owner of the file. If it is executable for that user, then the 
shell will attempt execute it. If not, they're not allowed to. Another program 
could attempt to read it and do something with it assuming that the user has 
read permissions for the file, but it can't be directly executed.

So, in the case of a shell script, you have to have permission to execute the 
file if you wish to execute it, and you have to have permission to read it if
you 
want to pass it to some other sort of executable (such as a command to start a 
new shell) in order to run it that way. But ultimately, whether an executable 
file is a binary or not is irrelevant.

- Jonathan M Davis 

Kagamin <spam here.lot> writes:

Jonathan M Davis Wrote:

 I suppose, the flag on a script is checked "manually" by the shell, and on
 a binary - by the OS.

 
 The "OS" means next to nothing in unix land. What's the OS? The kernel? The
set 
 of common utilities?

Oh, looking at execve(2), I see, shebang is processed by the kernel. Wow.

 file must be the owner of the file. If it is executable for that user, then
the 
 shell will attempt execute it. If not, they're not allowed to. Another program 
 could attempt to read it and do something with it assuming that the user has 
 read permissions for the file, but it can't be directly executed.

Well, no script can be directly executed, it's just a text after all. What
execve does is not really a direct execution.

spir <denis.spir gmail.com> writes:

On 03/04/2011 09:56 AM, Kagamin wrote:
 Jonathan M Davis Wrote:

 On Friday 04 March 2011 00:08:25 Kagamin wrote:
 Jérôme M. Berger 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.

 	
 	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.

 I think, the same happens on unix. Is the script to be flagged executable
 to be run, just like any other runnable file?

 The only way _anything_ is executable in *nix is if its executable flag is set.
 Extensions mean _nothing_ as far as executability goes.

 As you can see, there's an ambiguity here: script is not executed directly in
the same sense as machine code, so it may be not called an execution and not
require executable flag to be interpreted. Actual application beign executed is
interpreter. So the question is whether a script have to be flagged executable
in order to run interpreter on it.

What do you expect? *nixWorld is HackLand, in all senses of 'hack' ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com