Re: perl and line endings...

On 2008-10-17, at 02:41, Smylers wrote: It may be wrong, but Perl behaves consistently with its being true, and believing it avoids the surprise that the original hater encountered. So long as you only ever use Perl. The original ASCII spec was that a new line should be specified either by

Re: [offlist] Re: perl and line endings...

* Smylers [2008-10-17 13:35]: > > Did I miss something? > > No, just that I when I read it, so I thought I'd highlight > it and perhaps make a few other people as well. > > Cheers. Hehe. By itself that would have worked, it’s just in combination with the “totally wrong” quibble that it into p

[offlist] Re: perl and line endings...

> > (Is being "actually totally wrong" different from just being > > "wrong"?) > > Yes: what you wrote was wrong on multiple levels and did not > incorporate any individually correct statements. OK, fair enough! > > > It's a very misconception, though, > > > > Yes. It's very. > > The missing

Re: perl and line endings...

* Smylers [2008-10-17 09:50]: > Aristotle Pagaltzis writes: > > That's actually totally wrong! > > (Is being "actually totally wrong" different from just being > "wrong"?) Yes: what you wrote was wrong on multiple levels and did not incorporate any individually correct statements. > > It's a ve

Re: perl and line endings...

Aristotle Pagaltzis writes: > * Smylers [2008-10-10 19:40]: > > > \n denotes a 'new line', a virtual concept which is made up of some > > concept of some combination of line feeds (\x0A) and carriage > > returns, in an attempt to cope with the hateful different ways OSes > > have denoted line br

Re: [offlist] Re: perl and line endings...

Hi Aaron, * Aaron Crane [2008-10-14 00:20]: > I’m curious to know if there’s a reason you export an empty > `LC_ALL` rather than unsetting it. if there is, I don’t remember. I think it might have been that I wasn’t sure how unsetting variables interplays with exporting them vs. not. It did what

[offlist] Re: perl and line endings...

Aristotle Pagaltzis writes: * Aaron Crane [2008-10-11 00:10]: > $ echo z | env LANG=en_GB.utf-8 grep '[A-Z]' > z Which is why my `.profile` says this: export LC_ALL= export LANG=en_US.utf8 export LC_COLLATE=C export LC_CTYPE=de_DE.utf8 Same here, modulo language pref

Re: perl and line endings...

Juerd Waalboer wrote: > Michael G Schwern skribis 2008-10-11 9:58 (-0400): >>> So you really believe there's still at least one EBCDIC perl user out there? >> Frighteningly enough, yes. Some guys at IBM in China. >> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-11/msg00265.html >> h

Re: perl and line endings...

Michael G Schwern skribis 2008-10-11 9:58 (-0400): > > So you really believe there's still at least one EBCDIC perl user out there? > Frighteningly enough, yes. Some guys at IBM in China. > http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-11/msg00265.html > http://www.xray.mpe.mpg.de/m

Re: perl and line endings...

* Joshua Juran [2008-10-11 21:15]: > On Oct 11, 2008, at 6:15 AM, Aristotle Pagaltzis wrote: >> But `\n` always means *exactly one character* which on ASCII >> systems is always `\x0a`. > > [citation needed] > > #!/usr/bin/perl > > foreach ( @ARGV ) > { > s{ [\] n }{ \r }gx; > >

Re: perl and line endings...

On Oct 11, 2008, at 6:15 AM, Aristotle Pagaltzis wrote: * Smylers [2008-10-10 19:40]: Which characters? The representation \r denotes a carriage return, aka character \x0D. Whereas \n denotes a 'new line', a virtual concept which is made up of some concept of some combination of line feeds (

Re: perl and line endings...

Juerd Waalboer wrote: > Abigail skribis 2008-10-10 22:07 (+0200): >> On Fri, Oct 10, 2008 at 09:23:26PM +0200, Juerd Waalboer wrote: >>> Joshua Juran skribis 2008-10-10 11:32 (-0700): Constructions like [A-Za-z] are non-portable to EBCDIC, since the alphabetic code points are non-contig

Re: perl and line endings...

On 2008-10-11, at 04:02, Roger Burton West wrote: If you want to be sloppy about case in your directory listings, fine. Breaking a shell script that wants to look at files [A-Z]* but not [a-z]* is going a bit far. Ja. I have often thought that it was hatefully stupid to make the traditional U

Re: perl and line endings...

* Aristotle Pagaltzis [2008-10-11 15:20]: > (I realise I didn't explicitly hate on anything, but if you > don't think the above conglomerate isn't hateful, I can't help > you.) Also, wetware that can't properly parse or formulate stacked negations is hateful, but that's off-topic. Regards, -- A

Re: perl and line endings...

* Aaron Crane [2008-10-11 00:10]: > $ echo z | env LANG=en_GB.utf-8 grep '[A-Z]' > z Which is why my `.profile` says this: export LC_ALL= export LANG=en_US.utf8 export LC_COLLATE=C export LC_CTYPE=de_DE.utf8 Please note particularly unbreak-me line #3. Regards, -- Ari

Re: perl and line endings...

* Smylers [2008-10-10 19:40]: > Which characters? The representation \r denotes a carriage > return, aka character \x0D. > > Whereas \n denotes a 'new line', a virtual concept which is > made up of some concept of some combination of line feeds > (\x0A) and carriage returns, in an attempt to cop

Re: perl and line endings...

On Fri, Oct 10, 2008 at 11:01:21PM +0100, Aaron Crane wrote: > $ echo z | env LANG=en_GB.utf-8 grep '[A-Z]' > z Yes. If you want to be sloppy about case in your directory listings, fine. Breaking a shell script that wants to look at files [A-Z]* but not [a-z]* is going a bit far.

Re: perl and line endings...

On 2008-10-10 at 21:37 -0500, Peter da Silva wrote: > On 2008-10-10, at 13:32, Joshua Juran wrote: > > At least Mac OS 9 is ASCII. > > I don't recall seeing a [apple] symbol in ASCII. *sigh* I can see the Unicode vendor mapping in ROMAN.TXT maps 0xF0 to U+F8FF and I know that's in the Private Us

Re: perl and line endings...

Apropos of nothing, I just got a spam for auto insurance and read the subject line as "insurance hates". Yes, I thought, I hate it back.

Re: perl and line endings...

On 2008-10-10, at 13:32, Joshua Juran wrote: At least Mac OS 9 is ASCII. I don't recall seeing a  symbol in ASCII.

Re: perl and line endings...

> > Constructions like [A-Za-z] are non-portable to EBCDIC, since the > alphabetic code points are non-contiguous. As someone already pointed out, not true when talking about Perl: both the regex character ranges and the tr operator were surgically altered to run for the hills^Wpresidency of Un

Re: perl and line endings...

Joshua Juran writes: > Constructions like [A-Za-z] are non-portable to EBCDIC, since the > alphabetic code points are non-contiguous. They're also, astonishingly enough, non-portable to POSIXish systems with ASCII-compatible character sets: $ echo z | env LANG=en_GB.iso-8859-1 grep '[A-Z]' $

Re: perl and line endings...

Abigail skribis 2008-10-10 22:20 (+0200): > > > I'm sure there's at least one hacker who hates perl for exactly that > > > reason. > > So you really believe there's still at least one EBCDIC perl user out there? > That would assume everyone who hates a piece of software also (still) > uses that so

Re: perl and line endings...

Abigail skribis 2008-10-10 22:07 (+0200): > On Fri, Oct 10, 2008 at 09:23:26PM +0200, Juerd Waalboer wrote: > > Joshua Juran skribis 2008-10-10 11:32 (-0700): > > > Constructions like [A-Za-z] are non-portable to EBCDIC, since the > > > alphabetic code points are non-contiguous. > > Well, that's

Re: perl and line endings...

On Fri, Oct 10, 2008 at 10:14:40PM +0200, Juerd Waalboer wrote: > Abigail skribis 2008-10-10 22:07 (+0200): > > On Fri, Oct 10, 2008 at 09:23:26PM +0200, Juerd Waalboer wrote: > > > Joshua Juran skribis 2008-10-10 11:32 (-0700): > > > > Constructions like [A-Za-z] are non-portable to EBCDIC, since

Re: perl and line endings...

On Fri, Oct 10, 2008 at 09:23:26PM +0200, Juerd Waalboer wrote: > Joshua Juran skribis 2008-10-10 11:32 (-0700): > > Constructions like [A-Za-z] are non-portable to EBCDIC, since the > > alphabetic code points are non-contiguous. > > Well, that's not true for perl of course, which tries to be sm

Re: perl and line endings...

On Oct 10, 2008, at 12:37 PM, Earle Martin wrote: 2008/10/10 Joshua Juran At least Mac OS 9 is ASCII. DON'T CROSS THE STREAMS! Oops, I forgot to add "*ducks*" to the end. :-) Josh

Re: perl and line endings...

2008/10/10 Joshua Juran > At least Mac OS 9 is ASCII. > DON'T CROSS THE STREAMS! -- うつつにひとめ 見しごとはあらず Earle Martin | http://downlode.org/

Re: perl and line endings...

Joshua Juran skribis 2008-10-10 11:32 (-0700): > Constructions like [A-Za-z] are non-portable to EBCDIC, since the > alphabetic code points are non-contiguous. Well, that's not true for perl of course, which tries to be smart and has special cased simple letter ranges. -- Met vriendelijke groet

Re: perl and line endings...

On Oct 10, 2008, at 11:25 AM, Nicholas Clark wrote: On Fri, Oct 10, 2008 at 06:31:41PM +0100, Smylers wrote: It isn't possible to have an 'actual' \n character; all actual characters will be specific, not conceptual. EBCDIC has a "new line" control character distinct from both line feed an

Re: perl and line endings...

On Fri, Oct 10, 2008 at 06:31:41PM +0100, Smylers wrote: > It isn't possible to have an 'actual' \n character; all actual > characters will be specific, not conceptual. EBCDIC has a "new line" control character distinct from both line feed and carriage return. So I'd argue that your statement onl

Re: perl and line endings...

Darrell Fuhriman writes: > Should getting the actual characters be treated differently from > getting the \r\n representation of those characters? Which characters? The representation \r denotes a carriage return, aka character \x0D. Whereas \n denotes a 'new line', a virtual concept which is m

Re: perl and line endings...

* b...@cpan.org [2008-10-09 00:00]: > Now, of course we hate Perl. We just do it in private. ;-) Nah, it's more like marriage. Regards, -- Aristotle Pagaltzis //

Re: perl and line endings...

Joshua Juran wrote: > On Oct 8, 2008, at 2:55 PM, b...@cpan.org wrote: > >> On Wed, Oct 08, 2008 at 03:18:41PM -0400, Michael G Schwern wrote: >>> That's all perl. :) >>> >>> No, it's all you big guy. >>> >>> PEBKAC. >>> >> >> Ah ah. I wonder what percentage of the subscribers of hates-softw

Re: perl and line endings...

On Oct 8, 2008, at 2:55 PM, b...@cpan.org wrote: On Wed, Oct 08, 2008 at 03:18:41PM -0400, Michael G Schwern wrote: That's all perl. :) No, it's all you big guy. PEBKAC. Ah ah. I wonder what percentage of the subscribers of hates- software are actually Perl programmers. A good chunk

Re: perl and line endings...

On Wed, Oct 08, 2008 at 03:18:41PM -0400, Michael G Schwern wrote: > > > That's all perl. :) > > No, it's all you big guy. > > PEBKAC. > Ah ah. I wonder what percentage of the subscribers of hates-software are actually Perl programmers. A good chunk of the posters are, for sure. Now, of cour

Re: perl and line endings...

Darrell Fuhriman wrote: >> So you've mainly abandoned Perl for Ruby but you decided to pop a shot >> at Perl anyway - and it turned out to be Ruby's fault? :) > > Well, it's partially my fault for not checking my quoting (hardly unique > to ruby). But why should "actual-carriage-return{1}actual-ne

Re: perl and line endings...

So you've mainly abandoned Perl for Ruby but you decided to pop a shot at Perl anyway - and it turned out to be Ruby's fault? :) Well, it's partially my fault for not checking my quoting (hardly unique to ruby). But why should "actual-carriage-return{1}actual- newline{1}" work differently fr

Re: perl and line endings...

On 8 Oct 2008, at 18:43, Darrell Fuhriman wrote: Urrrggh... the problem seems to be coming up because I'm calling it as a rake task. Rake was converting the \r\n to actual carriage return+newline in the call to the shell. So you've mainly abandoned Perl for Ruby but you decided to pop a sho

Re: perl and line endings...

Is that different from what you observed? If so which version of Perl are you using? Urrrggh... the problem seems to be coming up because I'm calling it as a rake task. Rake was converting the \r\n to actual carriage return +newline in the call to the shell. ie: perl -i.bak -ne 's/ date

Re: perl and line endings...

On 8 Oct 2008, at 17:29, Darrell Fuhriman wrote: You *remove* all \r\n, replacing it with nothing Yes, which is what I wanted. What I didn't want is to remove all solitary \n, which is what it did. If I were to have used s/af//, I would not expect it to convert 'wtf' to 'w', but that's

Re: perl and line endings...

You *remove* all \r\n, replacing it with nothing Yes, which is what I wanted. What I didn't want is to remove all solitary \n, which is what it did. If I were to have used s/af//, I would not expect it to convert 'wtf' to 'w', but that's the equivalent of what it did. Darrell

Re: perl and line endings...

On Wed, 8 Oct 2008 08:52:40 -0700, Darrell Fuhriman wrote: > > I know, hating perl -- fish in a barrel. I've been doing a lot more > stuff in ruby lately, but I still like perl for a few things. In this > case, I had a file which had some spurious carriage returns, which I > needed to rem

perl and line endings...

I know, hating perl -- fish in a barrel. I've been doing a lot more stuff in ruby lately, but I still like perl for a few things. In this case, I had a file which had some spurious carriage returns, which I needed to remove so postgres wouldn't complain about them. As it happens, the car