Re: RFC 100 (v1) Embed full URI support into Perl

You're still showing non-portable examples. What is the win? And what does "file://z/docs/personal" become? Or for that matter "file://u/frankeh/Projects" become? (I happen to live at a mount point /u. You are squeezing a little too hard here. There are seperate problems to be solved, whether

Re: RFC 100 (v1) Embed full URI support into Perl

On Tue, 15 Aug 2000, Nathan Wiger wrote: > With URI support, you still have to contort a little, but not as much. > Here's some better examples from an email I sent earlier: > >$fo = open "file://c/docs/personal"; > ># Unix = /docs/personal# here, 'c' becomes '/' ># Mac = :docs

Re: RFC 100 (v1) Embed full URI support into Perl

Sam Tregar wrote: > > How is this better than File::Spec's approach? File::Spec has the idea and representation dead on. However, the interface is a pain; to write portable scripts you have to go through some contortions. With URI support, you still have to contort a little, but not as much. Her

Re: RFC 14 (v3) Modify open() to support FileObjects and

Nathan Wiger wrote: ># Replaced by 'open socket' >socket >setsockopt # socket->options >connect # overload <> or socket->connect >shutdown# close instead > close and shutdown are not exactly the same, especially when a fork has occurred and a child proces

Re: RFC 14 (v3) Modify open() to support FileObjects and

[EMAIL PROTECTED] (Nathan Wiger) wrote on 12.08.00 in <[EMAIL PROTECTED]>: > Here's a step-by-step process for supporting both that I propose. > Suggestions welcome: > > 1. If called as an indirect object function (in the form currently >proposed), steps 2-3 are skipped and the handler speci

Re: RFC 100 (v1) Embed full URI support into Perl

On 14 Aug 2000, Perl6 RFC Librarian wrote: >$fo = open "C:\Windows\System";# non-portable >$fo = open "file://C|/Windows/System"; # portable Can you explain how the second is portable to non-Windows systems? What does "C|" mean on my Linux box? >unlink "/local/etc/script.co

Re: RFC 14 (v3) Modify open() to support FileObjects and

On Sat, 12 Aug 2000, Nathan Wiger wrote: > > Pick one: > > > > 1) Filenames that end with a '/' are directories and those that don't > > are files. (Both examples are files.) > > No, too restrictive. I don't like this and would hate having to remember > it. > Plus the non-"/" separated fi

Re: Internal Filename Representations (was Re: Summary of I/O related

[EMAIL PROTECTED] (Jarkko Hietaniemi) wrote on 13.08.00 in <[EMAIL PROTECTED]>: > On Sun, Aug 13, 2000 at 02:14:24PM -0400, Chaim Frenkel wrote: > > Why do all those acts have to be performed to do an open? > > I must not be explaining myself very well... To do an open() from > Perl the user

Re: command line option: $|++

Peter Scott wrote: > > Can someone knowledgeable on this issue speak to it? > > Will $| $/ $\ et al be retired, or be valid for some default filehandle? > > Will there still be default filehandles? There's been a big debate on the -io list about this. No clear decisions yet, but looks like the

Re: RFC 14 (v3) Modify open() to support FileObjects and

On Mon, Aug 14, 2000 at 03:01:54PM -0700, Nathan Wiger wrote: > > or less verbose, > > > > $fh = open " > This is still up in the air. I think this will probably end up doing a > GET via the http handler on the webpage specified. That seems the most > natural,

Re: RFC 100 (v1) Embed full URI support into Perl

Chaim Frenkel wrote: > > > "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > > PRL>$fo = open "C:\Windows\System";# non-portable > PRL>$fo = open "file://C|/Windows/System"; # portable > > In what way is the second example portable? I don't think it will > do anythi