I'll just butt in here and say that while the URI format is nice for
alternate schemes, it is not nice for accessing files.
The general case in most programming languages is to assume that a
non-URI "file" name is local, specifying
file://wherever/whatever/filename is unnecessary additional syntax
On Fri, Aug 14, 2009 at 7:41 PM, David Green wrote:
> Well, we can encode a URI any way we like -- I was thinking of anything up
> to the next whitespace or semicolon, and internal semicolons, etc. being
> %-encoded.
Semicolons are reserved characters in URIs: inappropriately percentage
encoding
On Aug 14, 2009, at 16:17 , Mark J. Reed wrote:
On Fri, Aug 14, 2009 at 3:35 PM, Darren
Duncan wrote:
Under Mac OS X, all drives, root or otherwise, are accessible under
'/Volumes//...', and Unix in general lets you mount
drives
anywhere. I imagine Windows supports more ways of denoting driv
On Fri, Aug 14, 2009 at 3:35 PM, Darren Duncan wrote:
> Under Mac OS X, all drives, root or otherwise, are accessible under
> '/Volumes//...', and Unix in general lets you mount drives
> anywhere. I imagine Windows supports more ways of denoting drives than the
> drive letter.
Nope. Have to use
Richard Hainsworth wrote:
Would it be possible to remove the special purpose of \ from strings
within IO constructs?
This would mean '\' could be used in naming paths as an alternative to
'/', thus allowing windows and unix strings to be equivalent, eg.
IO(:path<<{$root-path}/data/new>>) would
On 2009-Aug-14, at 5:36 am, Richard Hainsworth wrote:
Would it be possible to remove the special purpose of \ from strings
within IO constructs?
It's P6, anything's possible! I probably wouldn't change [what look
like] ordinary quoted strings, but maybe something with a "qf//"-type
constr
On Fri, 14 Aug 2009, Timothy S. Nelson wrote:
On Thu, 13 Aug 2009, Hinrik Örn Sigurðsson wrote:
Imagine two roles, Filename and Dirname (or Path::File / Path::Dir). I
...or imagine just one, called IO::FSNode.
Sorry, I was stupiding again. I'll ask you to imagine 4:
IO::F
On Thu, 13 Aug 2009, Hinrik Örn Sigurðsson wrote:
Imagine two roles, Filename and Dirname (or Path::File / Path::Dir). I
...or imagine just one, called IO::FSNode.
http://perlcabal.org/syn/S32/IO.html#IO::FSNode
Btw, kudos for the special quoting idea -- I love it :).
On Fri, Aug 14, 2009 at 12:34 PM, David Green wrote:
> Of course, this being P6, we can have some kind of "io" macro that parses
> the single item after it:
>
> my $file1 = io file://some/dir/some%20file; # the
> quick way
I don't think that's a good idea. In general, parsin
I like this way.
Would it be possible to remove the special purpose of \ from strings
within IO constructs?
This would mean '\' could be used in naming paths as an alternative to
'/', thus allowing windows and unix strings to be equivalent, eg.
IO(:path<<{$root-path}/data/new>>) would be equi
On 2009-Aug-14, at 4:34 am, David Green wrote:
There's a lot of scope for a nice, friendly, high-level IO view;
perhaps we need an IO-working group to assemble knowledge about what
is and isn't possible with different filesystems and design an
interface around it all.
It won't be possible
On 2009-Aug-13, at 10:25 am, Hinrik Örn Sigurðsson wrote:
I've read a couple of posts about
file test operators, where some have suggested making filenames
special, either as a subtype of Str or something else entirely. That
way Str wouldn't have all these file test methods, which is good
because
More ideas:
On Thu, 13 Aug 2009, Hinrik Örn Sigurðsson wrote:
# bin/perl on Unix
my $rel = qf/usr bin perl/;
# /usr/bin/perl
my $abs = qf[/usr bin perl];
...and on Windows, would the above result in "C:\/usr\bin\perl" ? :)
# The following both result in the same object (
13 matches
Mail list logo
