Bug #89069 for P: newlines sensitive to $\

Mon Sep 30 10:52:29 2013 zefram [...] fysh.org - Ticket created

Subject:	newlines sensitive to $\
Date:	Mon, 30 Sep 2013 15:52:10 +0100
To:	bug-P [...] rt.cpan.org
From:	Zefram <zefram [...] fysh.org>

The output that P generates to a filehandle depends on $\: $ perl -lwe 'use P; P "foo"' | od -tc 0000000 f o o \n \n 0000005 $ perl -we 'use P; P "foo"' | od -tc 0000000 f o o \n 0000004 This is unlike the builtin say, which provides exactly one newline regardless of $\: $ perl -lwE 'say "foo"' | od -tc 0000000 f o o \n 0000004 $ perl -wE 'say "foo"' | od -tc 0000000 f o o \n 0000004 P thus fails in its objective of automatically providing sensible newline behaviour. -zefram

Mon Oct 28 05:25:34 2013 pause [...] tlinx.org - Correspondence added

On Mon Sep 30 10:52:29 2013, zefram@fysh.org wrote: Show quoted text

> The output that P generates to a filehandle depends on $\: > > $ perl -lwe 'use P; P "foo"' | od -tc > 0000000 f o o \n \n > 0000005 > $ perl -we 'use P; P "foo"' | od -tc > 0000000 f o o \n > 0000004 > > This is unlike the builtin say, which provides exactly one newline > regardless of $\: > > $ perl -lwE 'say "foo"' | od -tc > 0000000 f o o \n > 0000004 > $ perl -wE 'say "foo"' | od -tc > 0000000 f o o \n > 0000004 > > P thus fails in its objective of automatically providing sensible > newline behaviour. > > -zefram

----- I /could/ disagree insomuch that it was modeled on printf/sprintf. I don't use 'say'. printf behaves the same way (assuming you add a \n at the end of a statement going to output): perl -lwe 'print "foo\n"'|od -tc 0000000 f o o \n \n 0000005 Ishtar:law/bin> perl -we 'print "foo\n"'|od -tc 0000000 f o o \n 0000004 --- In the "design goal" of being a replacement for print/printf/sprintf, I would call that a success, and while "winning" on adherence to design, at this point, I think I agree with you. I.e. if it is something that *can* be checked for and handled automatically, then why not? I see no benefit to it providing a duplicate \n like perl's standard print/printf would if they were generating their own newline. A fix for this is in the devel version. Thanks for bringing this to my attention. (like I said, I don't use 'say' and only rarely use the "-l" switch)... and this is what happens when you don't get out much! ;-)

Mon Oct 28 05:25:34 2013 The RT System itself - Status changed from 'new' to 'open'

Mon Oct 28 06:32:14 2013 zefram [...] fysh.org - Correspondence added

Subject:	Re: [rt.cpan.org #89069] newlines sensitive to $\
Date:	Mon, 28 Oct 2013 10:31:59 +0000
To:	Linda A Walsh via RT <bug-P [...] rt.cpan.org>
From:	Zefram <zefram [...] fysh.org>

Linda A Walsh via RT wrote: Show quoted text

>I /could/ disagree insomuch that it was modeled on printf/sprintf.

printf and sprintf *never* add a newline, regardless of $\. Show quoted text

>I don't use 'say'.

Indeed, it repeatedly comes up that you use P instead, apparently because it's meant to subsume say's main selling point, its newline behaviour. Show quoted text

>printf behaves the same way (assuming you add a \n at the end of a >statement going to output): > > perl -lwe 'print "foo\n"'|od -tc

Your statement here doesn't match the example code: it's print, not printf, that has the $\-sensitive behaviour. Show quoted text

>In the "design goal" of being a replacement for print/printf/sprintf, >I would call that a success,

I was responding to the statement in P's documentation: It saves on in that you don't have constantly insert or move newlines (\n). which sounds awfully like it's meant to have say-like newline behaviour when writing to a filehandle. -zefram

Mon Oct 28 12:14:50 2013 pause [...] tlinx.org - Correspondence added

It may sound that way, but it started as a replacement for printf, then added sprintf. I filed a bug in the past about how printf and sprintf couldn't use the same parameters (an array with the format in the 1st element -- printf handles it, sprintf will choke). Anything on top of that was added for convenience. But hey, I already said I agreed w/ya and the fix was in...so isn't this a bit like a moot point?

Tue Nov 05 23:28:28 2013 pause [...] tlinx.org - Taken

Tue Nov 05 23:30:07 2013 pause [...] tlinx.org - Status changed from 'open' to 'resolved'

Tue Nov 05 23:30:08 2013 pause [...] tlinx.org - Severity Normal added