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

• Nick Sabalausky (27/27) Mar 01 2011 According to the docs, std.path.getName() "Returns the extensionless ver...
• Jonathan M Davis (14/50) Mar 01 2011 I would agree. I would _think_ that it would return the file name minus ...
• Nick Sabalausky (12/21) Mar 01 2011 Due to the practical need for dealing with Unixy systems (for instance, ...
• Jonathan M Davis (12/36) Mar 01 2011 If a program were trying to treat .bashrc like it had an extension, I wo...
• Daniel Gibson (8/31) Mar 01 2011 .bashrc doesn't have an extension and is not an extionsion either.
• Nick Sabalausky (4/8) Mar 01 2011 I know. I was just wondering how the semantics of "name" and "extension"...
• Steven Schveighoffer (7/18) Mar 01 2011 I would say it is not an extension, it is the filename. On unix only
• Nick Sabalausky (8/23) Mar 01 2011 As a windows guy, I would want windows builds to handle that however uni...
• Jim (4/31) Mar 01 2011 No, a filename that begins with a dot is just meant to be "invisible", b...
• spir (17/40) Mar 01 2011 To be consistent with how things work on Unixes, file names starting wit...
• Steven Schveighoffer (4/10) Mar 01 2011 / and \ are not legal in names on any filesystem that I know of.
• Lars T. Kyllingstad (5/18) Mar 01 2011 On a *NIX machine, try
• Steven Schveighoffer (10/27) Mar 01 2011 bleh... that seems useless :) I purposely checked FAT before posting,
• Nick Sabalausky (9/39) Mar 01 2011 Windows also handles files/paths with spaces a hell of a lot better than...
• Daniel Gibson (6/50) Mar 01 2011 It does? In what ways? In Unix you just have to escape spaces with
• Nick Sabalausky (13/60) Mar 01 2011 There's a long, seemingly-unending history of unix programs choking on p...
• Daniel Gibson (8/74) Mar 01 2011 This is a problem of *programs* not dealing properly with spaces in
• Nick Sabalausky (4/29) Mar 01 2011 Unix is nothing more than a kernel + programs anyway (or at least Linux)...
• Daniel Gibson (9/42) Mar 01 2011 Yeah. My point was that it's not because of shortcomings of APIs in Unix...
• Andrei Alexandrescu (4/7) Mar 01 2011 make and latex are prime examples. I have made an executive decision to
• Walter Bright (6/14) Mar 01 2011 Similarly, never use / as a path separator in Windows. Sure, it works so...
• Bekenn (3/5) Mar 01 2011 No kidding. Thank goodness that's gone post-XP. Now if only they'd do
• Daniel Gibson (2/8) Mar 01 2011 Or "My Documents", "My Pictures" and whatnot (or is that gone post-XP?)
• Bekenn (4/5) Mar 01 2011 Yes, those are gone. "My Documents" is just "Documents", "My Pictures"
• Walter Bright (2/8) Mar 01 2011 Let's hope "My" got severance pay for its years of meaningless service!
• Walter Bright (5/11) Mar 01 2011
• Bekenn (5/9) Mar 01 2011 Ah, this one (folders) I actually have a response for. Or, rather,
• Walter Bright (2/5) Mar 01 2011 I didn't know that. Thanks for the link!
• Bekenn (2/3) Mar 01 2011 No problem.
• Kagamin (2/8) Mar 02 2011 Did both on my xp, have /home and /programs.
• Nick Sabalausky (9/17) Mar 02 2011 I moved my pictures and music folders to the root of a secondary drive. ...
• Steven Schveighoffer (5/27) Mar 03 2011 With windows 7, the notion of storing in subdirectories is mostly
• Bruno Medeiros (9/17) Mar 08 2011 Me too, have been doing that for several years, ever since I found out
• Lars T. Kyllingstad (13/56) Mar 01 2011 I really don't understand what you guys are talking about. If you
• Daniel Gibson (7/63) Mar 01 2011 There are some fun special cases in Windows (originating in DOS):
• Nick Sabalausky (20/91) Mar 01 2011 My interpretation of that is: Those are all under "Naming Conventions", ...
• Steven Schveighoffer (15/27) Mar 01 2011 You still have to worry about them, because the shell treats them
• Lars T. Kyllingstad (5/29) Mar 01 2011 If you are using a command line shell you ought to know better than
• Jonathan M Davis (18/51) Mar 01 2011 Actually, a number of unix file systems allow / in the name too. The ext...
• Johannes Pfau (14/24) Mar 01 2011 Just tested it on ubuntu/ext4 and '\' in a filename works.
• Nick Sabalausky (14/23) Mar 01 2011 Strictly speaking, most filesystems are perfectly capable of having any
• Lars T. Kyllingstad (18/57) Mar 01 2011 I've also found a few cases like that. In general, I think std.path
• Jonathan M Davis (10/72) Mar 01 2011 Obviously it's a work in process and not something that you're looking t...
• Lars T. Kyllingstad (11/86) Mar 01 2011 It's definitely a work in progress, and therefore I'm not going to debat...
• Nick Sabalausky (13/19) Mar 01 2011 Speaking of sep, I've never been entirely happy with std.path's tendency...
• Lars T. Kyllingstad (6/29) Mar 01 2011 This was discussed on the Phobos mailing list a while ago, and Walter
• Nick Sabalausky (9/37) Mar 01 2011 *shrug* The only problems I've ever had with forward-slash on Windows is...
• Nick Sabalausky (39/55) Mar 01 2011 Just took a look at the doc page. I know it's not finished, but my comme...
• Lars T. Kyllingstad (19/86) Mar 02 2011 I agree. I changed this yesterday, and now it does the same on Windows
• spir (7/34) Mar 01 2011 +++
• Daniel Gibson (5/32) Mar 01 2011 And what about "foo.tar.gz"? Does it return "foo" or "foo.tar"? And what...
• Jonathan M Davis (5/49) Mar 01 2011 I'd definitely argue that everything to the right of the first dot in th...
• Andrei Alexandrescu (6/55) Mar 01 2011 If we want to stick with the notion of the extension, it should be the
• Jonathan M Davis (8/66) Mar 01 2011 Yeah, you're probably right. I definitely think of file.tar.gz as having...
• retard (8/77) Mar 01 2011 In the *nix land most common extensions of this sort
• retard (2/3) Mar 01 2011 Sorry about the typo, .pdf.gz
• Lars T. Kyllingstad (6/51) Mar 01 2011 That's a good question. And what about "foo-1.0.4.tar.gz"? I say only
• Nick Sabalausky (9/59) Mar 01 2011 I agree. I've always seen the ".tar" in "xxxx.tar.gz" as merely a conven...
• Jens Mueller (10/62) Mar 01 2011 I don't know whether this is useful but why not look at what is already
• Lars T. Kyllingstad (6/66) Mar 01 2011 I have used Linux's basename and dirname commands as the model for my
• Nick Sabalausky (10/21) Mar 01 2011 People don't always realize it, but Windows really is the same way. It's...
• Steven Schveighoffer (6/31) Mar 01 2011 Didn't the FAT16 filesystem require something in the name portion of the...
• Don (7/38) Mar 01 2011 No, it tries hard to make it look that way, but it's evolved from a
• Nick Sabalausky (13/29) Mar 01 2011 The existence of an 8.3 fallback doesn't really have any bearing on it. ...
• Don (10/41) Mar 03 2011 ??????
• Nick Sabalausky (4/46) Mar 03 2011 Because windows occasionally cares about the extention doesn't imply it
• Kagamin (3/8) Mar 03 2011 What do you mean? You can run .js and .vbs files as well.
• Jesse Phillips (7/15) Mar 01 2011 I don't like this description, it is a configuration file which just so ...
• Nick Sabalausky (9/16) Mar 01 2011 That's the exact same thing. "not being shown" == "hidden" What else cou...
• Jonathan M Davis (4/25) Mar 01 2011 No. It's a cat. :)
• Nick Sabalausky (7/34) Mar 01 2011 OMG, I completely forgot about the whole cat thing in Babylon 5 (I assum...
• Bekenn (4/16) Mar 01 2011 Definitely Babylon 5. Brilliant show, despite some unfortunate dialogue...
• Jonathan M Davis (6/47) Mar 01 2011 No. It was Babylon 5. Londo couldn't remember the word for duck and desc...
• Kagamin (2/6) Mar 01 2011 .Net treats it as a nameless file with extension.
• Lars T. Kyllingstad (5/5) Mar 01 2011 Since we're on the topic of std.path, does anyone have an opinion as to
• Nick Sabalausky (3/7) Mar 01 2011 I see no reason why not. Or at least, once 'inout' works.
• Kagamin (2/5) Mar 02 2011 You can pass program path to CreateProcess without extension, .exe is as...
• Nick Sabalausky (7/14) Mar 02 2011 I really don't think that indicates that Windows doesn't consider extens...
• Kagamin (2/20) Mar 03 2011 This indicates that windows is quite smart regarding extensions.
• Kagamin (2/5) Mar 03 2011 Whether that's a crap is debatable. Sometimes you would want to backup o...
• Nick Sabalausky (4/11) Mar 03 2011 I didn't say it shouldn't exist, I just said it shouldn't be in the user...
• Kagamin (2/7) Mar 03 2011 If they're in "My Documents/Local Settings" you can't navigate there eas...
• Kagamin (2/14) Mar 04 2011 I think, the same happens on unix. Is the script to be flagged executabl...
• Jonathan M Davis (5/21) Mar 04 2011 The only way _anything_ is executable in *nix is if its executable flag ...
• Kagamin (2/22) Mar 04 2011 As you can see, there's an ambiguity here: script is not executed direct...
• Daniel Gibson (3/27) Mar 04 2011 On *nix: Yes. Scripts have to be flagged executable. (Of course you can ...
• Kagamin (2/9) Mar 04 2011 I suppose, the flag on a script is checked "manually" by the shell, and ...
• Jonathan M Davis (16/32) Mar 04 2011 The "OS" means next to nothing in unix land. What's the OS? The kernel? ...
• Kagamin (3/12) Mar 04 2011 Well, no script can be directly executed, it's just a text after all. Wh...
• spir (7/29) Mar 04 2011 What do you expect? *nixWorld is HackLand, in all senses of 'hack' ;-)
"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.

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

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

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

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

Mar 01 2011
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.

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

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

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

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

I think that I agree with you on all counts. I can understand if the path stuff
can't deal with / or \ in file names (that's probably not worth trying to get
to
work right), but it _should_ be able to handle directories with dots in them
and
files with no extension. Files without extension may be uncommon in Windows,
but
they're common enough on Linux.

- Jonathan M Davis

Mar 01 2011
"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
even on Windows, and even though I'm primarily a Windows user.

That reminds me of something I've often wondered, though: Does unix consider
a file named ".bashrc" to be a nameless file with an extension of "bashrc",
or just an extentionless file named ".bashrc"? (I know unix doesn't
typically have a concept of file extension, it's all just part of the name,
but unix programs will often care about the extension portion of a
filename.)

Mar 01 2011
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
even on Windows, and even though I'm primarily a Windows user.

That reminds me of something I've often wondered, though: Does unix
consider a file named ".bashrc" to be a nameless file with an extension of
"bashrc", or just an extentionless file named ".bashrc"? (I know unix
doesn't typically have a concept of file extension, it's all just part of
the name, but unix programs will often care about the extension portion of
a filename.)

If a program were trying to treat .bashrc like it had an extension, I would
expect it to be treated as a file with no name and bashrc as its extension. I
don't think that anything else mould make sense. However, it's a prime example
of a situation where extensions make no sense. In general, Linux isn't big on
extensions. The DEs generally use MIME types to determine the type of a file
rather than its extension, and most programs follow suit. But in the rare case
where a program would care about extensions, I would expect it to be looking
for
_specific_ extensions (like mp3 or flac or pdf or whatever), so it wouldn't be
looking for a .bashrc file and it wouldn't really matter if it treated its
extension as bashrc.

- Jonathan M Davis

Mar 01 2011
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
even on Windows, and even though I'm primarily a Windows user.

That reminds me of something I've often wondered, though: Does unix consider
a file named ".bashrc" to be a nameless file with an extension of "bashrc",
or just an extentionless file named ".bashrc"? (I know unix doesn't
typically have a concept of file extension, it's all just part of the name,
but unix programs will often care about the extension portion of a
filename.)

.bashrc doesn't have an extension and is not an extionsion either.
The "." at the start is Unix convention to say "this is a hidden
file/folder", this means "ls" (the unix equivalent to "dir") doesn't
list them (ls -a does, though) and most file browsers only list them
when you select something like "show hidden files" or "show dot files".

Cheers,
- Daniel

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

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

Mar 01 2011
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 07:50:53 -0500, Nick Sabalausky <a a.a> wrote:

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

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

I would say it is not an extension, it is the filename.  On unix only
though.  And as to my opinion on files with multiple dots, the last one is
the extension, the others are part of the filename.

FYI In addition to ls not listing them, the shell doesn't consider them in
* expansion.  so echo * does not show hidden files.

-Steve

Mar 01 2011
"Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
news:op.vrn0zlu4eav7ka steve-laptop...
On Tue, 01 Mar 2011 07:50:53 -0500, Nick Sabalausky <a a.a> wrote:

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

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

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

As a windows guy, I would want windows builds to handle that however unix
handles it. Filenames that start with a dot are not at all a windows thing,
but on windows there *is* often a need to deal with unix files or unix
tools. For instance, when using Apache or developing for an external Apache
server even windows users still need to deal with .htaccess. And when they
do, it needs to work right.

Mar 01 2011
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
even on Windows, and even though I'm primarily a Windows user.

That reminds me of something I've often wondered, though: Does unix consider
a file named ".bashrc" to be a nameless file with an extension of "bashrc",
or just an extentionless file named ".bashrc"? (I know unix doesn't
typically have a concept of file extension, it's all just part of the name,
but unix programs will often care about the extension portion of a
filename.)

No, a filename that begins with a dot is just meant to be "invisible", but the
dot is in all respects a part of the name.

The whole idea of _not_ showing the extensions was probably conjured up in the
Usability department at Microsoft? I don't remember if they were mandatory in
DOS.

In Unix extensions has simply been regarded as part of the name without a fuss.
With modern GUIs it seems that this has shifted. But the invisibility dot
should not be confused with the extension dot.

Mar 01 2011
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
even on Windows, and even though I'm primarily a Windows user.

That reminds me of something I've often wondered, though: Does unix consider
a file named ".bashrc" to be a nameless file with an extension of "bashrc",
or just an extentionless file named ".bashrc"? (I know unix doesn't
typically have a concept of file extension, it's all just part of the name,
but unix programs will often care about the extension portion of a
filename.)

To be consistent with how things work on Unixes, file names starting with a '.'
should be special-cased.
This '.' is a conventional code just meaning normal users should not cope with
such files/dirs during normal use (and thus such files do not appear on normal
dir content lists). It definitely has nothing to do with the notion of
extension (which as you say is not a primary notion on Unixes). Treating it as
an extension would totally be buggy.

I would thus approve
assert( getName("/home/me/.foo" == "/home/me/.foo" );
assert( getName("/home/me/.foo.cfg" == "/home/me/.foo" );
on Unixes, provided this behaviour is well documented.

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

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

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

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

-Steve

Mar 01 2011
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 08:02:44 -0500, Steven Schveighoffer wrote:

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

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

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

-Steve

On a *NIX machine, try

touch "c:\\foo\\bar"

You may be surprised. ;)

-Lars

Mar 01 2011
"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!

really, the only disallowed character in unix filenames is '/'.  Even '*'
is allowed as a filename.  How... horrible.

-Steve

Mar 01 2011
"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.)

really, the only disallowed character in unix filenames is '/'.  Even '*'
is allowed as a filename.  How... horrible.

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

Mar 01 2011
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.

really, the only disallowed character in unix filenames is '/'.  Even '*'
is allowed as a filename.  How... horrible.

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


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

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

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

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

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

-Steve

On a *NIX machine, try

touch "c:\\foo\\bar"

You may be surprised. ;)

bleh... that seems useless :)  I purposely checked FAT before posting,
because I was sure Unix disallowed backslashes, I wanted to make sure
FAT
didn't allow slashes.

Holy crap, something that DOS got right and Unix didn't!

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

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

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

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

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

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

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

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

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

-Steve

On a *NIX machine, try

touch "c:\\foo\\bar"

You may be surprised. ;)

bleh... that seems useless :)  I purposely checked FAT before posting,
because I was sure Unix disallowed backslashes, I wanted to make sure
FAT
didn't allow slashes.

Holy crap, something that DOS got right and Unix didn't!

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

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

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

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

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

Cheers,
- Daniel

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

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

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

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

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

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

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

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

Yeah. My point was that it's not because of shortcomings of APIs in Unix (that
winapi handles better or something), but it's just because Unix coders aren't
(or at least weren't) as aware of possible problems with spaces.
Your original statement was "Windows also handles files/paths with spaces a hell
of a lot better than Unix." so I thought you were talking about the OS (or APIs
that are very close to the OS) and not about applications :-)

Cheers,
- Daniel

Mar 01 2011
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/1/11 3:42 PM, Nick Sabalausky wrote:
There's a long, seemingly-unending history of unix programs choking on paths
with spaces in them *even* when you give them the paths properly escaped.
Not all unix apps, but enough.

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

Andrei

Mar 01 2011
Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
On 3/1/11 3:42 PM, Nick Sabalausky wrote:
There's a long, seemingly-unending history of unix programs choking on
paths
with spaces in them *even* when you give them the paths properly escaped.
Not all unix apps, but enough.

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

Similarly, never use / as a path separator in Windows. Sure, it works
sometimes.
But it often fails in random ways, even with Windows system programs. For
example, / doesn't work with the COPY command.

I've always hated the Windows "Documents and Settings" subdirectory. Arggh.
Always a pain to use on the command line.

Mar 01 2011
Bekenn <leaveme alone.com> writes:
On 3/1/11 3:27 PM, Walter Bright wrote:
I've always hated the Windows "Documents and Settings" subdirectory.
Arggh. Always a pain to use on the command line.

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

Mar 01 2011
Daniel Gibson <metalcaedes gmail.com> writes:
Am 02.03.2011 00:37, schrieb Bekenn:
On 3/1/11 3:27 PM, Walter Bright wrote:
I've always hated the Windows "Documents and Settings" subdirectory.
Arggh. Always a pain to use on the command line.

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

Or "My Documents", "My Pictures" and whatnot (or is that gone post-XP?)

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

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

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

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

Let's hope "My" got severance pay for its years of meaningless service!

Mar 01 2011
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
to be renamed "folders".

</oldguyrant>

Mar 01 2011
Bekenn <leaveme alone.com> writes:
On 3/1/11 5:26 PM, Walter Bright wrote:
<oldguyrant>

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

</oldguyrant>

Ah, this one (folders) I actually have a response for.  Or, rather,
Raymond Chen does:
http://blogs.msdn.com/b/oldnewthing/archive/2011/02/16/10129908.aspx

Absolutely agreed re: "Programs".

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

I didn't know that. Thanks for the link!

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

No problem.

Mar 01 2011
Kagamin <spam here.lot> writes:
Bekenn Wrote:

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

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

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

Mar 02 2011
"Nick Sabalausky" <a a.a> writes:
"Kagamin" <spam here.lot> wrote in message
news:ikl9vq$b0$1 digitalmars.com...
Bekenn Wrote:

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

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

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

I moved my pictures and music folders to the root of a secondary drive. Kept
the same names, athough I don't know why. Maybe I'm just used to it.

Now if only I could get programs to quit cluttering "My Documents" with
their misc junk, instead of "My Documents/.." where all that crap belongs,
*that* would make me happy...(In the meantime, I've created a "My Docs"
subdir of "My Documents" that I use as my *real* documents dir - an annoying
kludge).

Mar 02 2011
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 02 Mar 2011 16:27:59 -0500, Nick Sabalausky <a a.a> wrote:

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

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

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

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

I moved my pictures and music folders to the root of a secondary drive.
Kept
the same names, athough I don't know why. Maybe I'm just used to it.

Now if only I could get programs to quit cluttering "My Documents" with
their misc junk, instead of "My Documents/.." where all that crap
belongs,
*that* would make me happy...(In the meantime, I've created a "My Docs"
subdir of "My Documents" that I use as my *real* documents dir - an
annoying
kludge).

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

-Steve

Mar 03 2011
Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 02/03/2011 11:34, Kagamin wrote:
Bekenn Wrote:

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

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

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

Me too, have been doing that for several years, ever since I found out
it was possible to do it in a clean, non-hacky way. And the nLite
customization tool makes it very easy to do that.

It's a shame Windows 7 doesn't support that anymore. Although they have
renamed "Documents and Settings" to "Users", so it's not too bad, it's
much better than the XP defaults.

--
Bruno Medeiros - Software Engineer

Mar 08 2011
"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.

really, the only disallowed character in unix filenames is '/'.  Even
'*' is allowed as a filename.  How... horrible.

Yeah, the only illegal filename characters are '/' and null.

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

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

-Lars

Mar 01 2011
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.

really, the only disallowed character in unix filenames is '/'.  Even
'*' is allowed as a filename.  How... horrible.

Yeah, the only illegal filename characters are '/' and null.

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

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

-Lars

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

Cheers,
- Daniel

Mar 01 2011
"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.

really, the only disallowed character in unix filenames is '/'.  Even
'*' is allowed as a filename.  How... horrible.

Yeah, the only illegal filename characters are '/' and null.

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

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

-Lars

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

My interpretation of that is: Those are all under "Naming Conventions", so
it's not so much "illegal names" as it is "names that your programs
shouldn't allow".

Although, my interpretation might be wrong...Some interesting little
experiments I just tried (WinXP):

- In Explorer, rename a file to "CON": Nothing happens. The filename remains
unchanged and no message occurs. Same result with "con".

- In Explorer, rename a file to "CON.txt". Error message: "A file with the
name you specified already exists." Same result with "con.txt".

- Some of the commandline apps I've written in D2/Phobos take an output
filename on the comand line. Using one of them to try to create a file named
either "CON", "CON.txt", "con", or "con.txt" results in the file's content
being displayed to the screen (and a whole hell of a lot of beeping, since
it's a binary file ;) ). No actual file was created as far as I could tell.

But I woudn't be surprised if there's some API other than whatever Phobos
uses that might allow it.

In any case, score one for unix including special names like that as part of
the filesystem.

Mar 01 2011
"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

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

Mar 01 2011
"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

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

Mar 01 2011
"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

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

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

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

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

Mar 01 2011
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 10:39:35 -0500, Adam Ruppe <destructionator gmail.com>
wrote:

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

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

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

ooooh, that is NASTY.

-Steve

Mar 01 2011
=?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

Mar 01 2011
"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

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

Mar 01 2011
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 10:52:43 -0500, Lars T. Kyllingstad
<public kyllingen.nospamnet> wrote:

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

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

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

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

-Steve

Mar 01 2011
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 10:55:57 -0500, Steven Schveighoffer wrote:

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

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

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

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

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

But std.path doesn't have to deal with these issues.  std.path is
basically a bunch of functions that search for '/', '\' or '.' in some
string.  The only special case it needs to worry about is that '\' is an
ordinary character on POSIX and a dir separator on Windows.

If you want to disallow creating files named "-rf *", that'll have to be
done in std.stdio and std.file.

-Lars

Mar 01 2011
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 11:04:52 -0500, Lars T. Kyllingstad
<public kyllingen.nospamnet> wrote:

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

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

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

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

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

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

But std.path doesn't have to deal with these issues.  std.path is
basically a bunch of functions that search for '/', '\' or '.' in some
string.  The only special case it needs to worry about is that '\' is an
ordinary character on POSIX and a dir separator on Windows.

If you want to disallow creating files named "-rf *", that'll have to be
done in std.stdio and std.file.

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

-Steve

Mar 01 2011
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 11:07:15 -0500, Steven Schveighoffer wrote:

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

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

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

But std.path doesn't have to deal with these issues.  std.path is
basically a bunch of functions that search for '/', '\' or '.' in some
string.  The only special case it needs to worry about is that '\' is
an ordinary character on POSIX and a dir separator on Windows.

If you want to disallow creating files named "-rf *", that'll have to
be done in std.stdio and std.file.

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

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

-Lars

Mar 01 2011
Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 01 March 2011 08:15:35 Lars T. Kyllingstad wrote:
On Tue, 01 Mar 2011 11:07:15 -0500, Steven Schveighoffer wrote:
On Tue, 01 Mar 2011 11:04:52 -0500, Lars T. Kyllingstad

<public kyllingen.nospamnet> wrote:
On Tue, 01 Mar 2011 10:55:57 -0500, Steven Schveighoffer wrote:
The point of this whole discussion is how should phobos' std.path deal
with filenames.  I thought that was implied.

But std.path doesn't have to deal with these issues.  std.path is
basically a bunch of functions that search for '/', '\' or '.' in some
string.  The only special case it needs to worry about is that '\' is
an ordinary character on POSIX and a dir separator on Windows.

If you want to disallow creating files named "-rf *", that'll have to
be done in std.stdio and std.file.

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

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

I previously suggested that we have a function which converts a file name so
that
it's valid on Windows (replacing invalid characters with valid ones), and IIRC
Andrei was against it, because it was file system specific or somesuch. I
definitely do that in at least one of my programs though. Another function that
I
find highly useful is one which escapes file names so that they're safe to use
in
a shell (the one I have wraps the file name in ' and then turn and 's in the
file
into '\''), but that could easily be shell-specific and might not be reasonable
either. I do like the idea of both functions however. I use them all the time.

- Jonathan M Davis

Mar 01 2011
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!

really, the only disallowed character in unix filenames is '/'.  Even '*'
is allowed as a filename.  How... horrible.

Actually, a number of unix file systems allow / in the name too. The extX file
systems don't, but reiserFS, btrfs, and XFS are some of those which do. The
only
character which is _certain_ that it can't be valid in a file name, I believe
is
NUL. However, given how much of a royal pain it would be to handle / correctly
in file names and how so few programs are able to handle files with / in their
name, I don't think that it's worth trying to make std.path handle file names
with / in them correctly. _Maybe_ it should handle \ correctly on Linux, but
even then, I'd argue that it shouldn't be trying to special case it.

Now, as for other characters like * or :, I've found it to be _very_ useful to
be able to put those in file names - particularly when ripping music - and the
fact that Windows is far more restrictive in what it allows in file names is
highly annoying. I _like_ the fact that Linux lets you put pretty much any
character in a file name. I do think that trying to fully support / and \ is
pushing it however - particularly since it's highly unlikely that they'll be
handled correctly by other programs anyway. Too many programmers have already
assumed that they aren't legal characters in file names.

- Jonathan M Davis

Mar 01 2011
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

Mar 01 2011
"Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
news:op.vrn06uqneav7ka steve-laptop...
On Tue, 01 Mar 2011 04:16:36 -0500, Jonathan M Davis <jmdavisProg gmx.com>
wrote:

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

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

Strictly speaking, most filesystems are perfectly capable of having any
character in the filename, even control characters. I know that's definitely
the case with FAT32 and NTFS. This has occasionally been used to create
files that are a royal PITA to delete (either as a prank or as a malware
technique). It's just that the software that interacts with the filesystem
(possibly the filesystem driver itself) either can't always cope with
certain characters or generally chooses to reject them before actually
committing to the filesystem.

That said, there's no reason to bend over backwards trying to support such
characters that *shouldn't* exist in file/path names, unless you're making a
tool specifically designed to deal with that sort of thing (in which case
you might need to bypass the usual IO APIs anyway).

Mar 01 2011
"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.

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

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

-Lars

Mar 01 2011
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.

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

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

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

- Jonathan M Davis

Mar 01 2011
"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.

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

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

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

It's definitely a work in progress, and therefore I'm not going to debate
the naming scheme yet.  First I'll need to get the functionality in
place. ;)

I would like to say, however, that I think 'sep' is almost up there with
rel2abs in terms of bad naming.  If you just see 'sep' in a piece of
code, maybe you understand it is a separator, but I don't think everyone
will conclude it is a directory separator.  Using the fully qualified
name 'std.path.sep' isn't good either, because now it looks like it's a
path separator.

-Lars

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

Speaking of sep, I've never been entirely happy with std.path's tendency to
encourage the use of platform-specific directory separators. Windows
generally handles forward-slash just fine, so I've always felt it best to
always just use forward-slash, and then convert to backslash as-needed in
the very rare cases where it actually matters.

Doing either std.path.join("..", "dir", "subdir", "file") or
".."~sep~"dir"~sep~"subdir"~sep~"file" is fucking butt-ugly, and it's
useless anyway since "../dir/subdir/file" works just fine on all OSes
including Windows. (Obviously sep should still exist, regardless of what
it's named. But, at least judging by the docs, std.path just seems to rely
on it too much.)

Mar 01 2011
"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

Mar 01 2011
"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.

Mar 01 2011
"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

Just took a look at the doc page. I know it's not finished, but my comments
based on how it is ATM:

- toCanonical is something that std.path desperately needs. Without it, it's
impossible to compare paths. I found the lack of it to be a big pain when I
switched from Tango to Phobos2.

- Like I've said in other posts, I strongly believe that if posix considers
".foo" to be an extensionless file named ".foo", then it should definitely
be treated the *same way* on windows too, since the only times windows ever
has such files is things like ".htaccess" or ".svn" that are already born of
unix anyway. (Optlink's stray ".exe" junk files notwithstanding.)

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

- Still some casing inconsistencies: basename, dirname, drivename still
aren't camel-cased, but should be.

- It needs a function to remove the extension (while keeping the filename
*and* path). Basically, it needs something that's akin to
std.path.getName(), but actually works right.

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

Everything else about it looks great.

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

Mar 01 2011
"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

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
junk files notwithstanding.)

I agree.  I changed this yesterday, and now it does the same on Windows
and POSIX.

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

Actually, in my experience, all of the strings defined at the top of
std.path are next to useless.  Most of the time I need to check "is this
character a dir separator?", and then I have to do

if (path[i] == sep[0] || path[i] == altsep[0]) ...

So I wrote an isDirSeparator() function that performs these tests, and
I've ended up using that almost exclusively.  The only place I expect to
be using the predefined strings is in the join() function.

- Still some casing inconsistencies: basename, dirname, drivename still
aren't camel-cased, but should be.

I know.  The naming scheme is by no means set in stone, I'm saving that
for last.

- It needs a function to remove the extension (while keeping the
filename *and* path). Basically, it needs something that's akin to
std.path.getName(), but actually works right.

I added stripExtension(), setExtension() and defaultExtension()
yesterday.  Haven't pushed anything to GitHub yet, though.

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

I agree.

Everything else about it looks great.

Thanks! :)

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

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

-Lars

Mar 02 2011
"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

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
junk files notwithstanding.)

I agree.  I changed this yesterday, and now it does the same on Windows
and POSIX.

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

Actually, in my experience, all of the strings defined at the top of
std.path are next to useless.  Most of the time I need to check "is this
character a dir separator?", and then I have to do

if (path[i] == sep[0] || path[i] == altsep[0]) ...

So I wrote an isDirSeparator() function that performs these tests, and
I've ended up using that almost exclusively.  The only place I expect to
be using the predefined strings is in the join() function.

- Still some casing inconsistencies: basename, dirname, drivename still
aren't camel-cased, but should be.

I know.  The naming scheme is by no means set in stone, I'm saving that
for last.

- It needs a function to remove the extension (while keeping the
filename *and* path). Basically, it needs something that's akin to
std.path.getName(), but actually works right.

I added stripExtension(), setExtension() and defaultExtension()
yesterday.  Haven't pushed anything to GitHub yet, though.

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

I agree.

Everything else about it looks great.

Thanks! :)

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

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

Hooray! That all sounds fantastic.

Mar 02 2011
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.

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

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

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

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

+++

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

Mar 01 2011
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.

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

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

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

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

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

Cheers,
- Daniel

Mar 01 2011
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.

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

version(Windows)

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

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

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

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

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

- Jonathan M Davis

Mar 01 2011
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.

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

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.

Andrei

Mar 01 2011
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.

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

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.

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

- Jonathan M Davis

Mar 01 2011
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.

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

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.
gz-compressed?"

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

In the *nix land most common extensions of this sort
are .tar.gz, .tar.bz2, .tgz, .ps.gz, .pds.gz, and .svgz. The files are
gzip or bzip2 packed single files, nothing more. Some tools only manage
to open them if the extension is correct and otherwise treat them as
black box archives. For example GNOME's pdf viewer refuses to open
document.gz, but renaming it to document.ps.gz makes it viewable,
assuming the file is a gzipped postscript document.

Mar 01 2011
retard <re tard.com.invalid> writes:
Tue, 01 Mar 2011 19:25:57 +0000, retard wrote:

.pds.gz,


Mar 01 2011
"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.

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

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

Mar 01 2011
"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.

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

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
"file.txt". It ain't a "foo" file at all, it just helps me know exactly what
the txt file is describing.

Mar 01 2011
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.

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

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

Mar 01 2011
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 14:10:58 +0100, Jens Mueller 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.

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

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

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

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

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

Now, the Apple II's ProDOS and such, *those* had separate notions of
filename and "extension" (not that it was called "extension" though).

Mar 01 2011
"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
"extension", and even then the extension is always just "everything after
the last dot in the filename". Anything beyond that is merely tradition
and
convention. The only real difference is that windows has no standard
mechanism for looking at the content of the file to help determine its
type.

Didn't the FAT16 filesystem require something in the name portion of the
8.3 filename?

Note, special care will need to be taken with the special directories '.'
and '..' to avoid some weird bugs.

-Steve

Mar 01 2011
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
"extension", and even then the extension is always just "everything after
the last dot in the filename". Anything beyond that is merely
convention. The only real difference is that windows has no standard
mechanism for looking at the content of the file to help determine its
type.

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

Didn't the FAT16 filesystem require something in the name portion of the
8.3 filename?

And the dot was not stored anywhere. Only 11 characters were stored.
This was still true in Windows 3.1, and I think it wasn't even
completely gone in Win95/98.

Mar 01 2011
"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
"extension", and even then the extension is always just "everything
after
the last dot in the filename". Anything beyond that is merely tradition
and
convention. The only real difference is that windows has no standard
mechanism for looking at the content of the file to help determine its
type.

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

The existence of an 8.3 fallback doesn't really have any bearing on it. And
neither does pedigree. If there is still a fundamental distinction with
extension, it's nothing more than a detail of how the filesystem spec
defines its data storage and completely abstracted away by the filesystem
driver.

Name one case in windows where some sort of distinction between filename and
extension actually makes a real tangible difference versus unix, that
doesn't merely amount to convention (there's zero technical hurdle in the
way of a windows program considering ".bashrc" to be extensionless) or
manually re-implementing part of the filesystem spec (heck, unix has FAT32
and NTFS drivers, too).

Mar 01 2011
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
"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.

Mar 03 2011
"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
"extension", and even then the extension is always just "everything
after
the last dot in the filename". Anything beyond that is merely
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.

Mar 03 2011
Kagamin <spam here.lot> writes:
Don Wrote:

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

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

Mar 03 2011
=?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

Mar 03 2011
"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.

Mar 03 2011
Jesse Phillips <jessekphillips+D gmail.com> writes:
Denis Koroskin Wrote:

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

Jerome

Double-click? Yes. Running from console? No.

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

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

Mar 03 2011
"Denis Koroskin" <2korden gmail.com> writes:
On Fri, 04 Mar 2011 00:10:28 +0300, Jesse Phillips
<jessekphillips+D gmail.com> wrote:

Denis Koroskin Wrote:

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

Jerome

Double-click? Yes. Running from console? No.

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

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

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

Mar 03 2011
Jesse Phillips <jessekphillips+D gmail.com> writes:
Denis Koroskin Wrote:

On Fri, 04 Mar 2011 00:10:28 +0300, Jesse Phillips
<jessekphillips+D gmail.com> wrote:

Denis Koroskin Wrote:
Double-click? Yes. Running from console? No.

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

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

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

Oh, I was confused on your original post.

Yes double-click fails, but the console works. Interestingly enough, gvim will
open if I change the extension to txt and am using powershell.

Mar 03 2011
"Nick Sabalausky" <a a.a> writes:
On Thu, 03 Mar 2011 21:47:54 +0300, Jérôme M. Berger <jeberger free.fr>
wrote:
Kagamin wrote:
Don Wrote:

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

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

I just tried that and it does work. Weird.

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

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

Try renaming a .exe into .js
and it will not run, whereas on Unix it would.

Works for me from the console.

Mar 03 2011
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


Mar 01 2011
"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.

Mar 01 2011
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...

Mar 01 2011
"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?

Mar 01 2011
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).

Mar 01 2011
"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).

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

Mar 01 2011
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

Mar 01 2011
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.

Mar 01 2011
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

Mar 01 2011
"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.

Mar 01 2011
=?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

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

-Lars

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

I see no reason why not.  Or at least, once 'inout' works.

Mar 01 2011
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.

Mar 02 2011
"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)";

Mar 02 2011
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.

Mar 03 2011
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.

Mar 03 2011
"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.

Mar 03 2011
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.

Mar 03 2011
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"

Mar 03 2011
"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.

Mar 03 2011
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?

Mar 04 2011
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

Mar 04 2011
Kagamin <spam here.lot> writes:
Jonathan M Davis Wrote:

On Friday 04 March 2011 00:08:25 Kagamin 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.

Mar 04 2011
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:
??????
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)

Mar 04 2011
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.

Mar 04 2011
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

Mar 04 2011
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.

Mar 04 2011
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:
??????
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

Mar 04 2011