Re: [RFT] File Spec
On Sat, Sep 13, 2003 at 09:55:48PM +0300, Vladimir Lipskiy wrote: To be clearer: concat_dirnames(b, /foo) == error. As long as concat_dirnames() will be taught to divine whether its arguments are absolute paths or relative paths, it could easily rotate its arguments so the above-mentioned call would become concat_dirnames(/foo, b). That would be really silly. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Quit looking, kids! It'll EAT YOUR MIND!! -- http://www.angryflower.com/fuck.gif
Re: [RFT] File Spec
On Sunday, September 14, 2003, at 12:50 , Michael G Schwern wrote: On Sat, Sep 13, 2003 at 09:55:48PM +0300, Vladimir Lipskiy wrote: To be clearer: concat_dirnames(b, /foo) == error. As long as concat_dirnames() will be taught to divine whether its arguments are absolute paths or relative paths, it could easily rotate its arguments so the above-mentioned call would become concat_dirnames(/foo, b). That would be really silly. I must agree. The only reasonable results of that are either (a) an error [] or (b) /foo. (I'd go with [b].) Gordon Henriksen [EMAIL PROTECTED]
Re: [RFT] File Spec
On Fri, Sep 12, 2003 at 10:29:04AM +0300, Vladimir Lipskiy wrote: People make mistakes. Perhaps you should produce some errors if a user strays outside these rules. Garbage in, garbage out: Bad. Garbage in, error out: Good. It really does that. I mean that it returns a when it suspects its arguments to be wrong. I'll admit to not knowing the general error philosophy of Parrot ops. It could throw an internal exception, but ... I am not convinced we should switch to that sort of indicating errors. Though what kind of errors it ought to provide is a subject to be arguing about. This does sound like something that should be covered by some sort of How should ops handle bad input design document. If there is such a beast, do what it recommends. If there isn't, there should be one. What if I feed you: concat_dirnames(VOL1:[dir.dir], VOL2:[dir.dir]) Well, I suppose that's simple, its an error since you can't usefully concatenate two absolute directories. Anyhow, the point is is an *error*. Yes, and since concat_dirnames() isn't supposed to concatenate anything but dirnames. Are you saying: concat_dirnames(C:\foo, bar) == error? But I was unclear. I meant the other way around. concat_dirnames(b, :my disk:a); Trying to concatenate an absolute directory onto a relative one should produce an error. What do you mean by absolute directory? /foo C:\foo [foo] VOL:[foo] \foo etc... Which isn't clear from the example I gave above since :mydisk:a is ambiguous on MacOS. To be clearer: concat_dirnames(b, /foo) == error. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Here's hoping you don't harbor a death wish!
Re: [RFT] File Spec
Are you saying: concat_dirnames(C:\foo, bar) == error? Yes. Even if the file spec tool was smart enough just like you and me it would never be able to unriddle what output it would have to produce as a result of the following call on Mac: concat_dirnames(disk:dir_a, dir_b); if disk was a disk, then the result should be disk:dir_a:dir_b if disk was a directory :disk:dir_a:dir_b Now let's have a look at this call on windows: concat_dirnames(c, dir_a\dir_b); Try to guess what I mean by c there? A directory or the disk C? I hope it's clear for you now why concat_dirnames() can't glue anything together but dirnames. File Spec is a lack of information on what disk and C are. That sort of information has to be provided by user. And the user really does that when he/she/it chooses an appropriate function -- concat_dirnames, concat_pathnames, prepend_volume and so forth. Which isn't clear from the example I gave above since :mydisk:a is ambiguous on MacOS. To be clearer: concat_dirnames(b, /foo) == error. As long as concat_dirnames() will be taught to divine whether its arguments are absolute paths or relative paths, it could easily rotate its arguments so the above-mentioned call would become concat_dirnames(/foo, b). At long last the name concat_ doesn't furnish a security in which order it will glue its arguments. For instance, if we had the append_dirname() function, then yes: append_dirname(b, /foo) that call is surely fallacious.
Re: [RFT] File Spec
Thursday, September 11, 2003 11:36 PM
Michael G Schwern [EMAIL PROTECTED] wrote:
On Thu, Sep 11, 2003 at 08:36:02PM +0300, Vladimir Lipskiy wrote:
Famous last words: Our data is perfect, we don't need to check our
inputs.
Yes. Our data is perfect and we don't need to check our inputs if we
play by rules. And the rules are:
Always use concat_dirnames to concatenate directory names
Always use append_filename to append a file name to a path
Always keep in mind that this tool gives you a proper result
when you give it proper input, which is simple directory
names, simple file names, and paths produced by this tool only.
If you observe the rules, you won't get into a mess.
People make mistakes. Perhaps you should produce some errors if a user
strays outside these rules. Garbage in, garbage out: Bad. Garbage in,
error out: Good.
It really does that. I mean that it returns a when it suspects its
arguments to be wrong.
I'll admit to not knowing the general error philosophy of Parrot ops.
It could throw an internal exception, but ... I am not convinced we should
switch to that sort of indicating errors. Though what kind of errors it
ought
to provide is a subject to be arguing about.
What if the volumes don't match?
Don't match against what? concat_dirnames doesn't do matching arguments
against anything but PARROT_FS_DIRNAME_START and PARROT_FS_DIRNAME_END,
which, for example, are '[' and ']' on VMS.
What if I feed you:
concat_dirnames(VOL1:[dir.dir], VOL2:[dir.dir])
Well, I suppose that's simple, its an error since you can't usefully
concatenate two absolute directories. Anyhow, the point is is an *error*.
Yes, and since concat_dirnames() isn't supposed to concatenate anything
but dirnames.
What if I'm adding a path with a volume to one without?
Still. You get what you do. On Mac:
concat_dirnames('my disk:a', ':b') = ':my disk:a:b'
Mac's a special case since, IIRC, :b can either mean The volume called b
or The file/directory in the current directory called b.
No. Volumes can't start with a :. The special case is that :b can mean
either the file b or the directory b in the current directory.
So Mac treats :my disk:a:b as Unix treats my disk/a/b.
But I was unclear. I meant the other way around.
concat_dirnames(b, :my disk:a);
Trying to concatenate an absolute directory onto a relative one should
produce an error.
What do you mean by absolute directory?
File::Spec has an individual function for such purposes, catpath().
We can't process more than two in-arguments in PASM, so we would take
advantage of prepend_volume and things of such sort.
Unless I'm missing something, since the volumes and root dirs are already
attached to the filepath string, you don't need more than two arguments.
And one doesn't need to concatenate such absolute paths unless he/she/it is
a psycho. Moreover you just said yourself above that there was no use while
conacatenating absolute paths and I agreed with you. Anyway I was speaking
of
Perl5 File::Spec function catdir() which actually takes three arguments:
a volume, directory, and file.
It has to be admitted, my patch ...
/everyone rises in applause
(___(\_
(___(
(___( _
(___(__ /
| |
|_|
(~: BOO-O-O!
May I go on? Good! ... STILL needs some reworking (sniff-sniff) to effectively
resist naughty users. So I'll take a pause and lay out a new draft of the tool
in the immediate future. And if the draft pleases everybody I'll go implement
it.
Re: [RFT] File Spec
Michael G Schwern [EMAIL PROTECTED] wrote: People make mistakes. Perhaps you should produce some errors if a user strays outside these rules. Garbage in, garbage out: Bad. Garbage in, error out: Good. Albeit I did write, we need a simple interface to get at runtime libs and includes, I did not think of GIGO. I have to second Michael here. Some parts of that stuff might come from user preferences and environment variables like PARROT_LIB_PATH. We can't trust that contents. I'm for a strict error checking here. A composed path/file might get it to a system() call, having gargabe like foo;rm -rf / inside is suboptimal. I'll admit to not knowing the general error philosophy of Parrot ops. The standard (current) behavior doesn't catch too many errors, but we will have some Safe.pm like execution environment - later. leo
[RFT] File Spec
Here is a new variant of File Spec for the Parrot internals. I've changed implementation. Made some alternations concerning with function names. catdir and catfile have become concat_dirnames and append_filename respectively. Now it will work properly on Windows, UNIX, VMS, Mac, cygwin, and OS/2(?), I believe. If you doesn't find your OS on the above-mentioned list, let me know. Below I'm laying out the semantics of curdir, concat_dirnames, and append_filename which File Spec is being consistent with. It would be great if you examined that on whether those functions do the Right Thing relative to your OS. Also at the moment the patch works fine for MSVC, though I'd like to know what the other compilers think about it. UNIX, cygwin, OS/2 curdir() = . concat_dirnames(, ) = concat_dirnames(null, ) = concat_dirnames(, null) = concat_dirnames(null, null) = concat_dirnames(., ) = . concat_dirnames(, .) = . concat_dirnames(., .) = . concat_dirnames(a, ) = a concat_dirnames(, b) = b concat_dirnames(a, .) = a concat_dirnames(., b) = b concat_dirnames(a, b) = a/b concat_dirnames(a/b, c) = a/b/c append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename(., ) = append_filename(a, ) = append_filename(a, b) = a/b MS Win32 == curdir() = . concat_dirnames(, ) = concat_dirnames(null, ) = concat_dirnames(, null) = concat_dirnames(null, null) = concat_dirnames(., ) = . concat_dirnames(, .) = . concat_dirnames(., .) = . concat_dirnames(a, ) = a concat_dirnames(, b) = b concat_dirnames(a, .) = a concat_dirnames(., b) = b concat_dirnames(a, b) = a\b concat_dirnames(a\b, c) = a\b\c append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename(., ) = append_filename(a, ) = append_filename(a, b) = a\b VMS = curdir() = [] concat_dirnames(, ) = concat_dirnames(null, ) = concat_dirnames(, null) = concat_dirnames(null, null) = concat_dirnames([], ) = [] concat_dirnames(, []) = [] concat_dirnames([], []) = [] concat_dirnames(a, ) = [a] concat_dirnames(, b) = [b] concat_dirnames(a, []) = [a] concat_dirnames([], b) = [b] concat_dirnames(a, b) = [a.b] concat_dirnames([a.b], c) = [a.b.c] append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename([], ) = append_filename([a], ) = append_filename([a], b) = [a]b Mac = curdir() = : concat_dirnames(, ) = concat_dirnames(null, ) = concat_dirnames(, null) = concat_dirnames(null, null) = concat_dirnames(:, ) = : concat_dirnames(, :) = : concat_dirnames(:, :) = : concat_dirnames(a, ) = :a concat_dirnames(, b) = :b concat_dirnames(a, :) = :a concat_dirnames(:, b) = :b concat_dirnames(a, b) = :a:b concat_dirnames(:a:b, :c) = :a:b:c append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename(:, ) = append_filename(:a, ) = append_filename(:a, b) = :a:b file_spec.diff Description: Binary data
Re: [RFT] File Spec
On Thu, Sep 11, 2003 at 10:23:27AM +0300, Vladimir Lipskiy wrote: Unix et al == append_filename(., ) = Shouldn't that be .? append_filename(a, ) = a append_filename(a, b) = a/b What about append_filename(, b) ? Would that be an error? Don't forget absolute paths concat_dirnames(/foo, /bar) = error? concat_dirnames(foo, /bar) = error? concat_dirnames(/foo, bar) = /foo/bar MS Win32 == append_filename(., ) = . append_filename(a, ) = a? What about volumes? concat_dirnames(C:\foo, bar) = C:\foo\bar concat_dirnames(C:\foo, C:\bar) = error? concat_dirnames(foo, C:\bar) = error? VMS = append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename([], ) = Ditto. append_filename([a], ) = [a] Same caveats about volumes. Mac = Is Parrot really targetting MacOS Classic? PS I'd forward this bit to [EMAIL PROTECTED] concat_dirnames(, ) = concat_dirnames(null, ) = concat_dirnames(, null) = concat_dirnames(null, null) = concat_dirnames(:, ) = : concat_dirnames(, :) = : concat_dirnames(:, :) = : concat_dirnames(a, ) = :a concat_dirnames(, b) = :b concat_dirnames(a, :) = :a concat_dirnames(:, b) = :b concat_dirnames(a, b) = :a:b concat_dirnames(:a:b, :c) = :a:b:c append_filename(, ) = append_filename(null, ) = append_filename(, null) = append_filename(null, null) = append_filename(:, ) = append_filename(:a, ) = append_filename(:a, b) = :a:b -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ I do have a cause though. It is obscenity. I'm for it. -- Tom Lehrer Smut
Re: [RFT] File Spec
On Thu, Sep 11, 2003 at 01:17:29PM +0300, Vladimir Lipskiy wrote: Shouldn't that be .? append_filename(a, ) = a Umm. Don't think so. At least it will be that way until you convince me that it must be another way concat_dirnames(a, ) = a concat_dirnames(, b)= b ergo append_filename(a, ) = a Why wouldn't appending no filename onto a directory result in the directory being returned? Unless append_filename() guarantees that it will always return a filepath ending in a filename? What about append_filename(, b) ? Would that be an error? No. It's okay. I just forgot to mention that case. append_filename(, b) will produce b Now wait a second. append_filename(a, ) produces nothing but append_filename(, b) produces a filename? Isn't that a little inconsistent? concat_dirnames(/foo, /bar) = error? concat_dirnames(foo, /bar) = error? concat_dirnames(/foo, bar) = /foo/bar I just want to remind you the Leo's words: Please keep in mind, that the intended usage inside Parrot just should be to locate some standard include or extension files for Parrot internals. More abstraction and complexity can always be added above that or implemented by HLLs. -- Him.(~:) I don't suppose Leo will be pass in spoiled data. Famous last words: Our data is perfect, we don't need to check our inputs. What about volumes? I plan a special functions for volumes, and nodes, and root dirs like prepend_volume, prepend_node, prepend_rootdir. For example, prepend_rootdir could throw the prepend_rootdir is unsupported on this platform exception on windows. Of course, I will go implement those if Parrot needs those. Ok, but what happens when I pass filepaths with volumes attached to concat_dirnames? What if the volumes don't match? What if I'm adding a path with a volume to one without? -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Death? Its like being on holiday with a group of Germans.
Re: [RFT] File Spec
Michael G Schwern [EMAIL PROTECTED] wrote:
Why wouldn't appending no filename onto a directory result in the
directory
being returned? Unless append_filename() guarantees that it will always
return a filepath ending in a filename?
Yes. And it guarantees to return a , when you do something that
it treats as wrong in it's point of view.
append_filename(, b) will produce b
Now wait a second. append_filename(a, ) produces nothing but
append_filename(, b) produces a filename? Isn't that a little
inconsistent?
No, it isn't. In the first case it returns being standing for to
indicate an error situation. In the second case,
append_filename(, b) will give you :b on Mac.
It does sense, when you want to get a relative filepath which is
a route to the file b in the current directory.
Famous last words: Our data is perfect, we don't need to check our
inputs.
Yes. Our data is perfect and we don't need to check our inputs if we
play by rules. And the rules are:
Always use concat_dirnames to concatenate directory names
Always use append_filename to append a file name to a path
Always keep in mind that this tool gives you a proper result
when you give it proper input, which is simple directory
names, simple file names, and paths produced by this tool only.
If you observe the rules, you won't get into a mess.
Ok, but what happens when I pass filepaths with volumes attached to
concat_dirnames?
You get what you do, nonsense. Even File::Spec, a tool of a lot more
higher level, doesn't protect you from such things.
D:\perl -MFile::Spec::Functions -e print catdir('C:\hh','C:\dd'), qq(\n)
C:\hh\C:\dd
What if the volumes don't match?
Don't match against what? concat_dirnames doesn't do matching arguments
against anything but PARROT_FS_DIRNAME_START and PARROT_FS_DIRNAME_END,
which, for example, are '[' and ']' on VMS.
What if I'm adding a path with a volume to one without?
Still. You get what you do. On Mac:
concat_dirnames('my disk:a', ':b') = ':my disk:a:b'
File::Spec has an individual function for such purposes, catpath().
We can't process more than two in-arguments in PASM, so we would take
advantage of prepend_volume and things of such sort.
Re: [RFT] File Spec
On Thursday, September 11, 2003, at 10:36 AM, Vladimir Lipskiy wrote: If you observe the rules, you won't get into a mess. I'm not convinced If you don't have users, you won't get into a mess is a workable design goal for library code. -- c
Re: [RFT] File Spec
On Thu, Sep 11, 2003 at 08:36:02PM +0300, Vladimir Lipskiy wrote:
Famous last words: Our data is perfect, we don't need to check our
inputs.
Yes. Our data is perfect and we don't need to check our inputs if we
play by rules. And the rules are:
Always use concat_dirnames to concatenate directory names
Always use append_filename to append a file name to a path
Always keep in mind that this tool gives you a proper result
when you give it proper input, which is simple directory
names, simple file names, and paths produced by this tool only.
If you observe the rules, you won't get into a mess.
People make mistakes. Perhaps you should produce some errors if a user
strays outside these rules. Garbage in, garbage out: Bad. Garbage in,
error out: Good.
I'll admit to not knowing the general error philosophy of Parrot ops.
Ok, but what happens when I pass filepaths with volumes attached to
concat_dirnames?
You get what you do, nonsense. Even File::Spec, a tool of a lot more
higher level, doesn't protect you from such things.
D:\perl -MFile::Spec::Functions -e print catdir('C:\hh','C:\dd'), qq(\n)
C:\hh\C:\dd
Justifying your own tool's bad behavior using another tool's bad behavior
is not a terribly compelling design argument. Just because File::Spec's
handling of volumes is historicly lousy doesn't mean yours has to be.
What if the volumes don't match?
Don't match against what? concat_dirnames doesn't do matching arguments
against anything but PARROT_FS_DIRNAME_START and PARROT_FS_DIRNAME_END,
which, for example, are '[' and ']' on VMS.
What if I feed you:
concat_dirnames(VOL1:[dir.dir], VOL2:[dir.dir])
Well, I suppose that's simple, its an error since you can't usefully
concatenate two absolute directories. Anyhow, the point is is an *error*.
What if I'm adding a path with a volume to one without?
Still. You get what you do. On Mac:
concat_dirnames('my disk:a', ':b') = ':my disk:a:b'
Mac's a special case since, IIRC, :b can either mean The volume called b
or The file/directory in the current directory called b. On VMS or
Windows no such ambiguity exists.
But I was unclear. I meant the other way around.
concat_dirnames(b, :my disk:a);
Trying to concatenate an absolute directory onto a relative one should
produce an error.
File::Spec has an individual function for such purposes, catpath().
We can't process more than two in-arguments in PASM, so we would take
advantage of prepend_volume and things of such sort.
Unless I'm missing something, since the volumes and root dirs are already
attached to the filepath string, you don't need more than two arguments.
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
It's Ecstacy time!
