Front page | perl.perl5.porters |
Postings from November 2000
Re: PerlIO - what next ?
Thread Previous
|
Thread Next
From:
Gurusamy Sarathy
Date:
November 8, 2000 09:01
Subject:
Re: PerlIO - what next ?
Message ID:
200011081700.eA8H0fZ06450@smtp3.ActiveState.com
On Wed, 08 Nov 2000 15:13:56 GMT, Nick Ing-Simmons wrote:
>>perldoc open?
>
>Oh the handy pragma - what do you know ...
>
>What level of discussion has this had ? - Can I suggest it needs
>a little more ...
IIRC, the idea was Larry's and is described in Camel v3. I've
attached whatever discussion I had with him and Tom about it (hope
they don't mind). It would be nice to see more discussion on it here,
but better make sure we don't invalidate what the Camel says about
it.
>_My_ first question is what are all the ':' for ? and seconds
>is do we really want strings?
The intent (presumably) is to make the quoting unnecessary where that
is useful, a la lexical attributes (C<my Dog $spot :fierce>).
> use open IN => ":crlf", OUT => ":raw";
>
>What about INOUT handles ?
Same as setting both IN and OUT? (The open pragma isn't so much about
handles as it is about setting the default disciplines for input and
output.)
>Why IN rather than '<' as the "key" ?
Because that's what Larry suggested, and I happened to like it
better than anything else.
>What is syntax for more-than one:
>
>A. use open IN => ':uft8', ':crlf';
>
>B. use open IN => ':uft8 :crlf';
>
>C. use open IN => ':uft8 :crlf';
>
>D. use open IN => [':uft8',':crlf'];
The open pragma currently allows the simplistic
use open IN => ":utf8 :crlf"
If we make the attribute syntax work here, perhaps we can allow other
styles.
>=item binmode FILEHANDLE, DISCIPLINE
>
>That allows me to "add" one - how do I take one off ?
Precede the discipline we want to remove with a "-", perhaps?
Don't know, sounds like there may be better ways.
>Why
>
> open FH, "<:para :DEFAULT", $file or die "can't open $file: $!";
> open FH, "<:utf8 :crlf", $file or die "can't open $file: $!";
>
>and not
>
> open FH, '<', $file, 'para', @open::DEFAULT or die
> open FH, '<', $file, 'utf8', 'crlf' or die
That doesn't scale to n-arg open:
open FH, "-|", 'some', 'command', 'with', 'args'
>Its a list operator - give it a list ...
Since it is an attribute of the handle, this might be more consistent:
open FH :para :crlf, '<', $file or die;
open FH :para :mac, '<', qw(full path to file) or die; # portable filespec
HTH,
Sarathy
gsar@ActiveState.com
>>> todo:11363
Replied: Thu, 24 Feb 2000 13:43:09 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: tchrist@perl.com
Delivery-Date: Thu Feb 24 13:01:21 2000
Message-Id: <200002242057.MAA05683@kiev.wall.org>
Date: Thu, 24 Feb 2000 12:57:55 PST
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: tchrist@perl.com, larry@wall.org
Subject: binmode without binmode?
While you're here, what will be the filemode for open to indicate
binmode without having to say binmode?
Larry
>>> todo:11365
Delivery-Date: Thu Feb 24 13:11:27 2000
Message-Id: <28784.951426475@chthon>
Date: Thu, 24 Feb 2000 14:07:55 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
>While you're here, what will be the filemode for open to indicate
>binmode without having to say binmode?
This is in perlopentut:
sysopen(BINDAT, "records.data", O_RDWR | O_BINARY)
However, it didn't find its way into 920's sysopen example list,
and probably should.
This doesn't address the problem of backticks/qx/readpipe not
providing control over binmodalities. I seem to recall it's also
an issue with simple pipe open. Since winders groks open |- and
-| now, this should be workaroundable -- right? Still, that helps
the VMS, MVS, and old Mac folk not at all, who still can't do that
niftiness.
I believe that python has fopen(path, "rb") and popen(path, "rb"), etc.
--tom
>>> todo:11367
Replied: Thu, 24 Feb 2000 13:48:27 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: tchrist@chthon.perl.com (Tom Christiansen)
Delivery-Date: Thu Feb 24 13:18:34 2000
Message-Id: <200002242114.NAA05914@kiev.wall.org>
Date: Thu, 24 Feb 2000 13:14:43 PST
From: Larry Wall <larry@wall.org>
To: tchrist@chthon.perl.com (Tom Christiansen)
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
Tom Christiansen writes:
: >While you're here, what will be the filemode for open to indicate
: >binmode without having to say binmode?
:
: This is in perlopentut:
:
: sysopen(BINDAT, "records.data", O_RDWR | O_BINARY)
:
: However, it didn't find its way into 920's sysopen example list,
: and probably should.
:
: This doesn't address the problem of backticks/qx/readpipe not
: providing control over binmodalities. I seem to recall it's also
: an issue with simple pipe open. Since winders groks open |- and
: -| now, this should be workaroundable -- right? Still, that helps
: the VMS, MVS, and old Mac folk not at all, who still can't do that
: niftiness.
:
: I believe that python has fopen(path, "rb") and popen(path, "rb"), etc.
I guess I'm asking whether we're going to have a binary pseudo-discipline,
which is essentially a no-op.
Larry
>>> todo:11368
Replied: Thu, 24 Feb 2000 13:55:31 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Tom Christiansen <tchrist@chthon.perl.com>
Replied: Larry Wall <larry@wall.org>
Delivery-Date: Thu Feb 24 13:27:05 2000
Message-Id: <29545.951427424@chthon>
Date: Thu, 24 Feb 2000 14:23:44 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
>: This is in perlopentut:
>:
>: sysopen(BINDAT, "records.data", O_RDWR | O_BINARY)
>:
>: However, it didn't find its way into 920's sysopen example list,
>: and probably should.
>I guess I'm asking whether we're going to have a binary pseudo-discipline,
>which is essentially a no-op.
Oh. Sorry. (But I still suggest adding that example. The problem
is that it raises and exception on normal systems without O_BINARY
defined. I'm not sure a good way to trick it into no-op-dom.
Maybe making it 0 on them.)
Unless disciplines are established on the open, there may be a
problem. Sarathy, isn't it the case that you really have to do
this right away in some situations? That doesn't seem to make
sense, since binmode is post-facto, but there's osmething in my
memory about that. Maybe it's the "use binmodal ARGV' thing.
Eep, I see that IO::Handle::_open_mode_string doesn't know about
"b" (from fopen). It probably should, and then call sysopen not
open.
--tom
>>> todo:11369
Replied: Thu, 24 Feb 2000 13:57:06 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: larry@kiev.wall.org (Larry Wall)
Replied: tchrist@chthon.perl.com (Tom Christiansen)
Delivery-Date: Thu Feb 24 13:28:13 2000
Message-Id: <200002242122.NAA06043@kiev.wall.org>
Date: Thu, 24 Feb 2000 13:22:39 PST
From: Larry Wall <larry@wall.org>
To: larry@kiev.wall.org (Larry Wall)
cc: tchrist@chthon.perl.com (Tom Christiansen), Larry Wall <larry@wall.org
***>,
gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
Larry Wall writes:
: I guess I'm asking whether we're going to have a binary pseudo-discipline,
: which is essentially a no-op.
More specifically, I'm asking what the syntax will be. I saw Sarathy
using a <!foo!bar notation, which I can see the resemblence to pipes of (or
however you say that), but I think that'll be more confusing than
good. I'd suggest using a <:foo:bar notation instead.
In that case, is binmode which?
open FILE, "<:bin", $file
open FILE, "<:binary", $file
open FILE, "<:binmode", $file
Larry
>>> todo:11370
Replied: Thu, 24 Feb 2000 14:00:20 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Tom Christiansen <tchrist@chthon.perl.com>
Replied: Larry Wall <larry@wall.org>
Replied: larry@kiev.wall.org (Larry Wall)
Delivery-Date: Thu Feb 24 13:34:38 2000
Message-Id: <17120.951427872@chthon>
Date: Thu, 24 Feb 2000 14:31:12 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: larry@kiev.wall.org (Larry Wall), gsar@ActiveState.com (Gurusamy Sarat
***hy)
Subject: Re: binmode without binmode?
>In that case, is binmode which?
> open FILE, "<:bin", $file
> open FILE, "<:binary", $file
> open FILE, "<:binmode", $file
How does one change the disciple later on? My /bin/sh nature
learns to some exec fd thingie. Would this work?
open FILE, "<:binary", $file or die;
# stuff goes here
open FILE, "<:text", "&=" . fileno(FILE) or die;
Gosh, no, because, you can't do that with the thrinary open.
Maybe
open FILE, "<:text,fdopen", FILE or die;
I still don't know how this binary/text oppositional thing plays
out in the world of unicode. I bet it doesn't.
--tom
>>> todo:11371
Replied: Thu, 24 Feb 2000 14:10:08 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: tchrist@chthon.perl.com (Tom Christiansen)
Replied: larry@kiev.wall.org (Larry Wall)
Delivery-Date: Thu Feb 24 13:42:04 2000
Message-Id: <200002242138.NAA06245@kiev.wall.org>
Date: Thu, 24 Feb 2000 13:38:50 PST
From: Larry Wall <larry@wall.org>
To: tchrist@chthon.perl.com (Tom Christiansen)
cc: Larry Wall <larry@wall.org>, larry@kiev.wall.org (Larry Wall),
gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
Tom Christiansen writes:
: >In that case, is binmode which?
:
: > open FILE, "<:bin", $file
: > open FILE, "<:binary", $file
: > open FILE, "<:binmode", $file
:
: How does one change the disciple later on?
Depends. If you haven't done any I/O, presumably
binmode FILE, "<:text";
Later, you have to re-open because buffers will be loaded. Some
disciplines may be able to switch to more specific disciplines for
efficiency if they're careful and either "nibble" the input to not
have buffering problems, or figure out how to transfer unused buffers among
disciplines. If we figure that out, we might be able to relax the
restriction more generally.
: My /bin/sh nature learns to some exec fd thingie. Would this work?
:
: open FILE, "<:binary", $file or die;
: # stuff goes here
: open FILE, "<:text", "&=" . fileno(FILE) or die;
:
: Gosh, no, because, you can't do that with the thrinary open.
: Maybe
:
: open FILE, "<:text,fdopen", FILE or die;
I expect we might possibly make :text work with 2-arg:
open FILE, "<:text&=" . fileno(FILE) or die;
Would have to be careful about people opening files starting with ":" though.
: I still don't know how this binary/text oppositional thing plays
: out in the world of unicode. I bet it doesn't.
You'd win that bet. Look at the most recent binmode entry, where it
talks about disciplines but doesn't give a syntax (yet). I'd like to.
Larry
>>> todo:11372
Delivery-Date: Thu Feb 24 13:43:11 2000
Message-Id: <200002242143.NAA21934@maul.activestate.com>
Date: Thu, 24 Feb 2000 13:43:09 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy), tchrist@perl.com
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 12:57:55 PST, Larry Wall wrote:
>
>While you're here, what will be the filemode for open to indicate
>binmode without having to say binmode?
:raw, maybe?
Sarathy
gsar@ActiveState.com
>>> todo:11373
Delivery-Date: Thu Feb 24 13:43:13 2000
Message-Id: <200002242139.NAA06260@kiev.wall.org>
Date: Thu, 24 Feb 2000 13:39:46 PST
From: Larry Wall <larry@wall.org>
To: tchrist@chthon.perl.com (Tom Christiansen)
cc: Larry Wall <larry@wall.org>, larry@kiev.wall.org (Larry Wall),
gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
Tom Christiansen writes:
: open FILE, "<:text,fdopen", FILE or die;
And it'd be :text:fdopen I suspect.
Larry
>>> todo:11374
Delivery-Date: Thu Feb 24 13:48:29 2000
Message-Id: <200002242148.NAA21963@maul.activestate.com>
Date: Thu, 24 Feb 2000 13:48:27 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: tchrist@chthon.perl.com (Tom Christiansen),
gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 13:14:43 PST, Larry Wall wrote:
>Tom Christiansen writes:
>: >While you're here, what will be the filemode for open to indicate
>: >binmode without having to say binmode?
>:
>: This is in perlopentut:
>:
>: sysopen(BINDAT, "records.data", O_RDWR | O_BINARY)
>:
>: However, it didn't find its way into 920's sysopen example list,
>: and probably should.
>:
>: This doesn't address the problem of backticks/qx/readpipe not
>: providing control over binmodalities. I seem to recall it's also
>: an issue with simple pipe open. Since winders groks open |- and
>: -| now, this should be workaroundable -- right? Still, that helps
>: the VMS, MVS, and old Mac folk not at all, who still can't do that
>: niftiness.
>:
>: I believe that python has fopen(path, "rb") and popen(path, "rb"), etc.
>
>I guess I'm asking whether we're going to have a binary pseudo-discipline,
>which is essentially a no-op.
That's essentially what I have in mind, yes. I scribbled down some
candidates for the builtin disciplines the other day:
- write crlf, locale, utf16, paragraph mode disciplines
+ raw discipline (default on Unix)
- input: no change
- output: no change
+ crlf discipline (default on Windows?)
- input: remove s/\r\n/\n/g
- output: add s/(?<!\r)\n/\r\n/g
+ paragraph discipline
- input: remove s/[ \t\r]*$//mg
- output: no change (?)
+ locale/oem discipline
- input: assume data is system default charset, convert to SvUTF8
- output: data is SvUTF8, convert to system default charset
data is !SvUTF8, write it is
+ utf16 discipline
- input: file is utf16 text, convert to SvUTF8 data
- output: if data is SvUTF8, convert to utf16 text
if data is !SvUTF8, convert locale/oem CP to utf16
+ utf16rev discipline
- same as utf16 except for endianness of output/input
Sarathy
gsar@ActiveState.com
>>> todo:11375
Replied: Thu, 24 Feb 2000 14:10:35 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: tchrist@perl.com
Delivery-Date: Thu Feb 24 13:48:47 2000
Message-Id: <200002242145.NAA06337@kiev.wall.org>
Date: Thu, 24 Feb 2000 13:45:32 PST
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@perl.com
Subject: Re: binmode without binmode?
Gurusamy Sarathy writes:
: On Thu, 24 Feb 2000 12:57:55 PST, Larry Wall wrote:
: >
: >While you're here, what will be the filemode for open to indicate
: >binmode without having to say binmode?
:
: :raw, maybe?
No maybe about it. That's a winner. :-)
binmode FILE;
is now offically equivalent to
binmode FILE ":raw";
Larry
>>> todo:11376
Delivery-Date: Thu Feb 24 13:55:32 2000
Message-Id: <200002242155.NAA21992@maul.activestate.com>
Date: Thu, 24 Feb 2000 13:55:30 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Tom Christiansen <tchrist@chthon.perl.com>
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 14:23:44 MST, Tom Christiansen wrote:
>>: This is in perlopentut:
>>:
>>: sysopen(BINDAT, "records.data", O_RDWR | O_BINARY)
>>:
>>: However, it didn't find its way into 920's sysopen example list,
>>: and probably should.
>
>>I guess I'm asking whether we're going to have a binary pseudo-discipline,
>>which is essentially a no-op.
>
>Oh. Sorry. (But I still suggest adding that example. The problem
>is that it raises and exception on normal systems without O_BINARY
>defined. I'm not sure a good way to trick it into no-op-dom.
>Maybe making it 0 on them.)
I doubt we'll make sysopen() with all its weirdly named flags the
canonical way to open things. :-)
>Unless disciplines are established on the open, there may be a
>problem. Sarathy, isn't it the case that you really have to do
>this right away in some situations? That doesn't seem to make
>sense, since binmode is post-facto, but there's osmething in my
>memory about that. Maybe it's the "use binmodal ARGV' thing.
binmode() doesn't even work when you open the file for append mode
and it contains a ^Z in the middle. So, yes, binmode() post-facto
doesn't work in all situations. What we need is a way to specify
flags to the constructor, and open() is the constructor here.
I put open(F, "<!crlf!utf16", $file) in Todo-5.6 but I have since
been thinking it may be nicer looking as "< :crlf :utf16" etc.
I did think also of:
open my $f :crlf :utf16, "< $file" or die;
but I think that's a non-starter because it doesn't work with
bareword filehandles.
>Eep, I see that IO::Handle::_open_mode_string doesn't know about
>"b" (from fopen). It probably should, and then call sysopen not
>open.
Sure looks like it.
Sarathy
gsar@ActiveState.com
>>> todo:11377
Delivery-Date: Thu Feb 24 13:57:07 2000
Message-Id: <200002242157.NAA22007@maul.activestate.com>
Date: Thu, 24 Feb 2000 13:57:05 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: larry@kiev.wall.org (Larry Wall),
tchrist@chthon.perl.com (Tom Christiansen),
gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 13:22:39 PST, Larry Wall wrote:
>Larry Wall writes:
>: I guess I'm asking whether we're going to have a binary pseudo-discipline,
>: which is essentially a no-op.
>
>More specifically, I'm asking what the syntax will be. I saw Sarathy
>using a <!foo!bar notation, which I can see the resemblence to pipes of (or
>however you say that), but I think that'll be more confusing than
>good. I'd suggest using a <:foo:bar notation instead.
Hey, that's exactly what I've (re)thinking too.
>In that case, is binmode which?
>
> open FILE, "<:bin", $file
> open FILE, "<:binary", $file
> open FILE, "<:binmode", $file
open FILE, ":raw", $file
was my preference, but :binary is probably more descriptive.
Sarathy
gsar@ActiveState.com
>>> todo:11378
Replied: Thu, 24 Feb 2000 14:15:56 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: tchrist@chthon.perl.com (Tom Christiansen)
Delivery-Date: Thu Feb 24 13:58:12 2000
Message-Id: <200002242154.NAA06456@kiev.wall.org>
Date: Thu, 24 Feb 2000 13:54:32 PST
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: Larry Wall <larry@wall.org>, tchrist@chthon.perl.com (Tom Christiansen
***),
gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
Gurusamy Sarathy writes:
: - write crlf, locale, utf16, paragraph mode disciplines
:
: + raw discipline (default on Unix)
: - input: no change
: - output: no change
:
: + crlf discipline (default on Windows?)
: - input: remove s/\r\n/\n/g
: - output: add s/(?<!\r)\n/\r\n/g
:
: + paragraph discipline
: - input: remove s/[ \t\r]*$//mg
: - output: no change (?)
:
: + locale/oem discipline
: - input: assume data is system default charset, convert to SvUTF8
: - output: data is SvUTF8, convert to system default charset
: data is !SvUTF8, write it is
:
: + utf16 discipline
: - input: file is utf16 text, convert to SvUTF8 data
: - output: if data is SvUTF8, convert to utf16 text
: if data is !SvUTF8, convert locale/oem CP to utf16
:
: + utf16rev discipline
: - same as utf16 except for endianness of output/input
I think we want the default :text input discipline (and maybe the real
default default) to be capable of nibbling the file to determine which
of those disciplines above to mutate into for efficiency. If we can
make opening random text files a no-brainer and still way fast,
everyone will love us. Of course, paragraph mode has to be asked for
explicitly, and maybe locale/oem/legacy, but crlf/utf8/utf16 should
all be determinable by examination. Exact character set should be
determinable on XML files.
How to default output disciplines is a wickier stickit.
Larry
>>> todo:11379
Delivery-Date: Thu Feb 24 13:59:02 2000
Message-Id: <12991.951429342@chthon>
Date: Thu, 24 Feb 2000 14:55:42 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
>: >While you're here, what will be the filemode for open to indicate
>: >binmode without having to say binmode?
>:
>: :raw, maybe?
>No maybe about it. That's a winner. :-)
> binmode FILE;
>is now offically equivalent to
> binmode FILE ":raw";
Oh boy! Does that this will work, too? :-)
open(TTY, "+<:cbreak /dev/tty")
--tom
>>> todo:11380
Delivery-Date: Thu Feb 24 14:00:21 2000
Message-Id: <200002242200.OAA22038@maul.activestate.com>
Date: Thu, 24 Feb 2000 14:00:20 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Tom Christiansen <tchrist@chthon.perl.com>
cc: Larry Wall <larry@wall.org>, larry@kiev.wall.org (Larry Wall),
gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 14:31:12 MST, Tom Christiansen wrote:
>>In that case, is binmode which?
>
>> open FILE, "<:bin", $file
>> open FILE, "<:binary", $file
>> open FILE, "<:binmode", $file
>
>How does one change the disciple later on?
binmode(FILE, ":some :thing :else").
Sarathy
gsar@ActiveState.com
>>> todo:11381
Delivery-Date: Thu Feb 24 14:02:09 2000
Message-Id: <200002242158.NAA06548@kiev.wall.org>
Date: Thu, 24 Feb 2000 13:58:56 PST
From: Larry Wall <larry@wall.org>
To: tchrist@chthon.perl.com (Tom Christiansen)
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
Tom Christiansen writes:
: Oh boy! Does that this will work, too? :-)
:
: open(TTY, "+<:cbreak /dev/tty")
If you're willing to write the :cbreak discipline portably, sure. :-) * 0/2
Larry
>>> todo:11382
Delivery-Date: Thu Feb 24 14:02:11 2000
Message-Id: <200002242156.NAA06516@kiev.wall.org>
Date: Thu, 24 Feb 2000 13:56:43 PST
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: Larry Wall <larry@wall.org>, larry@kiev.wall.org (Larry Wall),
tchrist@chthon.perl.com (Tom Christiansen),
gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
Gurusamy Sarathy writes:
: open FILE, ":raw", $file
:
: was my preference, but :binary is probably more descriptive.
No, I like :raw better, because it speaks to everyone. You have to be
more sophisticated to know that binary means raw.
Larry
>>> todo:11383
Delivery-Date: Thu Feb 24 14:08:52 2000
Message-Id: <200002242205.OAA06630@kiev.wall.org>
Date: Thu, 24 Feb 2000 14:05:38 PST
From: Larry Wall <larry@wall.org>
To: larry@kiev.wall.org (Larry Wall)
cc: tchrist@chthon.perl.com (Tom Christiansen), Larry Wall <larry@wall.org
***>,
gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
Larry Wall writes:
: Tom Christiansen writes:
: : Oh boy! Does that this will work, too? :-)
: :
: : open(TTY, "+<:cbreak /dev/tty")
:
: If you're willing to write the :cbreak discipline portably, sure. :-) * 0/2
The syntax of the shell command
$ grok ":trans:mogrify foo"
could perhaps be improved.
Larry
>>> todo:11384
Delivery-Date: Thu Feb 24 14:09:22 2000
Message-Id: <29028.951429964@chthon>
Date: Thu, 24 Feb 2000 15:06:04 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Gurusamy Sarathy <gsar@ActiveState.com>
cc: Larry Wall <larry@wall.org>
Subject: Re: binmode without binmode?
> - write crlf, locale, utf16, paragraph mode disciplines
I don't remember the story, but there's something that Matthias
was talking about wanting for the Mac and network proggies.
And Nick had some observations that came from looking at I/O
disciplines under Tcl.
Don't ask me. I'm just the parrot.
--tom
>>> todo:11385
Delivery-Date: Thu Feb 24 14:10:09 2000
Message-Id: <200002242210.OAA22079@maul.activestate.com>
Date: Thu, 24 Feb 2000 14:10:08 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: tchrist@chthon.perl.com (Tom Christiansen),
larry@kiev.wall.org (Larry Wall),
gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 13:38:50 PST, Larry Wall wrote:
>Tom Christiansen writes:
>: >In that case, is binmode which?
>:
>: > open FILE, "<:bin", $file
>: > open FILE, "<:binary", $file
>: > open FILE, "<:binmode", $file
>:
>: How does one change the disciple later on?
>
>Depends. If you haven't done any I/O, presumably
>
> binmode FILE, "<:text";
>
>Later, you have to re-open because buffers will be loaded. Some
>disciplines may be able to switch to more specific disciplines for
>efficiency if they're careful and either "nibble" the input to not
>have buffering problems, or figure out how to transfer unused buffers among
>disciplines. If we figure that out, we might be able to relax the
>restriction more generally.
It occurred to me that the way to avoid buffering issues is to make
disciplines sit above the buffering layer (stdio or whatever), so that
it won't matter. Basically the discipline only ever does its thing on
the specific read/write, so there's no buffered state that the disciplines
have to track.
>I expect we might possibly make :text work with 2-arg:
>
> open FILE, "<:text&=" . fileno(FILE) or die;
>
>Would have to be careful about people opening files starting with ":" though.
Yes, it makes me want to think about disallowing "<:foo $file" altogether.
If they want to specify a discipline, maybe they had better use the 3-arg
form.
Sarathy
gsar@ActiveState.com
>>> todo:11386
Delivery-Date: Thu Feb 24 14:10:36 2000
Message-Id: <200002242210.OAA22094@maul.activestate.com>
Date: Thu, 24 Feb 2000 14:10:34 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy), tchrist@perl.com
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 13:45:32 PST, Larry Wall wrote:
>Gurusamy Sarathy writes:
>: :raw, maybe?
>
>No maybe about it. That's a winner. :-)
Cool.
Sarathy
gsar@ActiveState.com
>>> todo:11387
Delivery-Date: Thu Feb 24 14:11:06 2000
Message-Id: <1920.951430057@chthon>
Date: Thu, 24 Feb 2000 15:07:37 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: larry@kiev.wall.org (Larry Wall), gsar@ActiveState.com (Gurusamy Sarat
***hy)
Subject: Re: binmode without binmode?
>Larry Wall writes:
>: Tom Christiansen writes:
>: : Oh boy! Does that this will work, too? :-)
>: :
>: : open(TTY, "+<:cbreak /dev/tty")
>:
>: If you're willing to write the :cbreak discipline portably, sure. :-) * 0/2
>The syntax of the shell command
> $ grok ":trans:mogrify foo"
>could perhaps be improved.
Are you thinking of magic open? The way I do
$ tcgrep "webget http://blah |"
--tom
>>> todo:11388
Delivery-Date: Thu Feb 24 14:15:06 2000
Message-Id: <10309.951430308@chthon>
Date: Thu, 24 Feb 2000 15:11:48 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Gurusamy Sarathy <gsar@ActiveState.com>
cc: Larry Wall <larry@wall.org>, larry@kiev.wall.org (Larry Wall)
Subject: Re: binmode without binmode?
>>I expect we might possibly make :text work with 2-arg:
>>
>> open FILE, "<:text&=" . fileno(FILE) or die;
>>
>>Would have to be careful about people opening files starting with ":" though.
>Yes, it makes me want to think about disallowing "<:foo $file" altogether.
>If they want to specify a discipline, maybe they had better use the 3-arg
>form.
But I should think one might want to dup/fdopen with a different discipline.
You can't exaclty reopen some kinds of things and get the right effect.
Perl doesn't have a dup() or fdopen() function. We use open for that.
--tom
Tchrist's list of what open does:
fopen
popen
fork open
fd open
dup & fdopen
Still hoping for:
bidirectional popen
bidirectional fork open
>>> todo:11389
Delivery-Date: Thu Feb 24 14:15:57 2000
Message-Id: <200002242215.OAA22127@maul.activestate.com>
Date: Thu, 24 Feb 2000 14:15:55 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen)
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 13:54:32 PST, Larry Wall wrote:
>Gurusamy Sarathy writes:
>: - write crlf, locale, utf16, paragraph mode disciplines
>:
>: + raw discipline (default on Unix)
>: - input: no change
>: - output: no change
>:
>: + crlf discipline (default on Windows?)
>: - input: remove s/\r\n/\n/g
>: - output: add s/(?<!\r)\n/\r\n/g
>:
>: + paragraph discipline
>: - input: remove s/[ \t\r]*$//mg
>: - output: no change (?)
>:
>: + locale/oem discipline
>: - input: assume data is system default charset, convert to SvUTF8
>: - output: data is SvUTF8, convert to system default charset
>: data is !SvUTF8, write it is
>:
>: + utf16 discipline
>: - input: file is utf16 text, convert to SvUTF8 data
>: - output: if data is SvUTF8, convert to utf16 text
>: if data is !SvUTF8, convert locale/oem CP to utf16
>:
>: + utf16rev discipline
>: - same as utf16 except for endianness of output/input
>
>I think we want the default :text input discipline (and maybe the real
>default default) to be capable of nibbling the file to determine which
>of those disciplines above to mutate into for efficiency. If we can
>make opening random text files a no-brainer and still way fast,
>everyone will love us. Of course, paragraph mode has to be asked for
>explicitly, and maybe locale/oem/legacy, but crlf/utf8/utf16 should
>all be determinable by examination. Exact character set should be
>determinable on XML files.
Yes, I was in fact thinking that making open() DWIM the binmode() on
dosland would be nice, if we can do it in a bulletproof way.
Maybe give them a way to choose the :dwim discipline as the system
wide default. :-)
>How to default output disciplines is a wickier stickit.
Hey, we can always have :raw be the default on output, and be compatible
to boot. :-)
Sarathy
gsar@ActiveState.com
>>> todo:11390
Replied: Thu, 24 Feb 2000 14:24:02 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: tchrist@chthon.perl.com (Tom Christiansen)
Replied: larry@kiev.wall.org (Larry Wall)
Delivery-Date: Thu Feb 24 14:18:13 2000
Message-Id: <200002242212.OAA06768@kiev.wall.org>
Date: Thu, 24 Feb 2000 14:12:17 PST
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: Larry Wall <larry@wall.org>, tchrist@chthon.perl.com (Tom Christiansen
***),
larry@kiev.wall.org (Larry Wall),
gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
Gurusamy Sarathy writes:
: It occurred to me that the way to avoid buffering issues is to make
: disciplines sit above the buffering layer (stdio or whatever), so that
: it won't matter. Basically the discipline only ever does its thing on
: the specific read/write, so there's no buffered state that the disciplines
: have to track.
You still want to be able to switch into various cheat-on-the-buffering
disciplines for screaming fast input. But I don't think you have to be
able to recover from that.
: >I expect we might possibly make :text work with 2-arg:
: >
: > open FILE, "<:text&=" . fileno(FILE) or die;
: >
: >Would have to be careful about people opening files starting with ":" though.
:
: Yes, it makes me want to think about disallowing "<:foo $file" altogether.
: If they want to specify a discipline, maybe they had better use the 3-arg
: form.
Hmm,
use magic 'open';
anyone?
Larry
>>> todo:11392
Replied: Thu, 24 Feb 2000 14:25:52 -0800
Replied: Gurusamy Sarathy <gsar@ActiveState.com>
Replied: Tom Christiansen <tchrist@chthon.perl.com>
Replied: Larry Wall <larry@wall.org>
Delivery-Date: Thu Feb 24 14:19:45 2000
Message-Id: <24987.951430588@chthon>
Date: Thu, 24 Feb 2000 15:16:28 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Gurusamy Sarathy <gsar@ActiveState.com>
cc: Larry Wall <larry@wall.org>
Subject: Re: binmode without binmode?
>Yes, I was in fact thinking that making open() DWIM the binmode() on
>dosland would be nice, if we can do it in a bulletproof way.
I wonder whether that would solve the issue of
@ARGV = map { m#^\w+://# ? "GET $_ |" : $_ } @ARGV;
while(<>) { ... }
and having the fetched files include "naughty" characters like ^Z.
--tom
>>> todo:11393
Delivery-Date: Thu Feb 24 14:20:20 2000
Message-Id: <9457.951430620@chthon>
Date: Thu, 24 Feb 2000 15:17:00 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy), larry@kiev.wall.org (Larry Wa
***ll)
Subject: Re: binmode without binmode?
>Hmm,
> use magic 'open';
>anyone?
You mean on the three arg one?
--tom
>>> todo:11394
Replied: Thu, 24 Feb 2000 14:32:38 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: tchrist@chthon.perl.com (Tom Christiansen)
Delivery-Date: Thu Feb 24 14:20:23 2000
Message-Id: <200002242217.OAA06845@kiev.wall.org>
Date: Thu, 24 Feb 2000 14:17:10 PST
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen)
Subject: Re: binmode without binmode?
Gurusamy Sarathy writes:
: Yes, I was in fact thinking that making open() DWIM the binmode() on
: dosland would be nice, if we can do it in a bulletproof way.
What makes you think only dosland needs to dwim that?
: Maybe give them a way to choose the :dwim discipline as the system
: wide default. :-)
I'm not sure it shouldn't simply be the default.
: >How to default output disciplines is a wickier stickit.
:
: Hey, we can always have :raw be the default on output, and be compatible
: to boot. :-)
Hmm. Under "use bytes" that makes some kind of sense, but the rest of
the time :utf8 or :latin1 seems more likely to be right. You don't
want to send a mixture of Latin-1 and UTF-8 to the same filehandle.
Larry
>>> todo:11395
Delivery-Date: Thu Feb 24 14:23:16 2000
Message-Id: <200002242218.OAA06868@kiev.wall.org>
Date: Thu, 24 Feb 2000 14:18:36 PST
From: Larry Wall <larry@wall.org>
To: tchrist@chthon.perl.com (Tom Christiansen)
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy),
larry@kiev.wall.org (Larry Wall)
Subject: Re: binmode without binmode?
Tom Christiansen writes:
: >Hmm,
:
: > use magic 'open';
:
: >anyone?
:
: You mean on the three arg one?
I meant on the two, actually, since that's what <> emulates.
Larry
>>> todo:11396
Delivery-Date: Thu Feb 24 14:23:20 2000
Message-Id: <200002242219.OAA06877@kiev.wall.org>
Date: Thu, 24 Feb 2000 14:19:23 PST
From: Larry Wall <larry@wall.org>
To: tchrist@chthon.perl.com (Tom Christiansen)
cc: Gurusamy Sarathy <gsar@ActiveState.com>, Larry Wall <larry@wall.org>
Subject: Re: binmode without binmode?
Tom Christiansen writes:
: >Yes, I was in fact thinking that making open() DWIM the binmode() on
: >dosland would be nice, if we can do it in a bulletproof way.
:
: I wonder whether that would solve the issue of
:
: @ARGV = map { m#^\w+://# ? "GET $_ |" : $_ } @ARGV;
: while(<>) { ... }
:
: and having the fetched files include "naughty" characters like ^Z.
The network is why everyone has to dwim crlf these days.
Larry
>>> todo:11397
Delivery-Date: Thu Feb 24 14:24:04 2000
Message-Id: <200002242224.OAA22194@maul.activestate.com>
Date: Thu, 24 Feb 2000 14:24:02 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen),
larry@kiev.wall.org (Larry Wall)
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 14:12:17 PST, Larry Wall wrote:
>Gurusamy Sarathy writes:
>: It occurred to me that the way to avoid buffering issues is to make
>: disciplines sit above the buffering layer (stdio or whatever), so that
>: it won't matter. Basically the discipline only ever does its thing on
>: the specific read/write, so there's no buffered state that the disciplines
>: have to track.
>
>You still want to be able to switch into various cheat-on-the-buffering
>disciplines for screaming fast input. But I don't think you have to be
>able to recover from that.
Whenever diddling the stdio buffers directly would be feasible,
we ought to do it. I wouldn't _dream_ of letting *that* go. :-)
But that won't be the wider general case however, especially for
disciplines that add characters.
Sarathy
gsar@ActiveState.com
>>> todo:11398
Delivery-Date: Thu Feb 24 14:25:54 2000
Message-Id: <200002242225.OAA22228@maul.activestate.com>
Date: Thu, 24 Feb 2000 14:25:52 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Tom Christiansen <tchrist@chthon.perl.com>
cc: Gurusamy Sarathy <gsar@ActiveState.com>, Larry Wall <larry@wall.org>
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 15:16:28 MST, Tom Christiansen wrote:
>>Yes, I was in fact thinking that making open() DWIM the binmode() on
>>dosland would be nice, if we can do it in a bulletproof way.
>
>I wonder whether that would solve the issue of
>
> @ARGV = map { m#^\w+://# ? "GET $_ |" : $_ } @ARGV;
> while(<>) { ... }
>
>and having the fetched files include "naughty" characters like ^Z.
It would, because we'd always be reading in binmode at the stdio
level. The crlf filtering happens only in the discipline.
Sarathy
gsar@ActiveState.com
>>> todo:11399
Delivery-Date: Thu Feb 24 14:26:33 2000
Message-Id: <18263.951430993@chthon>
Date: Thu, 24 Feb 2000 15:23:13 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
>What makes you think only dosland needs to dwim that?
For people who think line disciplines only have happen in
billville or in old big iron shops, I like to have them
think through what happens in normal POSIX tty modes, where
a ^M on input becomes a ^M^J on the screen but a ^J to
a program, whereas a ^J on output also becomes a ^M^J on
the scren but remains a ^J to a program. There's spookiness
there, indeed.
--tom
eglador(tchrist)% stty everything
speed 9600 baud; 24 rows; 80 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff -ixany -imaxbel -ignbrk
brkint -inpck -ignpar -parmrk
oflags: opost onlcr oxtabs
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -mdmbuf
discard dsusp eof eol eol2 erase intr kill lnext
^O ^Y ^D <undef> <undef> ^H ^C ^U ^V
min quit reprint start status stop susp time werase
1 ^\ ^R ^Q ^T ^S ^Z 0 ^W
>>> todo:11400
Replied: Thu, 24 Feb 2000 14:36:37 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Tom Christiansen <tchrist@chthon.perl.com>
Replied: Larry Wall <larry@wall.org>
Replied: larry@kiev.wall.org (Larry Wall)
Delivery-Date: Thu Feb 24 14:29:47 2000
Message-Id: <29048.951431185@chthon>
Date: Thu, 24 Feb 2000 15:26:25 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy), larry@kiev.wall.org (Larry Wa
***ll)
Subject: Re: binmode without binmode?
>Tom Christiansen writes:
>: >Hmm,
>:
>: > use magic 'open';
>:
>: >anyone?
>:
>: You mean on the three arg one?
>I meant on the two, actually, since that's what <> emulates.
You'd break old programs. I specifically know of programs that
passed to functions fdspecs like "<&=FH" or even just plain "-".
A lexically scoped version that disabled instead would be less
painful by far.
You're essentially talking about breaking any code that does
open(FH, "-")
open(FH, "cmd|")
open(FH, "|cmd")
etc. And please don't break it for nonliterals.
Perhaps you should have a different function, or should have
had many different functions?
--tom
>>> todo:11401
Delivery-Date: Thu Feb 24 14:32:40 2000
Message-Id: <200002242232.OAA22253@maul.activestate.com>
Date: Thu, 24 Feb 2000 14:32:38 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen)
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 14:17:10 PST, Larry Wall wrote:
>Gurusamy Sarathy writes:
>: Yes, I was in fact thinking that making open() DWIM the binmode() on
>: dosland would be nice, if we can do it in a bulletproof way.
>
>What makes you think only dosland needs to dwim that?
Sure, we can dwim it on Unix too. With samba gaining ground, people
everywhere seem to be afflicted with the crlf disease.
>: Maybe give them a way to choose the :dwim discipline as the system
>: wide default. :-)
>
>I'm not sure it shouldn't simply be the default.
Need to be careful here, we wouldn't want to break people's CRLF
strippers.
>: >How to default output disciplines is a wickier stickit.
>:
>: Hey, we can always have :raw be the default on output, and be compatible
>: to boot. :-)
>
>Hmm. Under "use bytes" that makes some kind of sense, but the rest of
>the time :utf8 or :latin1 seems more likely to be right. You don't
>want to send a mixture of Latin-1 and UTF-8 to the same filehandle.
Yup, :latin1 is probably the choice de jure for output.
Sarathy
gsar@ActiveState.com
>>> todo:11402
Delivery-Date: Thu Feb 24 14:36:38 2000
Message-Id: <200002242236.OAA22306@maul.activestate.com>
Date: Thu, 24 Feb 2000 14:36:37 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Tom Christiansen <tchrist@chthon.perl.com>
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy),
larry@kiev.wall.org (Larry Wall)
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 15:26:25 MST, Tom Christiansen wrote:
>>Tom Christiansen writes:
>>: >Hmm,
>>:
>>: > use magic 'open';
>>:
>>: >anyone?
>>:
>>: You mean on the three arg one?
>
>>I meant on the two, actually, since that's what <> emulates.
>
>You'd break old programs.
I think Larry meant it just for recognizing discipline-specs in
the string. It'd be ok for that, I think.
Sarathy
gsar@ActiveState.com
>>> todo:11403
Replied: Thu, 24 Feb 2000 14:44:26 -0800
Replied: Gurusamy Sarathy <gsar@ActiveState.com>
Replied: Tom Christiansen <tchrist@chthon.perl.com>
Replied: Larry Wall <larry@wall.org>
Delivery-Date: Thu Feb 24 14:37:44 2000
Message-Id: <23524.951431665@chthon>
Date: Thu, 24 Feb 2000 15:34:25 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Gurusamy Sarathy <gsar@ActiveState.com>
cc: Larry Wall <larry@wall.org>
Subject: Re: binmode without binmode?
>I doubt we'll make sysopen() with all its weirdly named flags the
>canonical way to open things. :-)
You mean the canonical way to open files. There are more things
to dream of opening, like pipes and forks and duped handles. :-)
>binmode() doesn't even work when you open the file for append mode
>and it contains a ^Z in the middle.
Oh, grblech. But
sysopen(FH, $path, O_BINARY | O_WRONGLY | O_CREAT | O_APPEND)
is ok?
--tom
>>> todo:11404
Delivery-Date: Thu Feb 24 14:38:47 2000
Message-Id: <21273.951431731@chthon>
Date: Thu, 24 Feb 2000 15:35:31 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Gurusamy Sarathy <gsar@ActiveState.com>
cc: Larry Wall <larry@wall.org>, larry@kiev.wall.org (Larry Wall)
Subject: Re: binmode without binmode?
>>>: >Hmm,
>>>: > use magic 'open';
>>>: >anyone?
>>>: You mean on the three arg one?
>>>I meant on the two, actually, since that's what <> emulates.
>>You'd break old programs.
>I think Larry meant it just for recognizing discipline-specs in
>the string. It'd be ok for that, I think.
I realized a couple minutes after hitting push that he couldn't
possibly be suggesting making all two-arg open be files only.
--tom
>>> todo:11405
Delivery-Date: Thu Feb 24 14:39:42 2000
Message-Id: <869.951431785@chthon>
Date: Thu, 24 Feb 2000 15:36:25 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Gurusamy Sarathy <gsar@ActiveState.com>
cc: Larry Wall <larry@wall.org>
Subject: Re: binmode without binmode?
>>Eep, I see that IO::Handle::_open_mode_string doesn't know about
>>"b" (from fopen). It probably should, and then call sysopen not
>>open.
>Sure looks like it.
Please >>TODO that, or fire a telegraham off for him to do it. :-)
--tom
>>> todo:11407
Delivery-Date: Thu Feb 24 14:44:27 2000
Message-Id: <200002242244.OAA22426@maul.activestate.com>
Date: Thu, 24 Feb 2000 14:44:25 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Tom Christiansen <tchrist@chthon.perl.com>
cc: Gurusamy Sarathy <gsar@ActiveState.com>, Larry Wall <larry@wall.org>
Subject: Re: binmode without binmode?
On Thu, 24 Feb 2000 15:34:25 MST, Tom Christiansen wrote:
>>binmode() doesn't even work when you open the file for append mode
>>and it contains a ^Z in the middle.
>
>Oh, grblech. But
>
> sysopen(FH, $path, O_BINARY | O_WRONGLY | O_CREAT | O_APPEND)
>
>is ok?
Yup.
Sarathy
gsar@ActiveState.com
>>> todo:11408
Delivery-Date: Thu Feb 24 14:47:10 2000
Message-Id: <23601.951432233@chthon>
Date: Thu, 24 Feb 2000 15:43:53 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Gurusamy Sarathy <gsar@ActiveState.com>
cc: Larry Wall <larry@wall.org>
Subject: Re: binmode without binmode?
>> sysopen(FH, $path, O_BINARY | O_WRONGLY | O_CREAT | O_APPEND)
>>is ok?
>Yup.
Except for my silly Freudian, which my fingers put there and my
eyes denied my seeing. :-)
--tom
>>> todo:11409
Delivery-Date: Thu Feb 24 14:48:17 2000
Message-Id: <200002242242.OAA07192@kiev.wall.org>
Date: Thu, 24 Feb 2000 14:42:46 PST
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen)
Subject: Re: binmode without binmode?
Gurusamy Sarathy writes:
: >: >How to default output disciplines is a wickier stickit.
: >:
: >: Hey, we can always have :raw be the default on output, and be compatible
: >: to boot. :-)
: >
: >Hmm. Under "use bytes" that makes some kind of sense, but the rest of
: >the time :utf8 or :latin1 seems more likely to be right. You don't
: >want to send a mixture of Latin-1 and UTF-8 to the same filehandle.
:
: Yup, :latin1 is probably the choice de jure for output.
Praps :text would examine LC_CTYPE, at least on systems like Linux where
that's supposed to drive everythine one way or the other.
Larry
>>> todo:11411
Delivery-Date: Thu Feb 24 14:58:17 2000
Message-Id: <200002242252.OAA07324@kiev.wall.org>
Date: Thu, 24 Feb 2000 14:52:50 PST
From: Larry Wall <larry@wall.org>
To: tchrist@chthon.perl.com (Tom Christiansen)
cc: Gurusamy Sarathy <gsar@ActiveState.com>, Larry Wall <larry@wall.org>
Subject: Re: binmode without binmode?
Tom Christiansen writes:
: >> sysopen(FH, $path, O_BINARY | O_WRONGLY | O_CREAT | O_APPEND)
: >>is ok?
:
: >Yup.
:
: Except for my silly Freudian, which my fingers put there and my
: eyes denied my seeing. :-)
Also funny how the ghost of creat() lives on.
Larry
>>> todo:11475
Replied: Fri, 25 Feb 2000 23:39:08 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: tchrist@chthon.perl.com (Tom Christiansen)
Delivery-Date: Fri Feb 25 21:54:10 2000
Message-Id: <200002260545.VAA22758@kiev.wall.org>
Date: Fri, 25 Feb 2000 21:45:42 PST
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy), Larry Wall <larry@wall.org>,
gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen)
Subject: Re: binmode without binmode?
Here's what I've writ about disciplines. You can skip most of C<open>.
The discipline stuff is down at the end. In particular, I'd like to
know if I got the stacking order right. I figure the discipline
closest to the filename ought to go on the right, and the discipline
closest to the filehandle on the left, so input processing goes
right-to-left, while output processing goes left-to-right.
Larry
=head2 binmode
binmode R<FILEHANDLE>, R<DISCIPLINES>
binmode R<FILEHANDLE>
=for index
binmode function
files ;read in binary mode
binary;mode on filehandles
disciplines, filehandle; setting with binmode
This function arranges for the R<FILEHANDLE> to have the semantics
specified by the R<DISCIPLINES> argument. If R<DISCIPLINES> is
omitted, binary semantics are applied to the filehandle. If
R<FILEHANDLE> is an expression, the value is taken as the name of the
filehandle or a reference to a filehandle, as appropriate.
The C<binmode> function should be called after the C<open> but before
any I/O is done on the filehandle. The only way to reset the mode on a
filehandle is to reopen the file, since the various disciplines may
have treasured up various bits and pieces of data in various buffers.
This restriction may be relaxed in the future.
In the olden days, C<binmode> was used primarily on operating systems
whose run-time libraries distinguish text from binary files. On those
systems, the purpose of C<binmode> was to turn off the default text
semantics. However, with the advent of Unicode, all programs on all
systems must take some cognizance of the distinction, even on Unix and
Mac systems. These days there is only one kind of binary file (as far
as Perl is concerned), but there are many kinds of text files, which
Perl would also like to treat in a single way. So Perl has a single
internal format for Unicode text, UTF-8. Since there are many kinds of
text files, text files often need to be translated upon input into
UTF-8, and upon output back into some legacy character set, or some
other representation of Unicode. You can use disciplines to tell Perl
how exactly (or inexactly) to do these translations.
For example, a discipline of C<":text"> will tell Perl to do generic
text processing without telling Perl which kind of text processing to
do. But disciplines like C<":utf8"> and C<":latin1"> tell Perl which
text format to read and write. On the other hand, the C<":raw">
discipline tells Perl to keep its cotton-pickin' hands off the data.
For more on how to use filehandle disciplines, see L<Chapter ##, Input
and Output>. The rest of this discussion is about what C<binmode> does
without the R<DISCIPLINES> argument; that is, the historical meaning of
C<binmode>, which is equivalent to:
binmode R<FILEHANDLE, ":raw";
Unless instructed otherwise, Perl will assume your freshly-opened file
should be read or written in text mode. Text mode means that
C<\n> (newline) will be your internal line terminator. All systems use
C<\n> as the internal line terminator, but what that really represents
varies from system to system, device to device, and even file to file,
depending on how you access the file. In such legacy systems
(including MS-DOS and VMS), what your program sees as a C<\n> may not
be what's physically stored on disk. The operating system might, for
example, store text files with C<\cM\cJ> sequences that are translated
on input to appear as C<\n> to your program, and have C<\n> from your
program translated back to C<\cM\cJ> on output to a file. C<binmode>
disables this automatic translation on such systems.
In the absence of a R<DISCIPLINES> argument, C<binmode> has no effect
under Unix or Mac OS, both of which use C<\n> to end each line, and
represent that as a single character. (It is, however, a different
character: Unix uses C<\cJ> and the Mac uses C<\cM>. Doesn't matter.)
The following example shows how a Perl script might read a GIF image
from a file and print it to the standard output. On systems that
would otherwise alter literal data into something other than its
exact physical representation, you must prepare both handles.
binmode STDOUT;
open(GIF, "vim-power.gif") or die "Can't open vim-powergif: $!\n";
binmode GIF;
while (read(GIF, $buf, 1024)) {
print STDOUT $buf;
}
=head2 open
open R<FILEHANDLE>, R<MODE>, R<EXPR>
open R<FILEHANDLE>, R<EXPR>
open R<FILEHANDLE>
=for index
open function
files;open function
filehandles;open function
filehandles;indirect
The C<open> function associates an internal R<FILEHANDLE> with an
external file specification given by R<EXPR>. It may be called with
one, two, or three arguments. If all three arguments are present, the
second argument specifies the access R<MODE> in which the file should
be opened, while the third argument supplies the actual filename. If
only two arguments are present, the mode and filename are assumed to be
combined in the second argument. (And if you don't specify a mode there,
the file is opened read-only, just to be on the safe side.) With
only one argument, the global scalar variable of the same name as the
R<FILEHANDLE> must contain the filename and optional mode:
$LOG = ">logfile"; # $LOG must not be declared my!
open LOG or die "Can't open logfile: $!";
But don't do that. It's not stylin'. Forget we mentioned it.
The C<open> function returns true when it succeeds and C<undef>
otherwise. If the C<open> started up a pipe to a child process, the
return value happens to be the process ID of that new process. As with
any syscall, always check the return value of C<open> to make sure it
worked. But this isn't C or Java, so don't use an C<if> statement when
the C<or> operator will do. You can also use C<||>, but if you do, use
parentheses on the C<open>. If you choose to omit parentheses on the
function call to turn it into a list operator, be careful to use "C<or
die>" after the list rather than "C<|| die>", because the precedence of
C<||> is higher than list operators like C<open>, and the C<||> will
bind to your last argument, not the whole open:
open LOG, ">logfile" || die "Can't create logfile: $!"; # WRONG
open LOG, ">logfile" or die "Can't create logfile: $!"; # ok
That looks rather intense, but typically you'd introduce some
whitespace to tell your eye where the list operator ends:
open LOG, ">logfile"
or die "Can't create logfile: $!";
=for index
indirect filehandles
autovivification; of filehandles
As that example shows, the R<FILEHANDLE> argument is often just a
simple identifier (normally uppercase), but it may also be an
expression whose value provides a reference to the actual filehandle.
(The reference may be either a symbolic reference to the filehandle
name, or a hard reference to any object that can be interpreted as a
filehandle.) This is called an I<indirect filehandle>, and any
function that takes a R<FILEHANDLE> as its first argument can handle
indirect filehandles as well as direct. But C<open> is special in
that, if you supply it with an undefined variable for the indirect
filehandle, Perl will automatically define that variable for you,
autovivifying it to contain a proper filehandle reference. One
advantage of this is that the filehandle will be automatically closed
when there are no further references to it, typically when the variable
goes out of scope:
{
my $fh; # (uninitialized)
open($fh, ">logfile") # $fh is autovivified
or die "Can't create logfile: $!";
... # do stuff with $fh
} # $fh closed here
The C<my> C<$fh> declaration can be readably incorporated into the C<open>:
open my $fh, ">logfile" or die ...
=for index
@right=> (right angle bracket) ;filenames=in filenames
@left=< (left angle bracket) ;filenames=in filenames
@plus=+ (plus) ;filenames=in filenames
@vertical=| (vertical bar) ;filenames=in filenames
The C<< > >> symbol you've been seeing in front of the filename is an
example of a mode. Historically, the two-argument form of C<open> came
first. The recent addition of the three-argument form lets you
separate the mode from the filename, which has the advantage of
avoiding any possible confusion between the two. In the following
example, we know that the user is not trying to open a filename that
happens to start with "C<< > >>". We can be sure that they're
specifying a R<MODE> of "C<< > >>", which opens the file named in
R<EXPR> for writing, creating the file if it doesn't exist and
truncating the file down to nothing if it already exists:
open(LOG, ">", "logfile") or die "Can't create logfile: $!";
In the shorter forms, the filename and mode are in the same string.
The string is parsed much like the typical shell processes file and
pipe redirections. First, any leading and trailing whitespace is
removed from the string. Then the string is examined, on either end if
need be, for characters specifying how the file is to be opened.
Whitespace is allowed between the mode and the filename.
The modes for indicating how to open a file are shell-like redirection
symbols. A list of these symbols is provided in the table below.
(To access a file with combinations of open modes not covered by
this table, see the low-level C<sysopen> function.)
=for informaltable PERL3-TAB-open-modes
Read Write Append Create Clobber
Mode Access Access Only Nonexisting Existing
---- ------ ------ ------ ----------- --------
< path Y N N N N
> path N Y N Y Y
>> path N Y Y Y N
+< path Y Y N N N
+> path Y Y N Y Y
+>> path Y Y Y Y N
| command N Y n/a n/a n/a
command | Y N n/a n/a n/a
If the filename begins with "C<< < >>" or nothing, an existing file
is opened for input. If the filename begins with "C<< > >>", the
file is opened for output, which truncates existing files and creates
non-existent ones. If the filename begins with "C<< >> >>",
the file is opened for appending, creating it if needed, automatically
placing all output at the end of the file. If a new file is created
because you used a mode of "C<< > >>" or "C<< >> >>" and the
file did not previously exist, access permissions depend on the
process's current C<umask> under the rules described for that
function.
Here are common examples:
open(INFO, "datafile") || die("can't open datafile: $!");
open(INFO, "< datafile") || die("can't open datafile: $!");
open(RESULTS, "> runstats") || die("can't open runstats: $!");
open(LOG, ">> logfile ") || die("can't open logfile: $!");
If you prefer the low-punctuation version, you can write:
open INFO, "datafile" or die "can't open datafile: $!";
open INFO, "< datafile" or die "can't open datafile: $!";
open RESULTS, "> runstats" or die "can't open runstats: $!";
open LOG, ">> logfile " or die "can't open logfile: $!";
When opened for reading, the special filename "C<->" refers to
C<STDIN>. When opened for writing, the same special filename refers
to C<STDOUT>. Normally, these are specified as C<< "<-" >> and
C<< ">-" >>, respectively.
open(INPUT, "-" ) # re-open standard input for reading
open(INPUT, "<-") # same thing, but explicit
open(OUTPUT, ">-") # re-open standard output for writing
This way the user can supply a program with a filename that means
to use the standard input or the standard output, but the author
of the program doesn't have to write special code to know about
this.
You may also place a "C<+>" in front of any of these three modes
to request simultaneous read and write. However, whether the file
is clobbered or created and whether it must already exist is still
governed by your choice of less-than or greater-than signs. This
means that "C<< +< >>" is almost always preferred for read/write
updates, as the dubious "C<< +> >>" mode would first clobber the
file before you could ever read anything from it. (Use that one
only if you want to reread only what you just wrote.)
open(DBASE, "+< database")
or die "can't open existing database in update mode: $!";
You can treat a file opened for update as a random-access
database, using C<seek> to move to a particular byte number, but the
variable-length records of regular text files usually make it
impractical to use read-write mode to update such files. See the
B<-i> command-line option in L<Chapter ##, Switches> for a better approach
to updating.
If the leading character in R<EXPR> is a pipe symbol, C<open> fires
up a new process and connects a write-only filehandle to that
command. This way you can write into that handle and have what you
write show up on that command's standard input. For example:
open(PRINTER, "| lpr -Plp1") or die "can't fork: $!";
print PRINTER "stuff\n";
close(PRINTER) or die "lpr/close failed: $?/$!";
If the trailing character in R<EXPR> is a pipe symbol, C<open> again
launches a new process, but this time with a read-only filehandle
connected to it. This lets whatever that command writes to its
standard output show up on your handle for reading. For example:
open(NET, "netstat -i -n |") or die "can't fork: $!";
while (<NET>) { ... }
close(NET) or die "can't close netstat: $!/$?";
Explicitly closing any piped filehandle causes the parent process to
wait for the child to finish, and returns the status code in C<$?>
(C<$CHILD_ERROR>). C<close> may also set C<$!> (C<$OS_ERROR>). See
the examples under C<close> and C<system> for how to interpret these
error codes.
Any pipe command containing shell metacharacters such as wildcards
or I/O redirections is passed to your system's canonical shell
(I</bin/sh> on Unix) so those shell-specific constructs can be
processed first. If no metacharacters are found, Perl launches the
new process itself without calling the shell.
You may also use the three-argument form to start up pipes.
The equivalent of the pipe opens above using that style is:
open(PRINTER, "|-", "lpr -Plp1") or die "can't fork: $!";
open(NET, "-|", "netstat -i -n") or die "can't fork: $!";
Here the minus in the second argument represents the command in the
third argument.
If you use the two-argument form to open a pipe to or from the special
command "C<->" (or, equivalently, leave out the command argument of the
three-argument forms in the last example), an implicit C<fork> is done
first. In this case the minus represents your new child process, which
is a copy of the parent. The return value from this forking C<open> is
the process id of the child when examined from the parent process, C<0>
when examined from the child process, and the undefined value C<undef>
if the C<fork> fails--in which case, there is no child. For example:
defined($pid = open(FROM_CHILD, "-|"))
or die "can't fork: $!";
if ($pid) {
@parent_lines = <FROM_CHILD>; # parent code
}
else {
print STDOUT @child_lines; # child code
}
The filehandle behaves normally for the parent, but for the child's
process, the parent's input (or output) is piped from (or to) the
child's C<STDOUT> (or C<STDIN>). The child process does not see the
parent's filehandle opened. (This is conveniently indicated by the C<0> PID.)
Typically you'd use this construct instead of the normal piped C<open>
when you want to exercise more control over just how the pipe command
gets executed, such as when you are running setuid, and don't want to
have to scan shell commands for metacharacters. The following pairs
are equivalent (including not checking for errors from a failed fork):
open FOO, "| tr 'a-z' 'A-Z'"; # pipe to command
open FOO, "|-" or exec 'tr', 'a-z', 'A-Z'; # pipe to child
open FOO, "cat -n file |"; # pipe from command
open FOO, "-|" or exec 'cat', '-n', 'file'; # pipe from child
For more elaborate uses of fork open, see the section on "Talking
to yourself" in the chapter on L<Chapter ##, Interprocess Communication>,
and in the section on "Cleaning up your path" in the chapter on
L<Chapter ##, Security>.
When starting a command with C<open>, you must choose either input
or output: "C<cmd|>" for reading or "C<|cmd>" for
writing. You may not use C<open> to start a command that pipes
both in and out, as the (currently) illegal notation, C<"|cmd|">,
might appear to indicate. However, the standard C<IPC::Open2> and
C<IPC::Open3> library routines give you a close equivalent. For details
on double-ended pipes, see the section "Bidirectional Communication"
in L<Chapter ##, Interprocess Communication>.
=for index
@ampersand=E<amp> (ampersand) ;filenames=in filenames
You may also, in the Bourne shell tradition, specify an R<EXPR>
beginning with C<< >E<amp> >>, in which case the rest of the string
is interpreted as the name of a filehandle (or file descriptor, if
numeric) to be duplicated using the I<dup2>(2) syscall. You may
use C<E<amp>> after C<< > >>, C<< >> >>, C<< < >>, C<< +> >>,
C<< +>> >>, and C<< +< >>. (The specified mode should match
the mode of the original filehandle.)
One reason you might want to do this would be if you already had a
filehandle open and wanted to make another handle that's really a
duplicate of the first one.
open(SAVEOUT, ">&SAVEERR") or die "couldn't dup SAVEERR: $!";
open(MHCONTEXT, "<&4") or die "couldn't dup fd4: $!";
That means that if a function is expecting a filename, but you don't
want to give it a filename because you already have the file open, you
can just pass the filehandle with a leading ampersand. It's best to
use a fully qualified handle though, just in case the function happens
to be in a different package:
somefunction("&main::LOGFILE");
Another reason to "dup" file handles is because you want to temporarily
redirect where an existing filehandle is going without losing track
of the original. Here is a script that saves, redirects, and
restores C<STDOUT> and C<STDERR>:
#!/usr/bin/perl
open SAVEOUT, ">&STDOUT";
open SAVEERR, ">&STDERR";
open STDOUT, ">foo.out" or die "Can't redirect stdout";
open STDERR, ">&STDOUT" or die "Can't dup stdout";
select STDERR; $| = 1; # make unbuffered
select STDOUT; $| = 1; # make unbuffered
print STDOUT "stdout 1\n"; # this propagates to
print STDERR "stderr 1\n"; # subprocesses too
system("some command"); # uses new stdout/stderr
close STDOUT;
close STDERR;
open STDOUT, ">&SAVEOUT";
open STDERR, ">&SAVEERR";
print STDOUT "stdout 2\n";
print STDERR "stderr 2\n";
If the filehandle or descriptor number to be duplicated is preceded
not just with a simple "C<&>" before its mode, but rather with a
"C<&=>" combination, instead of creating a completely new handle,
Perl makes something of an alias to the existing one using the
I<fdopen>(3) C library call. This is slightly more parsimonious
of systems resources, although that's less of a concern these days.
$fd = $ENV{"MHCONTEXTFD"};
open(MHCONTEXT, "<&=$fdnum")
or die "couldn't fdopen descriptor $fdnum: $!";
=for index
forks
processes;ID (pid)
pid==>processes
Filehandles C<STDIN>, C<STDOUT>, and C<STDERR> always remain open across
an C<exec>. Other filehandles, by default, do not. On systems supporting
the C<fcntl> function, you may modify the close-on-exec flag for a
filehandle.
use Fcntl qw(F_GETFD F_SETFD);
$flags = fcntl(FH, F_SETFD, 0)
or die "Can't clear close-on-exec flag on FH: $!\n";
See also the special C<$SYSTEM_FD_MAX>/C<$^F> variable in L<Chapter
##, Special Names>.
When using the one- or two-argument form of C<open>, to open a file
for reading whose name may have arbitrarily weird characters that
would otherwise be interpreted as a R<MODE> string, a dup specification,
or a minus for the shorthand for the standard input or output, you
have to insulate yourself this way:
$path =~ s#^(\s)#./$1#;
open (FH, "< $path\0")
or die "can't open $path: $!";
=for index
sysopen function
This is more easily accomplished using either the three-argument
form of C<open> or the C<sysopen> function.
open(FH, "<", $path)
or die "can't open $path: $!";
use Fcntl;
sysopen(FH, $path, O_RDONLY)
or die "can't open $path: $!";
If what you're looking for is a true, C-style I<open>(2) syscall
with all its attendant whistles and bells, then C<sysopen> is really
what you want. See C<sysopen> for examples.
=for index
binmode
files;text/binary distinction
binary;files
disciplines
If you're running on a system that distinguishes between text and
binary files, you may need to put your filehandle into binary mode--or
forego doing so, as the case may be--to avoid mutilating your files.
On such systems, if you use text mode on a binary file, or binary mode
on a text file, you probably won't like the results. Systems that need
the C<binmode> function are distinguished from those that don't by the
format used for text files. Those that don't need it terminate
each line with a single character that corresponds to what C thinks is
a newline, C<'\n'>. Unix and MacOS are fall into this category, but
VMS, MVS, MS-whatever, and S&M operating systems of other varieties
treat I/O on textfiles and binary files differently, so they need
C<binmode>.
Or its equivalent. As of the 5.6 release of Perl, you can specify
binary mode in the C<open> function without a separate call to
C<binmode>. As part of the R<MODE> argument, you may specify various
input and output disciplines. To do the equivalent of a C<binmode>,
use the three argument form of C<open> and stuff a discipline of C<:raw>
in after the other R<MODE> characters:
open(FH, "<:raw", $path) or die "can't open $path: $!";
Since this is a very new feature, there will certainly be more
disciplines by the time you read this than there were when we wrote
it. However, we can reasonably predict that there will in all
likelihood be disciplines resembling some or all of the following:
=for informaltable PERL3-TAB-disciplines
Discipline Meaning
---------- -------
C<:raw> Binary mode; do no processing
C<:text> Default text processing
C<:def> Default declared by "C<use open>"
C<:latin1> File should be ISO-8859-1
C<:ctype> File should be LC_CTYPE
C<:utf8> File should be UTF-8
C<:utf16> File should be UTF-16
C<:utf32> File should be UTF-32
C<:uni> Intuit Unicode (UTF-*)
C<:any> Intuit Unicode/Latin1/LC_CTYPE
C<:xml> Use encoding specified in file
C<:crlf> Intuit newlines
C<:para> Paragraph mode
C<:slurp> Slurp mode
You'll be able to stack disciplines that make sense to stack, so, for
instance, you could say:
open(FH, "<:para:crlf:uni", $path) or die "can't open $path: $!";
while ($para = <FH>) { ... }
That would set up disciplines to:
=over 4
=item *
read in some form of Unicode and translate to Perl's internal UTF-8 format
if the file isn't already in UTF-8,
=item *
look for variants of line ending sequences, translating them all to C<\n>.
=item *
process the file into paragraph-sized chunks, much as C<$/ = ""> does.
=back
If you want to set the default open mode (C<:def>) to something other
than C<:text>, you can declare that at the top of your file with:
use open IN => ":any", OUT => ":utf8";
In fact, it would be really nice if that were the default C<:text>
discipline someday. It perfectly captures the spirit of "Be liberal in
what you accept, and strict in what you produce." For more on
disciplines, see L<Chapter ##, Input and Output>.
>>> todo:11479
Delivery-Date: Fri Feb 25 23:39:10 2000
Message-Id: <200002260739.XAA25826@maul.activestate.com>
Date: Fri, 25 Feb 2000 23:39:08 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen)
Subject: Re: binmode without binmode?
On Fri, 25 Feb 2000 21:45:42 PST, Larry Wall wrote:
>Here's what I've writ about disciplines. You can skip most of C<open>.
>The discipline stuff is down at the end. In particular, I'd like to
>know if I got the stacking order right. I figure the discipline
>closest to the filename ought to go on the right, and the discipline
>closest to the filehandle on the left, so input processing goes
>right-to-left, while output processing goes left-to-right.
Looks great.
Noticed a few typos:
>For more on how to use filehandle disciplines, see L<Chapter ##, Input
>and Output>. The rest of this discussion is about what C<binmode> does
>without the R<DISCIPLINES> argument; that is, the historical meaning of
>C<binmode>, which is equivalent to:
>
> binmode R<FILEHANDLE, ":raw";
^
missing ---------------- >
>The following example shows how a Perl script might read a GIF image
>from a file and print it to the standard output. On systems that
>would otherwise alter literal data into something other than its
>exact physical representation, you must prepare both handles.
>
> binmode STDOUT;
> open(GIF, "vim-power.gif") or die "Can't open vim-powergif: $!\n";
^
missing --------------------------------------------------- .
>The C<open> function associates an internal R<FILEHANDLE> with an
>external file specification given by R<EXPR>. It may be called with
>one, two, or three arguments.
=for later
Or any number if we get our C<open PIPE, "-|", 'cat', '-n', 'file'>
act together.
> If all three arguments are present, the
>second argument specifies the access R<MODE> in which the file should
>be opened, while the third argument supplies the actual filename. If
>only two arguments are present, the mode and filename are assumed to be
>combined in the second argument. (And if you don't specify a mode there,
>the file is opened read-only, just to be on the safe side.) With
>only one argument, the global scalar variable of the same name as the
>R<FILEHANDLE> must contain the filename and optional mode:
>
> $LOG = ">logfile"; # $LOG must not be declared my!
> open LOG or die "Can't open logfile: $!";
>
>But don't do that. It's not stylin'. Forget we mentioned it.
Heh-heh. :-)
>format used for text files. Those that don't need it terminate
>each line with a single character that corresponds to what C thinks is
>a newline, C<'\n'>. Unix and MacOS are fall into this category, but
s/are //
>VMS, MVS, MS-whatever, and S&M operating systems of other varieties
>treat I/O on textfiles and binary files differently, so they need
>C<binmode>.
Sarathy
gsar@ActiveState.com
>>> todo:11489
Replied: Sat, 26 Feb 2000 10:38:23 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: tchrist@chthon.perl.com (Tom Christiansen)
Delivery-Date: Sat Feb 26 10:03:52 2000
Message-Id: <200002261800.KAA28277@kiev.wall.org>
Date: Sat, 26 Feb 2000 10:00:23 PST
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen)
Subject: Re: binmode without binmode?
Gurusamy Sarathy writes:
: >The C<open> function associates an internal R<FILEHANDLE> with an
: >external file specification given by R<EXPR>. It may be called with
: >one, two, or three arguments.
:
: =for later
: Or any number if we get our C<open PIPE, "-|", 'cat', '-n', 'file'>
: act together.
Can we at least put the 3rd argument into LIST context how so people
don't get used to a scalarized 3rd arg? Or do we want 3rd arg scalar
and then a LIST?
My other question is, how will we specify a path if it's different from
first arg? Force them to fork and exec? Other options, none of them
particularly appealing:
open PIPE, "-|:path", '/usr/local/bin/cat', 'cat', '-n', 'file'>
open PIPE, "-|{/usr/local/bin/cat}", 'cat', '-n', 'file'>
open {"/usr/local/bin/cat"} PIPE, "-|", 'cat', '-n', 'file'>
Larry
>>> todo:11490
Delivery-Date: Sat Feb 26 10:09:54 2000
Message-Id: <200002261806.KAA28339@kiev.wall.org>
Date: Sat, 26 Feb 2000 10:06:34 PST
From: Larry Wall <larry@wall.org>
To: larry@kiev.wall.org (Larry Wall)
cc: gsar@ActiveState.com (Gurusamy Sarathy), Larry Wall <larry@wall.org>,
gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen)
Subject: Re: binmode without binmode?
Larry Wall writes:
: Gurusamy Sarathy writes:
: : >The C<open> function associates an internal R<FILEHANDLE> with an
: : >external file specification given by R<EXPR>. It may be called with
: : >one, two, or three arguments.
: :
: : =for later
: : Or any number if we get our C<open PIPE, "-|", 'cat', '-n', 'file'>
: : act together.
:
: Can we at least put the 3rd argument into LIST context how so people
: don't get used to a scalarized 3rd arg? Or do we want 3rd arg scalar
: and then a LIST?
:
: My other question is, how will we specify a path if it's different from
: first arg? Force them to fork and exec? Other options, none of them
: particularly appealing:
:
: open PIPE, "-|:path", '/usr/local/bin/cat', 'cat', '-n', 'file'
: open PIPE, "-|{/usr/local/bin/cat}", 'cat', '-n', 'file'
: open {"/usr/local/bin/cat"} PIPE, "-|", 'cat', '-n', 'file'
I suppose if we required list form to specify both names, but default
the path, then we could have
open PIPE, "-|", "/usr/local/bin/cat", "cat", "-n", "file"
open PIPE, "-|", "", "cat", "-n", "file"
That argues for EXPR, LIST rather than LIST. On the other hand, if we
do that, we'll certainly have people writing
open PIPE, "-|", "cat", "-n", "file"
and wondering where the -n went. So maybe that's a bad plan.
Larry
>>> todo:11492
Replied: Sat, 26 Feb 2000 10:46:36 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Tom Christiansen <tchrist@chthon.perl.com>
Replied: Larry Wall <larry@wall.org>
Delivery-Date: Sat Feb 26 10:12:08 2000
Message-Id: <21466.951588524@chthon>
Date: Sat, 26 Feb 2000 11:08:44 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen), tchrist@chthon.perl.com
Subject: Re: binmode without binmode?
>: Or any number if we get our C<open PIPE, "-|", 'cat', '-n', 'file'>
>Can we at least put the 3rd argument into LIST context [n]ow so people
>don't get used to a scalarized 3rd arg? Or do we want 3rd arg scalar
>and then a LIST?
I can't see a case where you would want a scalar as the 3rd case,
so probably it should be made list context right away. There
can't be many things using it. I fear confuison between
open HANDLE, $mode, @arglist;
Although there's already the potention with
open HANDLE, @mode_and_arglist;
since that's doing to be a number. (You know, the way people
get confused about printf @ARGS vs sprintf @ARGS having different
protos.)
>My other question is, how will we specify a path if it's different from
>first arg? Force them to fork and exec? Other options, none of them
>particularly appealing:
> open PIPE, "-|:path", '/usr/local/bin/cat', 'cat', '-n', 'file'>
> open PIPE, "-|{/usr/local/bin/cat}", 'cat', '-n', 'file'>
> open {"/usr/local/bin/cat"} PIPE, "-|", 'cat', '-n', 'file'>
OR
open PIPE, "-|", {"/usr/local/bin/cat"} => 'cat', '-n', 'file'
or
open PIPE, "-|", cat => {"/usr/local/bin/cat"}, '-n', 'file'
Hm... that looks to be a lot more like some hulking initializer for
some object out of a module somewhere, since the core hasn't really
gone in for that kind of embellishment.
--tom
>>> todo:11494
Delivery-Date: Sat Feb 26 10:20:02 2000
Message-Id: <4534.951588997@chthon>
Date: Sat, 26 Feb 2000 11:16:37 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: larry@kiev.wall.org (Larry Wall), gsar@ActiveState.com (Gurusamy Sarat
***hy),
tchrist@chthon.perl.com (Tom Christiansen), tchrist@chthon.perl.com
Subject: Re: binmode without binmode?
Some of these look like smilocons:
open PIPE, "|-:text", "lpr fred -";
Hm... I just noticed that it looks like we'll have to check whether
there's just one argument, and if so, still break things up, and
maybe use the shell. Right now, you can do this:
open PIPE, "|-", "cat -n /etc/motd - 2>/dev/null";
print PIPE "done\n";
close PIPE;
That's back to the awkwardness of system/exec needing
system { $args[0] } @args;
to guarantee the shell won't be called when @args == 1.
--tom
>>> todo:11495
Delivery-Date: Sat Feb 26 10:28:58 2000
Message-Id: <200002261822.KAA28494@kiev.wall.org>
Date: Sat, 26 Feb 2000 10:22:20 PST
From: Larry Wall <larry@wall.org>
To: tchrist@chthon.perl.com (Tom Christiansen)
cc: Larry Wall <larry@wall.org>, larry@kiev.wall.org (Larry Wall),
gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen), tchrist@chthon.perl.com
Subject: Re: binmode without binmode?
Tom Christiansen writes:
: Some of these look like smilocons:
:
: open PIPE, "|-:text", "lpr fred -";
:
: Hm... I just noticed that it looks like we'll have to check whether
: there's just one argument, and if so, still break things up, and
: maybe use the shell. Right now, you can do this:
:
: open PIPE, "|-", "cat -n /etc/motd - 2>/dev/null";
: print PIPE "done\n";
: close PIPE;
:
: That's back to the awkwardness of system/exec needing
:
: system { $args[0] } @args;
:
: to guarantee the shell won't be called when @args == 1.
If you wanted a total hack, we could always do one like the split(/re/) hack
does to the /re/, and make
open PIPE, "|-", exec "cat -n /etc/motd - 2>/dev/null";
do the Right Thing, for some vague definition of right. But that's
pretty darn ugly.
Larry
>>> todo:11497
Delivery-Date: Sat Feb 26 10:38:24 2000
Message-Id: <200002261838.KAA26605@maul.activestate.com>
Date: Sat, 26 Feb 2000 10:38:23 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen)
Subject: Re: binmode without binmode?
On Sat, 26 Feb 2000 10:00:23 PST, Larry Wall wrote:
>Gurusamy Sarathy writes:
>: >The C<open> function associates an internal R<FILEHANDLE> with an
>: >external file specification given by R<EXPR>. It may be called with
>: >one, two, or three arguments.
>:
>: =for later
>: Or any number if we get our C<open PIPE, "-|", 'cat', '-n', 'file'>
>: act together.
>
>Can we at least put the 3rd argument into LIST context how so people
>don't get used to a scalarized 3rd arg? Or do we want 3rd arg scalar
>and then a LIST?
It's "F S? S?" currently. I'd go for "F S? L". >>TODO
>My other question is, how will we specify a path if it's different from
>first arg? Force them to fork and exec? Other options, none of them
>particularly appealing:
>
> open PIPE, "-|:path", '/usr/local/bin/cat', 'cat', '-n', 'file'>
> open PIPE, "-|{/usr/local/bin/cat}", 'cat', '-n', 'file'>
> open {"/usr/local/bin/cat"} PIPE, "-|", 'cat', '-n', 'file'>
There's of course this:
open PIPE, "-|" or exec { '/usr/local/bin/cat' } 'cat', '-n', 'file'
which works now.
Sarathy
gsar@ActiveState.com
>>> todo:11498
Delivery-Date: Sat Feb 26 10:43:51 2000
Message-Id: <200002261836.KAA28645@kiev.wall.org>
Date: Sat, 26 Feb 2000 10:36:42 PST
From: Larry Wall <larry@wall.org>
To: tchrist@chthon.perl.com (Tom Christiansen)
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen), tchrist@chthon.perl.com
Subject: Re: binmode without binmode?
Tom Christiansen writes:
: OR
:
: open PIPE, "-|", {"/usr/local/bin/cat"} => 'cat', '-n', 'file'
:
: or
: open PIPE, "-|", cat => {"/usr/local/bin/cat"}, '-n', 'file'
:
: Hm... that looks to be a lot more like some hulking initializer for
: some object out of a module somewhere, since the core hasn't really
: gone in for that kind of embellishment.
Well, I'm not into valueless anonymous hash composers, and we don't have
=> marking arguments as key/value pairs yet, but there's something to
be said for generalizing named parameters:
open [
HANDLE => *PIPE,
MODE => "-|",
CMD => [ "cat", '-n', 'file' ]
] or die;
That almost looks cool, if unworkable. But it does give me the idea
that we could have
open PIPE, "-|", ['cat', '-n', 'file']
since nobody in their right mind would open a reference, unless of course
Ilya installs open overloading.
Alternately, we might consider []-ifying the MODE.
Larry
>>> todo:11499
Delivery-Date: Sat Feb 26 10:46:37 2000
Message-Id: <200002261846.KAA26631@maul.activestate.com>
Date: Sat, 26 Feb 2000 10:46:35 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Tom Christiansen <tchrist@chthon.perl.com>
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy)
Subject: Re: binmode without binmode?
On Sat, 26 Feb 2000 11:08:44 MST, Tom Christiansen wrote:
>>My other question is, how will we specify a path if it's different from
>>first arg? Force them to fork and exec? Other options, none of them
>>particularly appealing:
>
>> open PIPE, "-|:path", '/usr/local/bin/cat', 'cat', '-n', 'file'>
>> open PIPE, "-|{/usr/local/bin/cat}", 'cat', '-n', 'file'>
>> open {"/usr/local/bin/cat"} PIPE, "-|", 'cat', '-n', 'file'>
>
>OR
>
> open PIPE, "-|", {"/usr/local/bin/cat"} => 'cat', '-n', 'file'
>
>or
> open PIPE, "-|", cat => {"/usr/local/bin/cat"}, '-n', 'file'
Actually, if we had to do this, I'd probably pick:
open PIPE, "{/usr/local/bin/cat} |", 'cat', '-n', 'file'
because it neatly replaces the '-', which we say stands for the
program to be executed.
Sarathy
gsar@ActiveState.com
>>> todo:11500
Replied: Sat, 26 Feb 2000 10:57:01 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: tchrist@chthon.perl.com (Tom Christiansen)
Delivery-Date: Sat Feb 26 10:48:11 2000
Message-Id: <200002261844.KAA28730@kiev.wall.org>
Date: Sat, 26 Feb 2000 10:44:48 PST
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen)
Subject: Re: binmode without binmode?
Gurusamy Sarathy writes:
: >My other question is, how will we specify a path if it's different from
: >first arg? Force them to fork and exec? Other options, none of them
: >particularly appealing:
: >
: > open PIPE, "-|:path", '/usr/local/bin/cat', 'cat', '-n', 'file'>
: > open PIPE, "-|{/usr/local/bin/cat}", 'cat', '-n', 'file'>
: > open {"/usr/local/bin/cat"} PIPE, "-|", 'cat', '-n', 'file'>
:
: There's of course this:
:
: open PIPE, "-|" or exec { '/usr/local/bin/cat' } 'cat', '-n', 'file'
:
: which works now.
That's what I meant by "Force them to fork and exec". I suppose we can
leave it at that for now.
But we might consider supporting:
exec [@cmd];
system [@cmd];
readpipe [@cmd];
open PIPE, "-|", [@cmd];
for unambiguous non-shell-invokingness. In which case we could support
open PIPE, "-|", $path, [@cmd];
or some such down the road.
Larry
>>> todo:11501
Delivery-Date: Sat Feb 26 10:57:03 2000
Message-Id: <200002261857.KAA26674@maul.activestate.com>
Date: Sat, 26 Feb 2000 10:57:01 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy),
tchrist@chthon.perl.com (Tom Christiansen)
Subject: Re: binmode without binmode?
On Sat, 26 Feb 2000 10:44:48 PST, Larry Wall wrote:
>That's what I meant by "Force them to fork and exec". I suppose we can
>leave it at that for now.
Yeah, this seems to fall in the "hard things possible" category.
>But we might consider supporting:
>
> exec [@cmd];
> system [@cmd];
> readpipe [@cmd];
> open PIPE, "-|", [@cmd];
>
>for unambiguous non-shell-invokingness. In which case we could support
>
> open PIPE, "-|", $path, [@cmd];
>
>or some such down the road.
Yup.
Sarathy
gsar@ActiveState.com
>>> todo:11502
Delivery-Date: Sat Feb 26 11:53:54 2000
Message-Id: <20725.951594622@chthon>
Date: Sat, 26 Feb 2000 12:50:22 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: tchrist@chthon.perl.com (Tom Christiansen),
gsar@ActiveState.com (Gurusamy Sarathy), tchrist@chthon.perl.com
Subject: Re: binmode without binmode?
>That almost looks cool, if unworkable. But it does give me the idea
>that we could have
> open PIPE, "-|", ['cat', '-n', 'file']
>since nobody in their right mind would open a reference, unless of course
>Ilya installs open overloading.
Actually, I had an example I deleted that read:
open PIPE, "-|", sub { while (1) { print ++$i, "\n" };
open PIPE, "-|", sub { exec qw/cat -n file/ };
--tom
>>> todo:11504
Delivery-Date: Sat Feb 26 13:02:05 2000
Message-Id: <4656.951598720@chthon>
Date: Sat, 26 Feb 2000 13:58:40 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: Larry Wall <larry@wall.org>
Subject: Re: binmode without binmode?
>There's of course this:
>
open PIPE, "-|" or exec { '/usr/local/bin/cat' } 'cat', '-n', 'file'
> which works now.
Things that work now have serious advantages over those that work
later. :-)
That kind of example always makes me nervous, though, for two reasons.
The first is pure superstition: I'm always afraid of `No more processes'.
This "can't happen", because Perl always retries all forms except
those from the Perl fork() function itself, including this one. (Yes,
I just tested this. :-)
The second, however, is real. If you don't have a real /usr/local/bin/cat
there, you just ended up with two processes running in the same code
where you never wanted them to. Watch:
print "parent $$\n";
open(FH, "|-") or exec xzyyz"
print "who am i: $$\n";
(In recent perls with your nice buffer-flushing fix,) that prints out:
parent 14500
who am i: 14500
who am i: 24664
Because the failed exec *fell through*. Oh glorp. We see this
in many examples in manpages and books. Happens all time.
You have to always write an extra or die there, something like:
print "parent $$\n";
open(FH, "|-") or exec "xzyyz"
or die "oh shucks, $! in $$";
print "who am i: $$\n";
Which produces much better behavior:
parent 11852
who am i: 11852
oh shucks, No such file or directory in 5350 at - line 3.
--tom
>>> todo:11505
Delivery-Date: Sat Feb 26 13:13:54 2000
Message-Id: <200002262110.NAA29916@kiev.wall.org>
Date: Sat, 26 Feb 2000 13:10:35 PST
From: Larry Wall <larry@wall.org>
To: tchrist@chthon.perl.com (Tom Christiansen)
cc: gsar@ActiveState.com (Gurusamy Sarathy), Larry Wall <larry@wall.org>
Subject: Re: binmode without binmode?
Tom Christiansen writes:
: Because the failed exec *fell through*. Oh glorp. We see this
: in many examples in manpages and books. Happens all time.
:
: You have to always write an extra or die there, something like:
:
: print "parent $$\n";
: open(FH, "|-") or exec "xzyyz"
: or die "oh shucks, $! in $$";
: print "who am i: $$\n";
:
: Which produces much better behavior:
:
: parent 11852
: who am i: 11852
: oh shucks, No such file or directory in 5350 at - line 3.
I've currently got:
The following piped opens are roughly equivalent:
open FH, "| tr 'a-z' 'A-Z'"; # to shell command
open FH, "|-", 'tr', 'a-z', 'A-Z'; # to bare command
open FH, "|-" or exec 'tr', 'a-z', 'A-Z' or die; # to child
as are these:
open FH, "cat -n 'file' |"; # from shell command
open FH, "-|", 'cat', '-n', 'file'; # from bare command
open FH, "-|" or exec 'cat', '-n', 'file' or die; # from child
(You'll note I'm documenting open FILEHANDLE, MODE, LIST as a fate accomply.)
Larry
>>> todo:11665
Delivery-Date: Tue Feb 29 10:34:28 2000
Message-Id: <24424.951849062@chthon>
Date: Tue, 29 Feb 2000 11:31:02 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>, gsar@chthon.perl.com
cc: camel@ora.com
Subject: disciplining the undisciplined
If you binmode(FH, "<:snickersnack") or open(FH, "<:flubber", $path),
will you take an exception for trying to use unknown disciplines?
I switched args 2 and 3 on open the other day. Sometimes I wish
thrinary open would have been :-)
open(FH, $path, "create exclusive writeonly")
--tom
>>> todo:11667
Delivery-Date: Tue Feb 29 10:39:55 2000
Message-Id: <200002291834.KAA05235@kiev.wall.org>
Date: Tue, 29 Feb 2000 10:34:56 PST
From: Larry Wall <larry@wall.org>
To: tchrist@chthon.perl.com (Tom Christiansen)
cc: Larry Wall <larry@wall.org>, gsar@chthon.perl.com, camel@ora.com
Subject: Re: disciplining the undisciplined
Tom Christiansen writes:
: If you binmode(FH, "<:snickersnack") or open(FH, "<:flubber", $path),
: will you take an exception for trying to use unknown disciplines?
I had decided that that was too exceptional to merit $@. If we're lucky,
most people won't know which disciplines they're using most of the time.
: I switched args 2 and 3 on open the other day. Sometimes I wish
: thrinary open would have been :-)
:
: open(FH, $path, "create exclusive writeonly")
Blurch. Where would that leave multiarg, er, multi-arg open?
Larry
>>> todo:11668
Delivery-Date: Tue Feb 29 10:43:52 2000
Message-Id: <14210.951849625@chthon>
Date: Tue, 29 Feb 2000 11:40:25 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: Larry Wall <larry@wall.org>
cc: tchrist@chthon.perl.com (Tom Christiansen), gsar@chthon.perl.com,
camel@ora.com, tchrist@chthon.perl.com
Subject: Re: disciplining the undisciplined
>: open(FH, $path, "create exclusive writeonly")
>Blurch. Where would that leave multiarg, er, multi-arg open?
Oh, I know. Hence the smiley. I think I was forgetting which
function I was calling. ENOSLEEP
--tom
>>> todo:14014
Replied: Mon, 17 Apr 2000 22:20:07 -0700
Replied: gsar@activestate.com
Replied: Larry Wall <larry@wall.org>
Replied: camel@ora.com
Replied: larry@kiev.wall.org
Delivery-Date: Mon Apr 17 20:40:28 2000
Message-Id: <200004180340.UAA19594@kiev.wall.org>
Date: Mon, 17 Apr 2000 20:40:28 PDT
From: Larry Wall <larry@wall.org>
To: camel@ora.com
cc: gsar@activestate.com, larry@kiev.wall.org
Subject: delegated opens
Because we can now have opens with three or more arguments, when we delegate
an open to a subroutine and expect to pass similar arguments, we have to
say something resembling this:
sub TIEHANDLE {
my $class = shift;
my $form = shift;
open my $self, $form, @_ or croak "can't open $form @_: $!";
return bless $self, $class;
}
This is because the prototype for CORE::open is ($$@).
By the way, $form is sort of a pun. It's short for "filename or mode".
Larry
>>> todo:14018
Delivery-Date: Mon Apr 17 22:20:09 2000
Message-Id: <200004180520.WAA11318@maul.ActiveState.com>
Date: Mon, 17 Apr 2000 22:20:07 PDT
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: camel@ora.com, gsar@ActiveState.com, larry@kiev.wall.org
Subject: Re: delegated opens
On Mon, 17 Apr 2000 20:40:28 PDT, Larry Wall wrote:
>Because we can now have opens with three or more arguments, when we delegate
>an open to a subroutine and expect to pass similar arguments, we have to
>say something resembling this:
>
> sub TIEHANDLE {
> my $class = shift;
> my $form = shift;
> open my $self, $form, @_ or croak "can't open $form @_: $!";
> return bless $self, $class;
> }
>
>This is because the prototype for CORE::open is ($$@).
Actually, "F S? L" or (*;$@).
I considered making it (*@) but chickened out at the end when I was faced
with open(X, something_with_wantarray_in_it()). IIRC, it was either this
or some other similar thing that also "broke" one of the overload tests.
Sarathy
gsar@ActiveState.com
>>> todo:14019
Replied: Mon, 17 Apr 2000 22:35:45 -0700
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: camel@ora.com
Replied: larry@kiev.wall.org
Delivery-Date: Mon Apr 17 22:27:10 2000
Message-Id: <200004180525.WAA20394@kiev.wall.org>
Date: Mon, 17 Apr 2000 22:25:42 PDT
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: Larry Wall <larry@wall.org>, camel@ora.com, gsar@ActiveState.com,
larry@kiev.wall.org
Subject: Re: delegated opens
Gurusamy Sarathy writes:
: Actually, "F S? L" or (*;$@).
Er, yeah, that's what I meant. :-)
: I considered making it (*@) but chickened out at the end when I was faced
: with open(X, something_with_wantarray_in_it()). IIRC, it was either this
: or some other similar thing that also "broke" one of the overload tests.
Someday we need to make &CORE::open(@_) et al do the right thing.
^
Larry
>>> todo:14021
Delivery-Date: Mon Apr 17 22:35:46 2000
Message-Id: <200004180535.WAA11360@maul.ActiveState.com>
Date: Mon, 17 Apr 2000 22:35:45 PDT
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy), camel@ora.com,
larry@kiev.wall.org
Subject: Re: delegated opens
On Mon, 17 Apr 2000 22:25:42 PDT, Larry Wall wrote:
>Someday we need to make &CORE::open(@_) et al do the right thing.
> ^
What I was thinking too. We may have to introduce a new opcode to
postpone the argument checking to run time (since many ops assume
they're getting exactly what they expect on the stack). Looks
doable.
Sarathy
gsar@ActiveState.com
>>> todo:14029
Replied: Tue, 18 Apr 2000 19:45:55 -0700
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: camel@ora.com
Replied: larry@kiev.wall.org
Delivery-Date: Tue Apr 18 08:02:17 2000
Message-Id: <200004181500.IAA25519@kiev.wall.org>
Date: Tue, 18 Apr 2000 08:00:48 PDT
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: Larry Wall <larry@wall.org>, gsar@ActiveState.com (Gurusamy Sarathy),
camel@ora.com, larry@kiev.wall.org
Subject: Re: delegated opens
Gurusamy Sarathy writes:
: On Mon, 17 Apr 2000 22:25:42 PDT, Larry Wall wrote:
: >Someday we need to make &CORE::open(@_) et al do the right thing.
: > ^
:
: What I was thinking too. We may have to introduce a new opcode to
: postpone the argument checking to run time (since many ops assume
: they're getting exactly what they expect on the stack). Looks
: doable.
I don't see why. &CORE::open(@_) should already know how to postpone
argument checking. It's just there's no subroutine definition there
to handle the subroutine call.
Larry
>>> todo:14068
Delivery-Date: Tue Apr 18 19:45:59 2000
Message-Id: <200004190245.TAA14589@maul.ActiveState.com>
Date: Tue, 18 Apr 2000 19:45:52 PDT
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy), camel@ora.com,
larry@kiev.wall.org
Subject: Re: delegated opens
On Tue, 18 Apr 2000 08:00:48 PDT, Larry Wall wrote:
>Gurusamy Sarathy writes:
>: What I was thinking too. We may have to introduce a new opcode to
>: postpone the argument checking to run time (since many ops assume
>: they're getting exactly what they expect on the stack). Looks
>: doable.
>
>I don't see why. &CORE::open(@_) should already know how to postpone
>argument checking. It's just there's no subroutine definition there
>to handle the subroutine call.
Doh. I didn't even try it.
% perl -we 'sub CORE::open { "@_\n" } print &CORE::open(1,2,3)'
1 2 3
CORE.pm, anyone?
Sarathy
gsar@ActiveState.com
>>> todo:12691
Replied: Thu, 16 Mar 2000 08:53:35 -0800
Replied: tchrist@perl.com
Replied: gsar@chthon.perl.com
Replied: camel@ora.com
Delivery-Date: Thu Mar 16 05:33:40 2000
Reply-to: tchrist@perl.com
Message-Id: <8325.953213615@chthon>
Date: Thu, 16 Mar 2000 06:33:35 MST
From: Tom Christiansen <tchrist@chthon.perl.com>
To: gsar@chthon.perl.com
cc: camel@ora.com
Subject: :def
You wrote:
In future, any default disciplines declared by this pragma will be
available by the special discipline name ":def", and could be used
within handle constructors that allow disciplines to be specified.
This would make it possible to stack new disciplines over the default
ones.
open FH, "<:para :def", $file or die "can't open $file: $!";
What do you think of :DEF instead? The all-caps thing stands out
more as some special metadiscipline. But perhaps it risks confusion
with :DEFAULTS.
--tom
>>> todo:12706
Delivery-Date: Thu Mar 16 08:54:13 2000
Message-Id: <200003161653.IAA20864@maul.ActiveState.com>
Date: Thu, 16 Mar 2000 08:53:34 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: tchrist@perl.com
cc: gsar@chthon.perl.com, camel@ora.com
Subject: Re: :def
On Thu, 16 Mar 2000 06:33:35 MST, Tom Christiansen wrote:
>You wrote:
> open FH, "<:para :def", $file or die "can't open $file: $!";
>
>What do you think of :DEF instead?
:def is what Larry had, but the allcaps thing might be better.
Sarathy
gsar@ActiveState.com
>>> todo:12711
Replied: Thu, 16 Mar 2000 10:29:08 -0800
Replied: gsar@ActiveState.com (Gurusamy Sarathy)
Replied: Larry Wall <larry@wall.org>
Replied: tchrist@perl.com
Replied: gsar@chthon.perl.com
Replied: camel@ora.com
Delivery-Date: Thu Mar 16 09:36:17 2000
Message-Id: <200003161732.JAA13120@kiev.wall.org>
Date: Thu, 16 Mar 2000 09:32:23 PST
From: Larry Wall <larry@wall.org>
To: gsar@ActiveState.com (Gurusamy Sarathy)
cc: tchrist@perl.com, gsar@chthon.perl.com, camel@ora.com
Subject: Re: :def
Gurusamy Sarathy writes:
: On Thu, 16 Mar 2000 06:33:35 MST, Tom Christiansen wrote:
: >You wrote:
: > open FH, "<:para :def", $file or die "can't open $file: $!";
: >
: >What do you think of :DEF instead?
:
: :def is what Larry had, but the allcaps thing might be better.
Then there's:
open FH, "<:para :_", $file or die "can't open $file: $!";
:-), or should that be :_)
Actaully, I'm not really liking either :def or :DEF, because I keep
reading them as "define" rather than "default". But then, I suppose
there will be someone who reads :para as parasite or paramour or paraguay.
Anyway, either :DEF or :DEFAULT is okay by me.
Larry
>>> todo:12720
Delivery-Date: Thu Mar 16 10:29:09 2000
Message-Id: <200003161829.KAA21417@maul.ActiveState.com>
Date: Thu, 16 Mar 2000 10:29:08 PST
From: Gurusamy Sarathy <gsar@ActiveState.com>
To: Larry Wall <larry@wall.org>
cc: gsar@ActiveState.com (Gurusamy Sarathy), tchrist@perl.com,
gsar@chthon.perl.com, camel@ora.com
Subject: Re: :def
On Thu, 16 Mar 2000 09:32:23 PST, Larry Wall wrote:
>Anyway, either :DEF or :DEFAULT is okay by me.
I like :DEFAULT.
Sarathy
gsar@ActiveState.com
Thread Previous
|
Thread Next