[31324] in Perl-Users-Digest
Perl-Users Digest, Issue: 2569 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 24 18:09:40 2009
Date: Mon, 24 Aug 2009 15:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 24 Aug 2009 Volume: 11 Number: 2569
Today's topics:
Another way of resizing an Image? <graham.stow@stowassocs.co.uk>
Re: Another way of resizing an Image? <rvtol+usenet@xs4all.nl>
Re: Another way of resizing an Image? <tadmc@seesig.invalid>
learn what is FOREX <onlyarsalan4u@gmail.com>
Re: log timestamp a script is used <gerhard_ulrike@yahoo.de>
Re: log timestamp a script is used <jurgenex@hotmail.com>
Re: log timestamp a script is used (Tim McDaniel)
Re: Possibly useful perl script to filter lines in one <jurgenex@hotmail.com>
Re: Possibly useful perl script to filter lines in one <tadmc@seesig.invalid>
Re: Possibly useful perl script to filter lines in one <nat.k@gm.ml>
Re: Preventing lines from printing (Tim McDaniel)
Re: Preventing lines from printing <uri@StemSystems.com>
Re: Preventing lines from printing (Tim McDaniel)
Re: Preventing lines from printing <uri@StemSystems.com>
Re: Preventing lines from printing (Tim McDaniel)
Re: Preventing lines from printing <uri@StemSystems.com>
Re: Printing only on a match (Jens Thoms Toerring)
Re: Printing only on a match <dear.race@luukku.com>
Re: Printing only on a match <bart.lateur@pandora.be>
Re: Printing only on a match <jurgenex@hotmail.com>
Re: windows one liner to output unix line feed <thepoet_nospam@arcor.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 24 Aug 2009 17:37:12 +0100
From: "Graham" <graham.stow@stowassocs.co.uk>
Subject: Another way of resizing an Image?
Message-Id: <7PidnVpVIfQgXA_XnZ2dnUVZ8iOdnZ2d@bt.com>
I need to write thumbnail images via a Perl script running on an ISP's
webserver. I've got no problem writing the script. However, the ISP isn't
keen to enhance his Perl 5 installation by installing the Image::Resize
module (or any CPAN module come to that). I'd change ISP but I haven't got
the time (the script must be up and running in 48 hours).
Can anyone suggest a workaround?
------------------------------
Date: Mon, 24 Aug 2009 19:30:23 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Another way of resizing an Image?
Message-Id: <4a92ce2f$0$191$e4fe514c@news.xs4all.nl>
Graham wrote:
> I need to write thumbnail images via a Perl script running on an ISP's
> webserver. I've got no problem writing the script. However, the ISP isn't
> keen to enhance his Perl 5 installation by installing the Image::Resize
> module (or any CPAN module come to that). I'd change ISP but I haven't got
> the time (the script must be up and running in 48 hours).
>
> Can anyone suggest a workaround?
Call a binary executable, often there is some tool with that
functionality available. Even PHP would do. :)
Though Image::Resize uses GD, so first try `perldoc GD`.
--
Ruud
------------------------------
Date: Mon, 24 Aug 2009 12:45:51 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Another way of resizing an Image?
Message-Id: <slrnh95js9.l78.tadmc@tadmc30.sbcglobal.net>
Graham <graham.stow@stowassocs.co.uk> wrote:
> the ISP isn't
> keen to enhance his Perl 5 installation by installing the Image::Resize
> module (or any CPAN module come to that).
> Can anyone suggest a workaround?
Install the module yourself.
perldoc -q module
How do I keep my own module/library directory?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 24 Aug 2009 09:10:50 -0700 (PDT)
From: arsalan <onlyarsalan4u@gmail.com>
Subject: learn what is FOREX
Message-Id: <9ac4a027-c1ed-4ece-af5f-deb25b9037c0@d9g2000prh.googlegroups.com>
http://www.forexluxury.blogspot.com/
investment management firms (who typically manage large accounts on
behalf of customers such as pension funds and endowments) use the
foreign exchange market to facilitate transactions in foreign
securities. For example, an investment manager bearing an
international equity portfolio needs to purchase and sell several
pairs of foreign currencies to pay for foreign securities purchases.
For more details........
http://www.forexluxury.blogspot.com/
------------------------------
Date: Mon, 24 Aug 2009 05:56:56 -0700 (PDT)
From: Gerhard <gerhard_ulrike@yahoo.de>
Subject: Re: log timestamp a script is used
Message-Id: <21f8f3fb-a8e7-4ee0-b12a-67313a1e2743@w6g2000yqw.googlegroups.com>
Thanks,
your first solution is very easy to use and does what i want it to
do.
I've wrote a simple Package:
"
system "echo $0 `date` >>/tmp/Scripts_used.lst";
1;
"
set the environment and have restartet my job-scheduler (to have the
correct
environment).
That's all and it works fine. I'll get my logs and can count the
numbers each
script is used.
THX
Gerhard
------------------------------
Date: Mon, 24 Aug 2009 06:14:47 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: log timestamp a script is used
Message-Id: <v94595pjt7anitu990qekgfmiig6jia1sv@4ax.com>
Gerhard <gerhard_ulrike@yahoo.de> wrote:
>I've wrote a simple Package:
>"
>system "echo $0 `date` >>/tmp/Scripts_used.lst";
>1;
>"
To avoid the overhead of forking of a new process just to get the date
you could have used localtime():
system ("echo $0 ". localtime) >>/tmp/Scripts_used.lst";
>That's all and it works fine.
But if it works fine then that's all that matters.
jue
------------------------------
Date: Mon, 24 Aug 2009 15:36:12 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: log timestamp a script is used
Message-Id: <h6uc1c$7qb$2@reader1.panix.com>
In article <v94595pjt7anitu990qekgfmiig6jia1sv@4ax.com>,
Jürgen Exner <jurgenex@hotmail.com> wrote:
>Gerhard <gerhard_ulrike@yahoo.de> wrote:
>>I've wrote a simple Package:
>>"
>>system "echo $0 `date` >>/tmp/Scripts_used.lst";
>>1;
>>"
>
>To avoid the overhead of forking of a new process just to get the
>date you could have used localtime():
>
> system ("echo $0 ". localtime) >>/tmp/Scripts_used.lst";
Well, you can avoid processes entirely by opening
/tmp/Scripts_used.lst in Perl with '>>' mode, and printing $0 and
localtime to it.
>But if it works fine then that's all that matters.
Yeah. And if this is, for example, running only several times a day,
the overhead is negligable. All too often, micro-optimization
takes macro-effort to produce micro-results.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 24 Aug 2009 05:48:55 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <bu2595hlt0dlnc2a38mm658hh7dol0rsv7@4ax.com>
Nathan Keel <nat.k@gm.ml> wrote:
>sln@netherlands.com wrote:
>
>>
>> In reality, you should never need to check the return value from
>> open(). If you can't program to that spec, you haven't been paid to
>> program. -sln
>
>To say one should never need to check the return value (rather than
>arguing about die'ing), just shows how unqualified you are as an
>alleged programmer. No one is suggesting to not check other things,
>but checking that a file opened is sometimes useful or needed. If you
>don't recognize or admit that, then you are a complete failure at
>simple programming logic.
Took you a surprisingly long tme to recognize that. Everyone else has
filtered Mr. Sln aka Robic0 a loooooong time ago.
jue
------------------------------
Date: Mon, 24 Aug 2009 10:17:04 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <slrnh95b5a.jpc.tadmc@tadmc30.sbcglobal.net>
sln@netherlands.com <sln@netherlands.com> wrote:
> In reality, you should never need to check the return value from open().
Bullshit.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 24 Aug 2009 09:33:13 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Possibly useful perl script to filter lines in one file out of another.
Message-Id: <ahzkm.116606$O23.18934@newsfe11.iad>
Jürgen Exner wrote:
> Took you a surprisingly long tme to recognize that. Everyone else has
> filtered Mr. Sln aka Robic0 a loooooong time ago.
>
> jue
No, I've always realized it, but I don't filter people out. I'm able to
just ignore them when I want. I usually ignore him anymore.
------------------------------
Date: Mon, 24 Aug 2009 15:33:01 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Preventing lines from printing
Message-Id: <h6ubrd$7qb$1@reader1.panix.com>
In article <87ocq5zvhu.fsf@quad.sysarch.com>,
Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
>
> TM> In article <87ocq61b6b.fsf@quad.sysarch.com>,
> TM> Uri Guttman <uri@StemSystems.com> wrote:
> >>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
> >>
> TM> #! /usr/bin/perl -wan
> TM> BEGIN { $sum = 0; $count = 0; }
> >>
> >> no need to initialize those to 0 as += won't warn when adding to
> >> undef. same is true for ++ and .= .
>
> TM> I like explicit initialization to the correct value, even if
> TM> the default works the same way. I don't like touching undef
> TM> (except with defined, which doesn't really touch it), even in
> TM> contexts where it works.
>
>do you also assign hash/array refs before you add things to them? the
>above is the same thing, autovivification. this saves lots of dumb
>boring newbie code that does it like other langs, check if
>initialized to something and if not initialize, then mung it.
If I omit initialization, it might be because I'm happy with the
default, but alternately, it may be that I've forgotten a necessary
assignment, and it's all too easy to just forget something entirely.
Doing an initialization answers the question (leaving open the
question of whether it's *correct*, of course).
It adds hardly any extra semantic or visual clutter to have
initializations like
my $running_total = 0;
my @bug_numbers = ();
especially because it's already standard to have other assignments
doing things like
my $use_bash = 1;
my @final_states = ('RESOLVED', 'VERIFIED', 'CLOSED');
I had seen the term "autovivification", but never really thought about
it. Now that you mention it, something like
if (! exists $dependencies{$_}) {
$dependencies{$_} = [];
}
push @{$dependencies{$_}}, $bug_number;
*does* add semantic and visual clutter, and a non-trivial chance of
buggy initialization. I think I'll use autovivification in the
future -- though maybe with a comment that I'm using it?
Thank you for the prompting. I write Perl code for me and don't
generally see other people's Perl code, so I don't have the chance to
pick up idioms by osmosis.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 24 Aug 2009 11:55:45 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Preventing lines from printing
Message-Id: <87zl9pw6im.fsf@quad.sysarch.com>
>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
TM> In article <87ocq5zvhu.fsf@quad.sysarch.com>,
TM> Uri Guttman <uri@StemSystems.com> wrote:
>>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
>>
TM> In article <87ocq61b6b.fsf@quad.sysarch.com>,
TM> Uri Guttman <uri@StemSystems.com> wrote:
>> >>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
>> >>
TM> #! /usr/bin/perl -wan
TM> BEGIN { $sum = 0; $count = 0; }
>> >>
>> >> no need to initialize those to 0 as += won't warn when adding to
>> >> undef. same is true for ++ and .= .
>>
TM> I like explicit initialization to the correct value, even if
TM> the default works the same way. I don't like touching undef
TM> (except with defined, which doesn't really touch it), even in
TM> contexts where it works.
too much explicit stuff leads to noisy code. knowing that my vars will
be undef by default and will work nicely (under warnings) with some key
ops is intermediate level perl and should be assumed by any decent perl
hacker. it is no different when you use a counter in a hash element
and ++ it without first setting it to 0.
TM> It adds hardly any extra semantic or visual clutter to have
TM> initializations like
TM> my $running_total = 0;
TM> my @bug_numbers = ();
but it does if you do this:
$count{foo} = 0 unless exists $count{foo} ;
$count{foo}++
TM> especially because it's already standard to have other assignments
TM> doing things like
TM> my $use_bash = 1;
TM> my @final_states = ('RESOLVED', 'VERIFIED', 'CLOSED');
i am only talking about coercion of undef to 0 or '' in cases where it
works. as i said this is true for scalars OR hash/array
elements. consistant style is important too.
TM> I had seen the term "autovivification", but never really thought about
TM> it. Now that you mention it, something like
TM> if (! exists $dependencies{$_}) {
TM> $dependencies{$_} = [];
no need for the exists test as the array ref is always true. this means
you could simplify this to:
$dependencies{$_} ||= [];
but as i said, even that is not needed with autovivification.
TM> }
TM> push @{$dependencies{$_}}, $bug_number;
TM> *does* add semantic and visual clutter, and a non-trivial chance of
TM> buggy initialization. I think I'll use autovivification in the
TM> future -- though maybe with a comment that I'm using it?
see my article on autoviv:
http://sysarch.com/Perl/autoviv.txt
no comment should be used. if you know about autoviv your code readers
should know about it too.
TM> Thank you for the prompting. I write Perl code for me and don't
TM> generally see other people's Perl code, so I don't have the chance to
TM> pick up idioms by osmosis.
you IS other people. one thing i always teach is that code is for
people, not for computers.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 24 Aug 2009 16:49:30 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Preventing lines from printing
Message-Id: <h6ugaq$ftp$1@reader1.panix.com>
In article <87zl9pw6im.fsf@quad.sysarch.com>,
Uri Guttman <uri@StemSystems.com> wrote:
>if you know about autoviv your code readers should know about it too.
There's no way you can make that generalization. Example: you and me!
You knew about it perfectly well, and I didn't.
For another example, the cow-orker who is most likely to have to pick
up my work doesn't like Perl, with the usual complaints that it's line
noise, it's opaque, et cetera. It is dangerous for me to depend on
subtle features.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 24 Aug 2009 13:36:04 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Preventing lines from printing
Message-Id: <87r5v1unaz.fsf@quad.sysarch.com>
>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
TM> In article <87zl9pw6im.fsf@quad.sysarch.com>,
TM> Uri Guttman <uri@StemSystems.com> wrote:
>> if you know about autoviv your code readers should know about it too.
TM> There's no way you can make that generalization. Example: you and me!
TM> You knew about it perfectly well, and I didn't.
TM> For another example, the cow-orker who is most likely to have to pick
TM> up my work doesn't like Perl, with the usual complaints that it's line
TM> noise, it's opaque, et cetera. It is dangerous for me to depend on
TM> subtle features.
then you will never improve your perl from kiddie levels. yours is a
common and falacious argument to never use 'advanced' features in any
language. those features are there for a reason. yes, you can enforce a
level of features to code but setting that at the right level is also a
skill to be learned. map/grep confound newbies all the time but are
considered standard ops for mid-level hackers. same for
autivivification. i don't use some bleading edge wierd things myself and
even some simple ones like format (which is never used by experts it
seems and only newbies! there are much better cpan modules for that
anyhow). so you do have to decide who your audience is and code to that
level. i just say mid to high-level is a good target as long as the code
is clean and clear. eschewing common ops from your target is limiting
your coding ability and looking down at your readers.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 24 Aug 2009 21:04:08 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Preventing lines from printing
Message-Id: <h6uv88$kun$1@reader1.panix.com>
In article <87r5v1unaz.fsf@quad.sysarch.com>,
Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
>
> TM> In article <87zl9pw6im.fsf@quad.sysarch.com>,
> TM> Uri Guttman <uri@StemSystems.com> wrote:
> >> if you know about autoviv your code readers should know about it
> >> too.
>
> TM> There's no way you can make that generalization. Example: you
> TM> and me! You knew about it perfectly well, and I didn't.
>
> TM> For another example, the cow-orker who is most likely to have
> TM> to pick up my work doesn't like Perl, with the usual complaints
> TM> that it's line noise, it's opaque, et cetera. It is dangerous
> TM> for me to depend on subtle features.
>
>then you will never improve your perl from kiddie levels. yours is a
>common and falacious argument to never use 'advanced' features in any
>language.
If you want to come by my office and try to train my technical lead in
Perl advanced features that are not obvious, please try. I suspect
he'll stop wanting to listen fairly quickly regardless of what you say
about Perl. It's not a fallacious argument in my environment -- it is
a constraint that I should worry about.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 24 Aug 2009 17:18:23 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Preventing lines from printing
Message-Id: <87hbvwud0g.fsf@quad.sysarch.com>
>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
TM> If you want to come by my office and try to train my technical lead in
TM> Perl advanced features that are not obvious, please try. I suspect
TM> he'll stop wanting to listen fairly quickly regardless of what you say
TM> about Perl. It's not a fallacious argument in my environment -- it is
TM> a constraint that I should worry about.
i am willing to do so if he is willing to pay for it. :)
if you really have such a low level audience then you can code for it. i
did say that but doing so is bad for you and them. you two won't be the
only people ever reading this code. and remember, code is for people,
not computers!
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: 24 Aug 2009 11:09:55 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: Printing only on a match
Message-Id: <7ffao3F2kot9hU1@mid.uni-berlin.de>
Diamond, Mark <dot@dot.dot> wrote:
> This post is prompted by having my earlier mistake ("Preventing lines from
> printing 23/8/09) pointed out to me. My problem is now one of elegance
> rather than failure.
> I have
> while (<>) {
> .
> .
> ($angle, $stage)= /^(\d\d)(\d+)/;
> print "$angle $stage\n";
> .
> .
> }
> which prints something whether there is a match or not. I assume that I can
> avoid the printing when there is no match by comparing $angle and $stage
> with null strings,
i guess you meant by checking if they are defined.
> but please, what is the/a sensible/elegant way of
> printing on a complete match and not printing on no match or only a partial
> match?
The simplest way might be
while (<>) {
print "$1 $2\n" if /^(\d{2})(\d+)/;
}
Don't know if it sensible/elegant enough for your eyes;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Mon, 24 Aug 2009 11:48:19 GMT
From: dee <dear.race@luukku.com>
Subject: Re: Printing only on a match
Message-Id: <1251114499.455055@vanews01>
Diamond, Mark wrote:
> I have
>
> while (<>) {
> .
> .
> ($angle, $stage)= /^(\d\d)(\d+)/;
> print "$angle $stage\n";
> .
> .
> }
>
> which prints something whether there is a match or not. I assume that I can
> avoid the printing when there is no match by comparing $angle and $stage
> with null strings, but please, what is the/a sensible/elegant way of
> printing on a complete match and not printing on no match or only a partial
> match?
Often, but not always, a sensible way is to add "or next":
while (<>) {
.
.
($angle, $stage)= /^(\d\d)(\d+)/ or next;
print "$angle $stage\n";
.
.
}
This doesn't work outside of a loop, but these situations very typically
appear in loops, so I use it often.
------------------------------
Date: Mon, 24 Aug 2009 14:17:02 +0200
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Printing only on a match
Message-Id: <s21595d6dcqaps1a16cifaere7jk6o0al8@4ax.com>
dee wrote:
>Often, but not always, a sensible way is to add "or next":
>
>while (<>) {
>.
>.
> ($angle, $stage)= /^(\d\d)(\d+)/ or next;
> print "$angle $stage\n";
>.
>.
>}
>
>This doesn't work outside of a loop, but these situations very typically
>appear in loops, so I use it often.
For the general case, you can use the slightly more verbose:
if( my($angle, $stage)= /^(\d\d)(\d+)/ ) {
print "$angle $stage\n";
}
--
Bart.
------------------------------
Date: Mon, 24 Aug 2009 05:54:42 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Printing only on a match
Message-Id: <q935951b4l89rqjmu945n7h1uhdf5ap51m@4ax.com>
"Diamond, Mark" <dot@dot.dot> wrote:
>This post is prompted by having my earlier mistake ("Preventing lines from
>printing 23/8/09) pointed out to me. My problem is now one of elegance
>rather than failure.
>
>I have
>
>while (<>) {
>.
>.
> ($angle, $stage)= /^(\d\d)(\d+)/;
> print "$angle $stage\n";
>.
>.
>}
>
>which prints something whether there is a match or not. I assume that I can
>avoid the printing when there is no match by comparing $angle and $stage
>with null strings, but please, what is the/a sensible/elegant way of
>printing on a complete match and not printing on no match or only a partial
>match?
Per idiom for that kind of task:
print "$angle $stage\n" if ($angle, $stage)= /^(\d\d)(\d+)/;
jue
------------------------------
Date: Mon, 24 Aug 2009 21:34:45 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: windows one liner to output unix line feed
Message-Id: <4a92eb45$0$30222$9b4e6d93@newsspool1.arcor-online.net>
sln@netherlands.com schrieb:
> In addition, I was giving examples suggesting that Perl did nothing wrong,
> even if the filehandle (apparently not) is not open for binary output.
> The suggestion is that the device could be reacting (normally) to embedded
> CR's from a cross-platform, or who knows, some binary interaction, by the
> user.
You gave examples of something that no relevance at all to the
questions at hand and did useless abstractions in almost-gibberish.
> Or his device is in a mode that translates control characters differently.
"His device" is a regular file on a Windows box, and unless you
have a crystal ball that has you know the unknowable, that's a
premise for the question.
> Obviously, the way to debug is to inspect the file, inspect the device mode,
> then make a determination. The way NOT to debug, is suspecting Perl a culprit
> in something that would have showed up hundreds of thousands of times before
> this.
There is no 'device' (in the sense commonly adopted in Perl as a device
driver interface) involved, and there also wasn't any console involved
in the OPs question. So your reasoning makes absolutely no sense.
Furthermore, you suggest some abstract digging around instead of asking
the apparent question, namely:
would a standardised Perl installation, its binary executed with
standard parameters and often used code, change line end characters
in a regular textfile with unix line endings _on its own accord_.
The answer is yes, and as mostly, it is in the docs and has nothing to
do with consoles or devices. And it has shown up quite often, though
nowadays tutorials and books tend to include information on win32
and the :crlf layer (at least rudimentary ones).
And as I pointed out, albeit the mechanism and ways to turn it off
are documenten, they are not consistent when the inline switch is used.
> But, apparently, to get the newbies all rieled up on a wild goose chase,
> that is seemingly whats happening.
You jumped on that train quite willingly yourself.
-Chris
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2569
***************************************
