Walter Bright wrote:
> "bobef" <bobef@lessequal.com> wrote in message news:dt4vmb$62s$1@digitaldaemon.com...
> 
>>Just from curiosity, because I did the same thing today, what functions are you submitting to std.path?
> 
> 
> I received both of your emails about it. I guess we'll have to do a merge of the best of both!
> 
> Also, for submissions to std.path, I'll need an explicit release into the public domain, as I'm making std.path public domain. 
> 
> 

In that line: 3D math libs anyone??

http://www.webpages.uidaho.edu/~shro8822/point_math.d
http://www.webpages.uidaho.edu/~shro8822/point_lib.d

If the disclaimer need fixing, just tell me what to fix it to.
I have a runtime unit struct that I might put up soon also.

"bobef" <bobef@lessequal.com> wrote in message news:dt5cbv$hvo$1@digitaldaemon.com...
> I hate this shit. Here I place this source and allow everyone to do whatever he can imagine with it, but I will not be responsible for anything. In other words 'bobef license 1.0': use without restrictions at your own risk.

I understand completely and hate to be pedantic, but please add "I wrote this and place it into the Public Domain."

Walter Bright wrote:
> "bobef" <bobef@lessequal.com> wrote in message news:dt5cbv$hvo$1@digitaldaemon.com...
>> I hate this shit. Here I place this source and allow everyone to do whatever he can imagine with it, but I will not be responsible for anything. In other words 'bobef license 1.0': use without restrictions at your own risk.
> 
> I understand completely and hate to be pedantic, but please add "I wrote this and place it into the Public Domain."
> 
> 

Hope this do the trick...

Written and placed into the public domain by Borislav Peev (bobef).

bobef wrote:
> 	version(t_Linux)
> 	{
> 		(...)
> 		writefln("\ngetFullPath tests\n");
> 
> 		writefln(getFullPath("\\rabbit/..\\bird"));
> 		writefln(getFullPath("\\rabbit\\cat\\..\\bird"));
> 		writefln(getFullPath("\\rabbit\\..\\bird"));
> 		writefln(getFullPath("rabbit.d"));
> 		writefln(getFullPath("rabbit\\..\\.\\bird"));
> 		writefln(getFullPath(".\\rabbit\\..\\.\\bird\\..\\"));

It is not correct to remove '..' on Linux. '/a/../b' is not garanteed to be '/b', since '/a' could be a symbolic link to somewhere else on the filesystem.

-- 
Miles < http://www.ubr.inf.br/wiki/Usuário:Miles >

"Using Perl for CGI programming is like using Emacs for text editing."

Miles wrote:
> bobef wrote:
>> 	version(t_Linux)
>> 	{
>> 		(...)
>> 		writefln("\ngetFullPath tests\n");
>>
>> 		writefln(getFullPath("\\rabbit/..\\bird"));
>> 		writefln(getFullPath("\\rabbit\\cat\\..\\bird"));
>> 		writefln(getFullPath("\\rabbit\\..\\bird"));
>> 		writefln(getFullPath("rabbit.d"));
>> 		writefln(getFullPath("rabbit\\..\\.\\bird"));
>> 		writefln(getFullPath(".\\rabbit\\..\\.\\bird\\..\\"));
> 
> It is not correct to remove '..' on Linux. '/a/../b' is not garanteed to
> be '/b', since '/a' could be a symbolic link to somewhere else on the
> filesystem.
> 

Never thought of that.
And I think it is also not correct to replace \ with / in the Linux paths... I don't have enough Linux knowledge to solve these yet.

bobef wrote:
> Never thought of that.
> And I think it is also not correct to replace \ with / in the Linux
> paths... I don't have enough Linux knowledge to solve these yet.

Yes, it is not correct.

Every character except for '/' and '\0' is a valid character for Linux filenames. It is even possible to embed some ANSI escape sequences on filenames to make them shine on different colors on ls (this is stupid and useless, but possible).

On a side note, expandTilde() is a bit off as part of the D library... the meaning we give to '~' on Linux is just as a _shell feature_, and just a convention. Otherwise, '~' is also valid as part of a filename.

About Windows NT based systems:
First, most parts of Windows accepts '/' as valid separator in file names.
Also, the following paths are totally valid and accepted, and most of them will
confuse the posted code:

c:\\server\share\name - don't ask - it's a hack from Win3 era still living...
\??\c:\folder\file - seen in registry, it is used by native functions
\\?\c:\folder\filename - allows up to 37000 UNICODE characters in a name.
If the path is in this format it cannot be relative, cannot contain '.' nor
'..' nor '/'.
\??\UNC\Server\Share - same as above but for UNC filenames

The named streams syntax use ':', so 'filename:streamname"
must be interpreted as file with name 'filename' containing one unnamed stream
and one named stream called 'streamname'.
Current code will accept 'filename' as drive name if I read it correctly.
If I remember correctly, Ares have a code dealing with parts of file name but
I do not remeber whether it "knows" about named file streams - these will be
interesting test cases for that code <hint> <hint> ;-)
Regards,
Todor

P.S. The following names are also valid but they are variations of the
examples above:

\\?\Volume{d208a5aa-7554-11d9-a0af-806d6172696f}\boot.ini

is a "complete" file name in the sence it describes the full path to
the file and adding something like 'c:' will render it inusable.

And last, paths like \\.\PhysicalDrive2 are also valid.

Hope you enjoy the nice subtleness of everyone's favourite OS ;-)
Please note that everyone of the paths posted are accepted by notepad.exe
and the command interpreter cmd.exe on my machine with installed XP.
Todor


On Fri, 24 Feb 2006 18:09:58 +0200, Miles <_______@_______.____> wrote:

> bobef wrote:
>> Never thought of that.
>> And I think it is also not correct to replace \ with / in the Linux
>> paths... I don't have enough Linux knowledge to solve these yet.
>
> Yes, it is not correct.
>
> Every character except for '/' and '\0' is a valid character for Linux
> filenames. It is even possible to embed some ANSI escape sequences on
> filenames to make them shine on different colors on ls (this is stupid
> and useless, but possible).
>
> On a side note, expandTilde() is a bit off as part of the D library...
> the meaning we give to '~' on Linux is just as a _shell feature_, and
> just a convention. Otherwise, '~' is also valid as part of a filename.

In article <dtn34m$22sv$1@digitaldaemon.com>, Miles says...
>
>bobef wrote:
>> 	version(t_Linux)
>> 	{
>> 		(...)
>> 		writefln("\ngetFullPath tests\n");
>> 
>> 		writefln(getFullPath("\\rabbit/..\\bird"));
>> 		writefln(getFullPath("\\rabbit\\cat\\..\\bird"));
>> 		writefln(getFullPath("\\rabbit\\..\\bird"));
>> 		writefln(getFullPath("rabbit.d"));
>> 		writefln(getFullPath("rabbit\\..\\.\\bird"));
>> 		writefln(getFullPath(".\\rabbit\\..\\.\\bird\\..\\"));
>
>It is not correct to remove '..' on Linux. '/a/../b' is not garanteed to be '/b', since '/a' could be a symbolic link to somewhere else on the filesystem.
>
>-- 
>Miles < http://www.ubr.inf.br/wiki/Usuário:Miles >
>
>"Using Perl for CGI programming is like using Emacs for text editing."

Python does the same thing with it's normpath function. http://docs.python.org/lib/module-os.path.html

I know it's not optimal, but I suppose until we can get some functions written to handle symbolic path expansion, it could just be noted in the docs that a getFullPath type function at the moment, does not handle symbolic links.  Then at least the user is going in with both eyes open.

Good points though for future improvements.

-Kramer