Hey,
Just joined the list, and I too have been thinking about a good path literal
for Perl 6. Nice to see so many other people are thinking the same :).
Not knowing where to start in this long thread, I will instead try to show how
I would like a path literal to work. For me a path literal is a w
On Mon, Aug 17, 2009 at 23:11, Jon Lang wrote:
>> The default p{} should only allow "/" as separator and should not allow
>> characters that won't work on modern Windows and Unix like \ / ? % * : | " >
>> <,
>> etc. The reason for this is that portable Path's should be the default and if
>> you re
>> Perl 5 runs on (at least) VMS and VOS too. So, if Perl 6 is to adopt a policy
>> of enforced portable filenames by default, it should (at least) also exclude
>> - as the first character, and forbid more than one . in a filename.
>
> And, as I mentioned in an earlier post during the discussion, t
On Tue, Aug 18, 2009 at 13:10, Jan Ingvoldstad wrote:
> On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsen
> wrote:
>
>> My idea with portable by default was only portability for modern Unix and
>> modern Windows. So DOS and VMS limitations would not apply. The problem
On Tue, Aug 18, 2009 at 15:20, Carl Mäsak wrote:
> Leon (>):
>> Reading this discussion, I'm getting the feeling that filename
>> literals are increasingly getting magical, something that I don't
>> think is a good development. The only sane way to deal with filenames
>> is treating them as opaque
o a :
my $file = eval { decode("utf8", $file, Encode::FB_CROAK); };
every time i get a filename?
Regards Troels.
On Tue, Aug 18, 2009 at 16:37, Nicholas Clark wrote:
> On Tue, Aug 18, 2009 at 01:10:58PM +0200, Jan Ingvoldstad wrote:
>> On Tue, Aug 18, 2009 at 12:54
Very interesting read, that opens a whole new can of worms. How should we
behave when we actually read file names from the filesystem.
As for the path literal the newest revision of S32-setting-library should make
most people happy as the default is OS independent and abstract. More
strictness can
