Lots of good points.
Something that the Mac OS (even OS X) has which most Unix variants don't
are directory IDs and file IDs. The Carbon APIs use a FSSpec structure,
which is a volume ID, directory ID, and file name. (volume ID, file ID
is good enough to identify a file which exists already, bu
On Thu, 4 Sep 2003 [EMAIL PROTECTED] wrote:
> On Mon, 1 Sep 2003, Michael G Schwern wrote:
> > You also must worry about volumes.
[my long explanation snipped]
Sorry, wrong list; this is a standard-module issue, not an implementation
issue or even a core-language issue.
-Martin
Leopold Toetsch wrote:
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
[ snipped a lot of explanations ]
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 ad
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
[ snipped a lot of explanations ]
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 imple
On Mon, 1 Sep 2003, Michael G Schwern wrote:
> You also must worry about volumes.
> Unix: No user visible concept of a volume
> Windows: VOLUME:\dir1\dir2\file
> VMS: VOLUME:[dir1.dir2]file
This has been worrying me for some years. The concept of "volume" has
different implications for different p
Though I haven't been following this thread, it seems you're coming up
with some File::Spec-like thing for Parrot?
I'd recommend looking at Ken Williams' excellent Path::Class module
which gives you actual file and directory objects. EXTREMELY useful when
you're in an ultra-cross platform environ
> Though I haven't been following this thread, it seems you're coming up
> with some File::Spec-like thing for Parrot?
Exactly.
> I'd recommend looking at Ken Williams' excellent Path::Class module
Surely, I will.
> So yes, you must distinguish between concatenating directories and files.
>
>
Leo wrote:
> Albeit File::Spec is using catfile and catdir, I don't like the function
> names ("cat file" is on *nix what "type file" is on Win*). Maybe
> concat_pathname and concat_filename is better.
Yes, indeed. I'm for having concat_pathname only since this patch or
the File::Spec module makes
Leo wrote:
> Albeit File::Spec is using catfile and catdir, I don't like the function
> names ("cat file" is on *nix what "type file" is on Win*). Maybe
> concat_pathname and concat_filename is better.
Yes, indeed. I'm for having concat_pathname only since this patch or
the File::Spec module makes
Vladimir Lipskiy <[EMAIL PROTECTED]> wrote:
[ my first answer seems to be missing ]
> From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> Subject: TWEAKS: Takers Wanted - Effort And Knowledge Sought
>> Platform code
>> -
>>We need some functions to deal with paths and files like File::Spec
- Original Message -
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
Sent: Thursday, August 07, 2003 12:51 PM
Subject: TWEAKS: Takers Wanted - Effort And Knowledge Sought
> Platform code
> -
>We need some functions to deal with paths and files like File::Spec.
>For loading include
11 matches
Mail list logo