[30447] in Perl-Users-Digest
Perl-Users Digest, Issue: 1690 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jul 4 18:09:48 2008
Date: Fri, 4 Jul 2008 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 Fri, 4 Jul 2008 Volume: 11 Number: 1690
Today's topics:
Re: comp.lang.perl.misc pollution sln@netherlands.com
Re: FAQ 8.28 How can I call backticks without shell pro <uri@stemsystems.com>
Re: FAQ 8.28 How can I call backticks without shell pro <szrRE@szromanMO.comVE>
Re: FAQ 8.28 How can I call backticks without shell pro <uri@stemsystems.com>
Re: Formatting ASCII to be read by Windows NotePad <bill@ts1000.us>
Re: Formatting ASCII to be read by Windows NotePad <spamtrap@dot-app.org>
Re: Formatting ASCII to be read by Windows NotePad <wgumgfy@gmail.com>
Re: Formatting ASCII to be read by Windows NotePad <spamtrap@dot-app.org>
Re: Formatting ASCII to be read by Windows NotePad <wgumgfy@gmail.com>
Re: Formatting ASCII to be read by Windows NotePad <spamtrap@dot-app.org>
Re: Formatting ASCII to be read by Windows NotePad <wgumgfy@gmail.com>
Re: Formatting ASCII to be read by Windows NotePad <spamtrap@dot-app.org>
Re: Unwanted output using croak with eval andrew@ugh.net.au
Windows Perl/Tk Sirius App <s1037989@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 04 Jul 2008 17:42:15 GMT
From: sln@netherlands.com
Subject: Re: comp.lang.perl.misc pollution
Message-Id: <okns64lkj476qhqj5j0sc8aq4gn0hd3fdd@4ax.com>
On Thu, 3 Jul 2008 21:57:25 -0700, Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
>On 2008-07-03, sln@netherlands.com <sln@netherlands.com> wrote:
>>
>> Free Agent is good if you can still find it.
>
>How is Free Agent, anyway? I heard it's good if you can get it.
>
>I like slrn; easily available for un*x (including OS X); can probably
>get it as part of Cygwin for Windows too.
>
>--keith
I never used Free Agent. Had always had the full Agent.
Agent went from 1,2,3 and now 4. I stopped at 2 (32 bit) for windows.
It has all I need for Usenet (don't use it for email). It will handle
bulk very nicely and don't need image viewers nor html processing.
Does yenc and uue very nicely for attachments. Posting is a breaze.
Many filters, configurations, setup options... lots of tools, etc.
I think version 4 has all the bells and whistles, including multiple
server/identities.
As far as I know, its still 29 dollars US. Its by far the most complete
solution for nntp under windows. Just google Forte Agent. "Free Agent"
was a version 1 product I think, but there is a version 4 shareware I
think.
Some links:
http://www.sharewarejunkies.com/07zwd04/forte_agent.htm
http://www.forteinc.com/agent/index.php
http://www.forteinc.com/main/homepage.php
http://www.tucows.com/preview/195240
------------------------------
Date: Fri, 04 Jul 2008 16:38:34 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: FAQ 8.28 How can I call backticks without shell processing?
Message-Id: <x78wwh4nat.fsf@mail.sysarch.com>
>>>>> "s" == szr <szrRE@szromanMO.comVE> writes:
s> Uri Guttman wrote:
>>>>>>> "s" == szr <szrRE@szromanMO.comVE> writes:
>> perl -e '@e = qw( a b c ); open( $e, "-|", 'echo', @e ); print <$e>'
>> a b c
>>
>> echo printed its args with spaces as expected so it got 3 separate
>> args and not 'abc' as you claim it would.
s> Curious, I thought the behavior would be like:
s> $ perl -e '@e = qw( a b c ); print @e'
s> which yields 'abc', as I saw that after the first three arguement of the
s> normal 3 arg open() it appeared to take a list of additional args that
s> is passes to what ever you opened. I didn't know it separates them like
s> it does. Good to know.
you don't get what is happening there. perl is printing each element and
there is no separator so it appears you are concatenating. when you exec
with a list each argument is separated in the same way and it depends on
the exec'ed program how they will be used. echo puts spaces between them
which is why i chose that for the one liner. i could have used perl
again and it would not have put spaces in unless i made it do so (as
with "@e").
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 4 Jul 2008 11:55:46 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: FAQ 8.28 How can I call backticks without shell processing?
Message-Id: <g4lrnj01jfn@news4.newsguy.com>
Uri Guttman wrote:
>>>>>> "s" == szr <szrRE@szromanMO.comVE> writes:
>
> s> Uri Guttman wrote:
> >>>>>>> "s" == szr <szrRE@szromanMO.comVE> writes:
>
> >> perl -e '@e = qw( a b c ); open( $e, "-|", 'echo', @e ); print
> >> <$e>'
> >> a b c
I think you meant to have "echo" not 'echo', although the result, i
nthis case, is the same.
> >> echo printed its args with spaces as expected so it got 3 separate
> >> args and not 'abc' as you claim it would.
>
> s> Curious, I thought the behavior would be like:
> s> $ perl -e '@e = qw( a b c ); print @e'
> s> which yields 'abc', as I saw that after the first three arguement
> of the s> normal 3 arg open() it appeared to take a list of
> additional args that s> is passes to what ever you opened. I didn't
> know it separates them like s> it does. Good to know.
>
> you don't get what is happening there. perl is printing each element
> and there is no separator so it appears you are concatenating. when
> you exec with a list each argument is separated in the same way and
> it depends on the exec'ed program how they will be used. echo puts
> spaces between them which is why i chose that for the one liner. i
> could have used perl
> again and it would not have put spaces in unless i made it do so (as
> with "@e").
Seem you are correct:
opentest.pl:
1 #!/usr/bin/perl -w
2
3 use strict;
4
5 print join(',', @ARGV), "\n";
6
$ perl -e '@e = qw(a b c); open( $e, "-|", "./opentest.pl", @e );
print <$e>'
a,b,c
It's good to know. I've been using Perl for years but I never found a
situation where I needed to use open() like that, although I should of
known it would behave like system() - each element in the array gets
passed as a separate argument to the program.
Thanks :-)
--
szr
------------------------------
Date: Fri, 04 Jul 2008 21:21:53 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: FAQ 8.28 How can I call backticks without shell processing?
Message-Id: <x7hcb51h1p.fsf@mail.sysarch.com>
>>>>> "s" == szr <szrRE@szromanMO.comVE> writes:
s> Uri Guttman wrote:
>>>>>>> "s" == szr <szrRE@szromanMO.comVE> writes:
>>
s> Uri Guttman wrote:
>> >>>>>>> "s" == szr <szrRE@szromanMO.comVE> writes:
>>
>> >> perl -e '@e = qw( a b c ); open( $e, "-|", 'echo', @e ); print
>> >> <$e>'
>> >> a b c
s> I think you meant to have "echo" not 'echo', although the result, i
s> nthis case, is the same.
yes. it worked because of how shell quoting is done. that still was one
string passed to perl -e.
>> you don't get what is happening there. perl is printing each element
>> and there is no separator so it appears you are concatenating. when
>> you exec with a list each argument is separated in the same way and
>> it depends on the exec'ed program how they will be used. echo puts
>> spaces between them which is why i chose that for the one liner. i
>> could have used perl
>> again and it would not have put spaces in unless i made it do so (as
>> with "@e").
s> Seem you are correct:
s> opentest.pl:
s> 1 #!/usr/bin/perl -w
s> 2
s> 3 use strict;
s> 4
s> 5 print join(',', @ARGV), "\n";
s> 6
s> $ perl -e '@e = qw(a b c); open( $e, "-|", "./opentest.pl", @e );
s> print <$e>'
s> a,b,c
s> It's good to know. I've been using Perl for years but I never found a
s> situation where I needed to use open() like that, although I should of
s> known it would behave like system() - each element in the array gets
s> passed as a separate argument to the program.
they are all using the same internal call to exec which bypasses the
shell if there is a list. the exec kernel call only takes a list of args
anyhow so perl can call it directly if you let or force it. it is faster
and safer as you can't inject bogus shell code that may get executed.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 4 Jul 2008 08:45:12 -0700 (PDT)
From: Bill H <bill@ts1000.us>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <1884bd3e-496c-49c5-978b-d870fb9574e8@e39g2000hsf.googlegroups.com>
On Jul 4, 10:56=A0am, Sherman Pendley <spamt...@dot-app.org> wrote:
> "Waylen Gumbal" <wgum...@gmail.com> writes:
> > Sherman Pendley wrote:
> >> "Waylen Gumbal" <wgum...@gmail.com> writes:
>
> >> > Sherman Pendley wrote:
> >> > > UnRiel <bdwh...@gmail.com> writes:
>
> >> > > > I have a nice PERL script I use to generate CISCO configurations
>
> >> > > No need to shout - neither Perl nor Cisco are acronyms.
>
> >> > I don't think two all-caps words in a sentence that's otherwise
> >> > properly cased really constitutes shouting.
>
> >> It's shouting those words.
>
> > Not in that context it wasn't.
>
> You must be new to usenet. All caps is considered shouting here,
> unless that's the correct spelling of a word or acronym, and as I
> said, that applies to neither Perl nor Cisco.
>
> >> > > Transfer the files in text mode. That will translate the line
> >> > > endings as needed.
>
> >> > While it is common to use ASCII mode one should still take care, as
> >> > this isn't always guarenteed to work. There used (still are?) issues
> >> > with this when uploading to MacOS based servers, for example.
>
> >> Such as?
>
> > I've had issues in the past uploading to a MacOS based ftp server
> > (remember that Mac uses \r for line endings, where as Win32 uses \r\n,
> > and most Linux and Unix systems use \n)
>
> I've been using a Mac for ten years, and I wrote the readme.macosx
> that's included with Perl. So spare me the lectures.
>
> Yes, I do remember that MacOS once, many years ago when "classic"
> MacOS was relevant, used to use \r. Mac OS X uses \n, just like any
> other Unix, as documented here:
>
> <http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSyst...=
>
> <http://tinyurl.com/58w7dy>
>
> This ain't your grandpa's Mac any more. Try to keep up, OK?
>
> > and when uploading in "ASCII"
> > mode, the line endings became \n instead of \r (this happened with 3
> > different ftp clients, including the command line ftp client, so I
> > attribute the problem likely was the server wasn't properly telling the
> > client what sort of platform it was (what line endings it used.)
>
> You're beginning to try my patience. This is little more than "it
> didn't work." What *specific* server app were you connecting to? What
> client were you using? What version of both?
>
> Note that according to RFC 959, the client sends \r\n pairs in ASCII
> mode, which the server translates to its native format. Because a
> "neutral" format is used in transit, neither client nor server is
> aware, nor needs to be aware of the native format used by the other,
> by design. Your attribution of the problem, as you wrote it above,
> makes no sense.
>
> Do you have anything *useful* to say here? Do you actually understand
> the FTP protocol? Did you actually debug the problem you had? Or are
> you basically just saying "I had a problem in the past, and it must
> have been the Mac at the other end because Macs are weird"?
>
> sherm--
>
> --
> My blog:http://shermspace.blogspot.com
> Cocoa programming in Perl:http://camelbones.sourceforge.net- Hide quoted =
text -
>
> - Show quoted text -
I'll jump on the Mac ftp issue bandwagon and even make it pertain to
perl. I have a couple of clients using DreamWeaver in OS X that,
whether due to settings or the OS, when they post their webpages or
perl scripts to one of my linux servers they wind up with the "\r" in
the scripts and a blank line after every line in the html files. The
servers themselves don't care and it all works good, but if I then d/l
the files via ftp (ascii mode) to the pc the perl scripts loose all
line feeds (i have to open and save using edit.com to get them back)
and the extra blank lines in html stay are still there. Now one of
these same clients has used fetch (or the OS X equivalent) and this
problem went away, so it may be a Dreamweaver issue.
I also know, on a few of the Mac servers that I have had the "joy" of
moving websites off of, when d/ling the files via ftp, no setting
change (ascii or binary) will ever fix the lack of line feeds in the
files I receive from the Mac.
Bill H
------------------------------
Date: Fri, 04 Jul 2008 12:56:01 -0400
From: Sherman Pendley <spamtrap@dot-app.org>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <m14p75a8ri.fsf@dot-app.org>
Bill H <bill@ts1000.us> writes:
> On Jul 4, 10:56 am, Sherman Pendley <spamt...@dot-app.org> wrote:
>>
>> Yes, I do remember that MacOS once, many years ago when "classic"
>> MacOS was relevant, used to use \r. Mac OS X uses \n, just like any
>> other Unix, as documented here:
>>
>> <http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSyst...>
>> <http://tinyurl.com/58w7dy>
>
> I'll jump on the Mac ftp issue bandwagon and even make it pertain to
> perl. I have a couple of clients using DreamWeaver in OS X that,
> whether due to settings or the OS, when they post their webpages or
> perl scripts to one of my linux servers they wind up with the "\r" in
> the scripts and a blank line after every line in the html files.
Dreamweaver's default setting is incorrect for Mac OS X - it still
defaults to the old format with \r. Fortunately, a quick trip to its
preferences can fix that.
> Now one of
> these same clients has used fetch (or the OS X equivalent) and this
> problem went away, so it may be a Dreamweaver issue.
I think Transmit is a popular GUI FTP client; I use ncftp in a
terminal window myself. It sounds to me like Dreamweaver isn't using
ASCII mode transfers.
> I also know, on a few of the Mac servers that I have had the "joy" of
> moving websites off of, when d/ling the files via ftp, no setting
> change (ascii or binary) will ever fix the lack of line feeds in the
> files I receive from the Mac.
Were the files in the server's native format, using \n, to begin with?
If they weren't, I wouldn't expect a Mac or any other Unix server to
be able to do the translation. That's not a problem with Mac servers in
particular, it's just how ASCII transfers work in FTP; they're meant
to translate correctly-formatted files, not fix broken files.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Fri, 4 Jul 2008 11:44:18 -0700
From: "Waylen Gumbal" <wgumgfy@gmail.com>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <6d79c3F12ui5U1@mid.individual.net>
Sherman Pendley wrote:
> "Waylen Gumbal" <wgumgfy@gmail.com> writes:
> > Sherman Pendley wrote:
> > > "Waylen Gumbal" <wgumgfy@gmail.com> writes:
> > > > Sherman Pendley wrote:
> > > > > UnRiel <bdwhite@gmail.com> writes:
> > > > >
> > > > > > I have a nice PERL script I use to generate CISCO
> > > > > > configurations
> > > > >
> > > > > No need to shout - neither Perl nor Cisco are acronyms.
> > > >
> > > > I don't think two all-caps words in a sentence that's otherwise
> > > > properly cased really constitutes shouting.
> > >
> > > It's shouting those words.
> >
> > Not in that context it wasn't.
>
> You must be new to usenet. All caps is considered shouting here,
> unless that's the correct spelling of a word or acronym, and as I
> said, that applies to neither Perl nor Cisco.
I am not new to the usenet. Anyone who made it past the 4th grade can
see shouting wasn't his intention. Please stop pretending you didn't
know it wasn't his intention.
> > > > > Transfer the files in text mode. That will translate the line
> > > > > endings as needed.
> > > >
> > > > While it is common to use ASCII mode one should still take care,
> > > > as
> > > > this isn't always guarenteed to work. There used (still are?)
> > > > issues with this when uploading to MacOS based servers, for
> > > > example.
> > >
> > > Such as?
> >
> > I've had issues in the past uploading to a MacOS based ftp server
> > (remember that Mac uses \r for line endings, where as Win32 uses
> > \r\n, and most Linux and Unix systems use \n)
>
> Yes, I do remember that MacOS once, many years ago when "classic"
> MacOS was relevant, used to use \r. Mac OS X uses \n, just like any
> other Unix, as documented here:
That doesn't matter. It can be a client and/or server software issue.
> This ain't your grandpa's Mac any more. Try to keep up, OK?
Non sequitur. It's not so much the OS, but programs (client or server)
that are incorrectly configured. You can never take for granted that a
remote FTP server you are given to connect to will be setup right. Same
goes for the default settings of a given client.
> > and when uploading in "ASCII"
> > mode, the line endings became \n instead of \r (this happened with 3
> > different ftp clients, including the command line ftp client, so I
> > attribute the problem likely was the server wasn't properly telling
> > the client what sort of platform it was (what line endings it used.)
>
> Note that according to RFC 959, the client sends \r\n pairs in ASCII
> mode, which the server translates to its native format. Because a
> "neutral" format is used in transit, neither client nor server is
> aware, nor needs to be aware of the native format used by the other,
> by design. Your attribution of the problem, as you wrote it above,
> makes no sense.
Are you aware that not all software necessarily (properly) follows an
RFC that it should be following? You can never take for granted that any
piece of software you install will work perfectly. Checking in advance
helps, but there can always be suprises even reviewers can miss.
> Do you have anything *useful* to say here?
Are you going through some rough times? Else, why do you find it so
necessary to so unpleasant to others. I don't recall ever doing anything
cross towards you, so I don't know why you can't simply discuss things
in a calmer tone.
--
wg
------------------------------
Date: Fri, 04 Jul 2008 15:05:04 -0400
From: Sherman Pendley <spamtrap@dot-app.org>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <m1tzf55v33.fsf@dot-app.org>
"Waylen Gumbal" <wgumgfy@gmail.com> writes:
> Are you going through some rough times? Else, why do you find it so
> necessary to so unpleasant to others.
I find it necessary to correct nonsense when I see it, for the sake of
those who might otherwise be misled into believing it. If you find
that unpleasant, don't post nonsense.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Fri, 4 Jul 2008 12:55:14 -0700
From: "Waylen Gumbal" <wgumgfy@gmail.com>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <6d7dh4F18da9U1@mid.individual.net>
Sherman Pendley wrote:
> "Waylen Gumbal" <wgumgfy@gmail.com> writes:
>
> > Are you going through some rough times? Else, why do you find it so
> > necessary to so unpleasant to others.
>
> I find it necessary to correct nonsense when I see it, for the sake of
> those who might otherwise be misled into believing it. If you find
> that unpleasant, don't post nonsense.
I didn't post nonsense. Do you act this same way in real life too?
I'm obviously not the only to have run into such issues (regardless of
destination and source platforms), so I don't know where you get off
taking that stance.
--
wg
------------------------------
Date: Fri, 04 Jul 2008 16:21:38 -0400
From: Sherman Pendley <spamtrap@dot-app.org>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <m1y74hjt7x.fsf@dot-app.org>
"Waylen Gumbal" <wgumgfy@gmail.com> writes:
> Sherman Pendley wrote:
>> "Waylen Gumbal" <wgumgfy@gmail.com> writes:
>>
>> > Are you going through some rough times? Else, why do you find it so
>> > necessary to so unpleasant to others.
>>
>> I find it necessary to correct nonsense when I see it, for the sake of
>> those who might otherwise be misled into believing it. If you find
>> that unpleasant, don't post nonsense.
>
> I didn't post nonsense.
So where, exactly, did you post a specific problem with a specific
app, as opposed to vague hand-waving about an entire platform that you
obviously know very little about?
> Do you act this same way in real life too?
Life is no less real when you're typing to people than when you're
talking face to face with them. And yes, I call BS when and where I
see it, online or off. That does tend to upset people who continually
spout BS - but I couldn't care less about their opinions anyway, so
that's fine by me.
> I'm obviously not the only to have run into such issues (regardless of
> destination and source platforms), so I don't know where you get off
> taking that stance.
I'm taking it because I haven't yet seen an accurate description of
the problem you claim to have had. First you claim that a particular
OS may have problems, then when I asked for details you gave me a
bunch of hand-waving about an FTP server supposedly not informing the
client what it was, when in fact *no* FTP server does so for ASCII
transfers, nor needs to.
In this whole sorry thread, I've yet to see a single coherent, logical
description of the problem you supposedly had. Nor have I seen a bit
of evidence that you know anything about the FTP protocol. All I've
seen is a bunch of semi-religious FUD about how Macs "have problems"
with FTP.
You really should read this, if you intend to discuss technical issues
with adults:
<http://www.catb.org/~esr/faqs/smart-questions.html>
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Fri, 4 Jul 2008 13:32:48 -0700
From: "Waylen Gumbal" <wgumgfy@gmail.com>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <6d7fnhF18tpuU1@mid.individual.net>
Sherman Pendley wrote:
> "Waylen Gumbal" <wgumgfy@gmail.com> writes:
> > Sherman Pendley wrote:
> > > "Waylen Gumbal" <wgumgfy@gmail.com> writes:
> > >
> > > > Are you going through some rough times? Else, why do you find it
> > > > so
> > > > necessary to so unpleasant to others.
> > >
> > > I find it necessary to correct nonsense when I see it, for the
> > > sake
> > > of those who might otherwise be misled into believing it. If you
> > > find that unpleasant, don't post nonsense.
> >
> > I didn't post nonsense.
>
> So where, exactly, did you post a specific problem with a specific
> app, as opposed to vague hand-waving about an entire platform that you
> obviously know very little about?
I did post a specific problem; EOL translation between platforms, in the
realm of FTP, based on my own experience.
> > I'm obviously not the only to have run into such issues (regardless
> > of destination and source platforms), so I don't know where you get
> > off taking that stance.
>
> I'm taking it because I haven't yet seen an accurate description of
> the problem you claim to have had.
I was just tell of my own experience regarding EOL.
> First you claim that a particular OS may have problems,
I never made any such claim.
> then when I asked for details you gave me a bunch of hand-waving
> about an FTP server supposedly not informing the client what it was,
> when in fact *no* FTP server does so for ASCII transfers, nor needs
> to.
Because it was some time ago. I was just recalling an experience. Why do
you care so damn much anyways? Who asked you to be a lawyer?
> In this whole sorry thread, I've yet to see a single coherent, logical
> description of the problem you supposedly had. Nor have I seen a bit
> of evidence that you know anything about the FTP protocol.
I don't have to prove any thing. I know how FTP work and I know there
are many server and client implementations released over the years that
could misbehave when it comes to converting EOLs.
> You really should read this, if you intend to discuss technical issues
> with adults:
Maybe you should learn to act like an adult, instead of jumping all over
someone's back as if you're drug sniffing canine. There is no reason to
act this way, and in many people's eyes you come off as entirely
condescending. Please be civil of fsck off.
--
wg
------------------------------
Date: Fri, 04 Jul 2008 18:03:59 -0400
From: Sherman Pendley <spamtrap@dot-app.org>
Subject: Re: Formatting ASCII to be read by Windows NotePad
Message-Id: <m1lk0hb92o.fsf@dot-app.org>
"Waylen Gumbal" <wgumgfy@gmail.com> writes:
> Sherman Pendley wrote:
>>
>> First you claim that a particular OS may have problems,
>
> I never made any such claim.
Your own words, directly copied and pasted:
"While it is common to use ASCII mode one should still take care, as this
isn't always guarenteed to work. There used (still are?) issues with
this when uploading to MacOS based servers, for example."
>> then when I asked for details you gave me a bunch of hand-waving
>> about an FTP server supposedly not informing the client what it was,
>> when in fact *no* FTP server does so for ASCII transfers, nor needs
>> to.
>
> Because it was some time ago. I was just recalling an experience. Why do
> you care so damn much anyways? Who asked you to be a lawyer?
I care about accuracy in the technical fora in which I participate -
and I don't recall needing to be asked by you to care about it.
>> In this whole sorry thread, I've yet to see a single coherent, logical
>> description of the problem you supposedly had. Nor have I seen a bit
>> of evidence that you know anything about the FTP protocol.
>
> I don't have to prove any thing. I know how FTP work
Do you? Then why did you - again, your own words - "attribute the
problem likely was the server wasn't properly telling the client what
sort of platform it was"?
If you actually knew how FTP works, at the protocol level, you would
know that no server ever tells the client that. It doesn't need to -
both client and server transforms the text to and from its native
format to ASCII with \r\n for transport. Neither one needs to know or
care about the native format of the other.
> and I know there
> are many server and client implementations released over the years that
> could misbehave when it comes to converting EOLs.
I worked in web hosting for many years, and I've answered this and
similar questions literally hundreds of times. In every single case,
without exception, the answer was that the user was expecting ASCII
mode to handle translations that it isn't designed to handle.
For instance, if one uploads a file with \r in binary mode to a Unix
server, it's not in the server's native text format. So, when someone
else downloads that file later on, in ASCII mode, the server doesn't
translate it - there are no \n's in the file to translate, and an FTP
server will *only* translate its native format.
The most common cause of problems, in my experience, is users who
expect ASCII mode to translate all kinds of line endings to the
client's native format, when in fact that's not what is supposed to
happen.
> There is no reason to
> act this way, and in many people's eyes you come off as entirely
> condescending. Please be civil of fsck off.
I *am* being civil. I'm simply correcting misinformation; if your
feelings are hurt in the process, that's your problem. If you can't
stand being corrected, check your facts before posting.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Fri, 4 Jul 2008 08:12:49 -0700 (PDT)
From: andrew@ugh.net.au
Subject: Re: Unwanted output using croak with eval
Message-Id: <0368006e-a1b0-46c7-afeb-32d1576eda2f@k13g2000hse.googlegroups.com>
On 13 Jun, 18:12, fishfry <BLOCKSPAMfish...@your-mailbox.com> wrote:
> OOPS! Operator error.
You may have been confused by the behaviour of the debugger. I find
that if you are stepping through code and croak is called from within
eval then the debugger just continues until the next breakpoint (or
the end of the script, whichever is sooner). I suspect this is due to
croak manipulating the stack though I haven't looked into it. Setting
a breakpoint on the next line works around the issue.
Andrew
------------------------------
Date: Fri, 4 Jul 2008 13:47:18 -0700 (PDT)
From: Stefan <s1037989@gmail.com>
Subject: Windows Perl/Tk Sirius App
Message-Id: <ba36a126-38bb-464f-9e98-943a78fd1b94@x41g2000hsb.googlegroups.com>
About 6 months ago I posted code to this group concerning a Sirius
Radio application that I wrote which had a locking up problem. I have
since discovered how to resolve the issue and made many other
enhancements as well. The program is specific to my needs, but it
least it gives some great starter code for any one else wanting to do
the same. It also provides as an example on how to create a Tk
program.
#! /usr/bin/perl
use Tk;
use Tk::DialogBox;
use Tk::NoteBook;
use Tk::LabEntry;
use Tk::Font;
use Tk::StayOnTop;
use Audio::Radio::Sirius;
use Win32::SerialPort;
use Win32::Registry;
use strict;
$^W++;
$|=1;
# TO DO:
# Button to launch web page channel list
our $DEBUG = 1;
our $serial;
our $tuner;
our $timeout = 10;
my $padx = 4;
my $pady = 4;
#$Audio::Radio::Sirius::DEFAULTS{debug} = 1;
our $reg;
$::HKEY_LOCAL_MACHINE->Open("SOFTWARE\\SiriusTK", $reg);
my %tuner = (
minimize => 0,
serial => 0,
power => 0,
channel => 0,
mute => 0,
presets => {
row1 => {
1 => "Top 40",
8 => "80\'s",
9 => "90\'s",
# 12 => "SIRIUS\nSuper Mix",
21 => "Alternative\nRock",
60 => "Today\'s\nCountry",
103 => "Blue Collar\nComedy",
104 => "Comedy\nUncensored",
105 => "Family\nComedy",
},
row2 => {
# 119 => "DSC",
129 => "CNBC",
130 => "Bloomberg\nRadio",
132 => "CNN",
134 => "NPR Now",
135 => "NPR Talk",
141 => "BBC",
146 => "Sirius Left",
151 => "StL\nT&W",
},
},
);
my $mw = MainWindow->new();
$mw->optionAdd('*font', 'Helvetica 16');
$mw->title('Powered Off');
$mw->geometry('+1+1');
$mw->resizable(0,0);
my @frame;
$frame[0] = $mw->Frame->pack(-side=>'top',-fill=>'x');
my $minimize = $frame[0]->Button(-text=>$tuner{minimize} ? 'Restore' :
'Minimize', -height=>2, -width=>8,
-command => sub { minimize($tuner{minimize}?0:1); },
)->pack(-side=>'left', -padx=>$padx, -pady=>$pady);
my $exit = $frame[0]->Button(-text=>'Exit', -height=>2, -width=>8,
-command => sub { power(0); exit; },
)->pack(-side=>'left', -padx=>$padx, -pady=>$pady);
my $power = $frame[0]->Button(-text=>$tuner{power} ? 'Off' : 'On', -
height=>2, -width=>8,
-command => sub { power($tuner{power}?0:1); },
)->pack(-side=>'left', -padx=>$padx, -pady=>$pady);
my $mute = $frame[0]->Button(-text=>$tuner{mute} ? 'Unmute' : 'Mute', -
height=>2, -width=>8,
-command => sub { mute($tuner{mute}?0:1); },
)->pack(-side=>'left', -padx=>$padx, -pady=>$pady);
my $clock = $frame[0]->Label(-text=>'',-width=>20,-font=>$mw->Font(-
family=>'Helvetica',-size=>18))->pack(-side=>'left', -padx=>$padx, -
pady=>$pady);
$frame[1] = $mw->Frame->pack(-side=>'top',-fill=>'x');
my $cdn = $frame[1]->Button(-text=>'Down',-height=>2, -width=>8,
-command => sub { channel($tuner{channel}, -1); },
)->pack(-side=>'left', -padx=>$padx, -pady=>$pady);
my $cup = $frame[1]->Button(-text=>'Up',-height=>2, -width=>8,
-command => sub { channel($tuner{channel}, 1); },
)->pack(-side=>'left', -padx=>$padx, -pady=>$pady);
my $channel = $frame[1]->Entry(-textvariable => \$tuner{channel}, -
width=>4,)->pack(-side=>'left', -padx=>$padx, -pady=>$pady);
my $set = $frame[1]->Button(-text=>'Set',-height=>2, -width=>8,
-command => sub { channel($tuner{channel}); },
)->pack(-side=>'left', -padx=>$padx, -pady=>$pady);
if ( $DEBUG > 1 ) {
my $stdout = $frame[1]->Text(-width=>25, -height=>3, -font=>$mw-
>Font(-family=>'Helvetica',-size=>10))->pack(-side=>'left', -padx=>
$padx, -pady=>$pady);
#tie *STDOUT, 'Tk::Text', $stdout;
print "STDOUT\n";
my $stderr = $frame[1]->Text(-width=>25, -height=>3, -font=>$mw-
>Font(-family=>'Helvetica',-size=>10))->pack(-side=>'left', -padx=>
$padx, -pady=>$pady);
#tie *STDERR, 'Tk::Text', $stderr;
print STDERR "STDERR\n";
}
my $c = 2;
foreach my $cat ( keys %{$tuner{presets}} ) {
$frame[$c] = $mw->Frame->pack(-side=>'top',-fill=>'x');
foreach my $chan ( sort {$a<=>$b} keys %{$tuner{presets}{$cat}} ) {
$_ = $tuner{presets}{$cat}{$chan};
$frame[$c]->Button(-text=>$_, -height=>2, -width=>9, -font=>$mw-
>Font(-family=>'Helvetica',-size=>12),
-command => sub { channel($chan); },
)->pack(-side=>'left', -padx=>$padx, -pady=>$pady);
}
$c++;
}
check_serial();
refresh_title();
refresh_clock();
eval MainLoop() while 1;
# E N D M A I N R O U T I N E
sub debug { print STDERR @_ if $DEBUG };
sub check_serial {
my (@argv) = @_;
my @status = ();
debug("Called check_serial()\n");
$serial = new Win32::SerialPort('com9') unless $serial;
if ( $serial ) {
debug("\$serial OK\n");
if ( (@status) = $serial->status ) {
debug("Received Serial status\n");
if ( not defined $status[0] ) {
debug("Serial status FAIL: not defined\n");
$tuner{serial} = 0;
} elsif ( $status[0] == 1 ) {
debug("Serial status FAIL: blocking\n");
$tuner{serial} = 0;
} else {
debug("Serial status OK\n");
$tuner = new Audio::Radio::Sirius unless $tuner;
if ( $tuner ) {
debug("\$tuner OK\n");
if ( $tuner->connect($serial) ) {
debug("serial<->tuner OK\n");
$tuner{serial} = 1;
} else {
debug("serial<->tuner FAIL\n");
$tuner{serial} = 0;
}
} else {
debug("\$tuner FAIL\n");
$tuner{serial} = 0;
}
}
} else {
debug("Did NOT receive Serial status\n");
$tuner{serial} = 0;
}
} else {
debug("\$serial FAIL\n");
$tuner{serial} = 0;
}
unless ( $tuner{serial} ) {
debug("Resetting SiriusTK\n");
$tuner{power} = 0;
$tuner{channel} = 0;
$tuner{mute} = 0;
$power->configure(-text => 'On');
$mute->configure(-text => 'Mute');
$mw->title('Powered Off');
undef $tuner;
$serial->close if $serial;
undef $serial;
}
$mw->after(100, \&check_serial);
}
sub minimize {
my (@argv) = @_;
if ( $argv[0] ) {
$mw->stayOnTop;
$frame[3]->packForget();
$frame[2]->packForget();
$frame[1]->packForget();
$tuner{minimize} = 1;
} else {
$mw->dontStayOnTop;
$mw->raise();
$mw->geometry('+1+1');
$frame[1]->pack(-side=>'top',-fill=>'x');
$frame[2]->pack(-side=>'top',-fill=>'x');
$frame[3]->pack(-side=>'top',-fill=>'x');
$tuner{minimize} = 0;
}
$minimize->configure(-text => $argv[0] ? 'Restore' : 'Minimize');
}
sub power {
my (@argv) = (@_);
#debug("Called power($argv[0])\n");
#debug("Running power\n");
return unless $tuner{serial};
my $ok = 0;
eval {
local $SIG{ALRM} = sub { die "alarm: power($argv[0])\n" }; # NB: \n
required
alarm $timeout;
$ok = $tuner->power($argv[0]);
#debug("No ok: $ok\n") unless $ok;
alarm 0;
};
if ( $ok && !$@ ) {
$tuner{power} = $argv[0];
$power->configure(-text => $tuner{power} ? 'Off' : 'On');
$mw->title($tuner{power} ? 'Powered On' : 'Powered Off');
channel();
} else {
debug("Err(power): $@\n");
}
}
sub mute {
my (@argv) = (@_);
#debug("Called mute($argv[0])\n");
return unless $tuner{serial};
return unless $tuner{power};
#debug("Running mute\n");
my $ok = 0;
eval {
local $SIG{ALRM} = sub { die "alarm: mute($argv[0])\n" }; # NB: \n
required
alarm $timeout;
$ok = $tuner->mute($argv[0]);
#debug("No ok: $ok\n") unless $ok;
alarm 0;
};
if ( $ok && !$@ ) {
$tuner{mute} = $argv[0];
$mute->configure(-text => $tuner{mute} ? 'Unmute' : 'Mute');
} else {
debug("Err(mute): $@\n");
}
}
sub channel {
my (@argv) = (@_);
unless ( $argv[0] ) {
$reg->QueryValueEx('Channel', undef, $argv[0]) unless $argv[0];
if ( $argv[0] ) {
debug("Read channel $argv[0] from Registry\n");
} else {
$argv[0] = 1;
debug("Did not read channel from Registry; default to $argv[0]\n");
}
}
$reg->SetValueEx('Channel', undef, ®_DWORD, $argv[0]);
debug("Called channel($argv[0] + ".($argv[1] || 0)."): $tuner{channel}
\n");
#return if $tuner{channel} == $argv[0] + ($argv[1] || 0);
return unless $tuner{serial};
return unless $tuner{power};
#debug("Running channel($argv[0] + ".($argv[1] || 0)."):
$tuner{channel}\n");
my $ok = 0;
eval {
local $SIG{ALRM} = sub { die "alarm: channel($argv[0] + ".($argv[1]
|| 0).")\n" }; # NB: \n required
alarm $timeout;
#debug("Setting channel\n");
$ok = $tuner->channel(@argv);
#debug("Set channel\n");
#debug("No ok: $ok\n") unless $ok;
alarm 0;
};
if ( $ok && !$@ ) {
$tuner{channel} = $argv[0] + ($argv[1] || 0);
debug("New channel: $tuner{channel}\n");
} else {
debug("Err(channel): $@\n");
}
}
sub refresh_title {
#debug("Called refresh_title()\n");
if ( $tuner{serial} && $tuner{power} ) {
#debug("Running refresh_title\n");
eval {
#debug("Calling monitor\n");
local $SIG{ALRM} = sub { die "alarm: refresh_title_1\n" }; # NB:
\n required
alarm $timeout;
$tuner->monitor(1);
alarm 0;
#debug("Leaving monitor\n");
};
debug("Err(refresh_title_1): $@\n") unless !$@;
eval {
#debug("Calling callback\n");
local $SIG{ALRM} = sub { die "alarm: refresh_title_2\n" }; # NB:
\n required
alarm $timeout;
$tuner->set_callback('channel_update', \&channelupdate);
alarm 0;
#debug("Leaving callback\n");
};
debug("Err(refresh_title_2): $@\n") unless !$@;
$frame[0]->after(100, \&refresh_title);
} else {
$frame[0]->after(1000, \&refresh_title);
}
}
sub refresh_clock {
my $tpiece = localtime();
$tpiece =~ s/(\S+):(\S+):(\S+)//;
my ($hpiece,$mpiece,$spiece) = ($1,$2,$3);
$hpiece -= 12 if $hpiece > 12;
$tpiece =~ s/\s+/ /g;
$clock->configure(-text => "$tpiece / $hpiece:$mpiece:$spiece");
$frame[1]->after(100, \&refresh_clock);
}
sub channelupdate {
my ($channel, $pid, $artist, $title, $composer) = @_;
debug("Called channelupdate()\n");
if ( $tuner{serial} && $tuner{power} ) {
no warnings;
$tuner{channel} = $channel;
if ( $artist || $title ) {
debug("$channel: ".(join(' - ', $artist || '', $title ||
''))."\n");
$mw->title("$channel: ".(join(' - ', $artist || '', $title ||
'')));
} else {
debug("$channel: Reading information from sattelite...\n");
$mw->title("$channel: Reading information from sattelite...");
}
} else {
debug("Powered Off\n");
$mw->title('Powered Off');
}
}
------------------------------
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 1690
***************************************
