Well,
(binmode() revisited ;-)
This is exactly why I needed to change the binmode() routine in the first
place......
(binmode v 5.6+ allows for several line disciplines, current: :crlf or :binary
according to doc's)
why not implement it this ways....
Have binmode sort out how to (re)open the MBX links, possibly add a (few) line
disciplines....
An MBX opened with "ctx=bin", is a transparent pipeline afaik, that's why I
needed to change the binmode
routine anyway, to allow for UNIX semantics using an MBX. It also is the way a
very good VMS web server
(WASD) creates it's mailboxes, to allow normal CGI script processing (including
file uploads etc.) without
too much trouble.
At writing of the perl script it IS known against what we will talk..., VMS
semantics or UNIX
semantics...
binmode SHOULD be safe as it's a no-op for non record oriented OS'es, and a new
line discipline is now possible
line :vms-stream, or :vms-record, etc. etc.
This would also remove the need for special-case processing against own
children.., they should just add the
correct binmodes before data is transferred.
I Hope it Helps,
regards,
Nico Baggus
> -----Original Message-----
> From: Dan Sugalski <[EMAIL PROTECTED]>
> Sent: Monday, April 30, 2001 11:36
> To: [EMAIL PROTECTED] (Charles Lane)
> Cc: [EMAIL PROTECTED]
> Subject: Re: pipe buffers and other unpleasant subjects
>
>
> At 09:40 AM 4/30/2001 -0400, Charles Lane wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> writes:
> > > At 09:24 AM 4/30/2001 -0400, [EMAIL PROTECTED] wrote:
> > > >"Craig A. Berry" <[EMAIL PROTECTED]> writes:
> > >> > I think this is a reproducer for the problem that occasionally
> > >> > inserts spurious carriage returns into what should be
> one line of
> > >> > output in the test suite. It appears to be a function
> of pipe buffer
> > >> > size. If the mailbox buffer for a pipe fills up,
> reading EOF from
> > >> > the pipe causes a carriage return to get inserted in
> the stream.
> > > >
> > > >Well, much of this is from the interaction between the CRTL and
> > > >mailboxes. There's a limit to what we can do to wedge
> our fixes in
> > > >between those two. There's a definite limit to what I'm
> willing to do
> > > >to rewrite the CRTL i/o library.
> >
> > > Would it be better, then, to drop to $QIO calls for this
> then? We could
> > > wedge that in reasonably easily, as we do have a goodly
> amount of control
> > > at this level.
> >
> >Yes, we'd want to use $QIO's...but that alone won't help much. My
> >example again:
> >
> >CHILD.COM:
> >
> > $ write sys$output "this is a test"
> > $ perl -e "print qq(a test\nreally\n);" ! q or qq?
> I can never
> > recall
> >
> >The DCL write just puts "this is a test" in the mailbox, no
> \n to strip.
> >But when the parent reads from the mailbox, I think you'll
> agree that adding
> >a \n before handing it to Perl is in order.
>
> Maybe. I do hate treating an I/O channel as both record and stream
> oriented. Bleah.
>
> >Should the Perl print strip the trailing \n or not before it
> goes in the
> >mailbox? Well, yes, if it will go through the same
> interpretation at the
> >parent as the DCL write does. And the parent has no clue
> which bit of
> >data comes from which source.
>
> I'd argue that perl should actually split the data on
> whatever's in PL_ors
> and post it to the mailbox piece by piece that way, but that
> still has the
> problem of sending arbitrary streams of unstructured data
> down a stream
> that wants structured data.
>
> Dan
>
> --------------------------------------"it's like
> this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
>
>
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
