[27019] in Perl-Users-Digest
Perl-Users Digest, Issue: 8944 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Feb 12 03:05:49 2006
Date: Sun, 12 Feb 2006 00:05:06 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 12 Feb 2006 Volume: 10 Number: 8944
Today's topics:
Re: Absolute Novice (Mac Tiger) Needs Help <rwxr-xr-x@gmx.de>
Re: Absolute Novice (Mac Tiger) Needs Help <ben.usenet@bsb.me.uk>
Re: Absolute Novice (Mac Tiger) Needs Help <kamins@dogeared.com>
Re: Absolute Novice (Mac Tiger) Needs Help <jwkenne@attglobal.net>
Re: Absolute Novice (Mac Tiger) Needs Help (James Taylor)
Re: Absolute Novice (Mac Tiger) Needs Help (James Taylor)
Re: Absolute Novice (Mac Tiger) Needs Help (James Taylor)
Re: Absolute Novice (Mac Tiger) Needs Help (James Taylor)
Re: Absolute Novice (Mac Tiger) Needs Help <kamins@dogeared.com>
Re: Perl vs. Python <penryu@saiyix.ath.cx>
Re: Program to generate buttons for sequence of command (Raghuramaiah Gompa)
Trim whitespace with cookbook recipe does not result in <io@localhost.localdomain>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 12 Feb 2006 00:31:44 +0100
From: "Lukas Mai" <rwxr-xr-x@gmx.de>
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <dsls4s$1vk$02$1@news.t-online.com>
James Taylor <usenet@oakseed.demon.co.uk.invalid> schrob:
>
> Surely, the point of \n is that it represents a newline on *any*
> platform. MacOS X is (NextStep/BSD unix) so newlines are linefeeds like
> any other sensible operating system. Classic MacOS used carriage returns
> as newline markers. It was my understanding that the difference between
> binmode and err... "textmode" was that textmode performed the
> translation of newline chars so that the Perl programmer didn't have to
> concern himself with this issue. The Perl programmer could just read a
> text file and then be able to use \n to refer to newlines within the
> data in memory whether it had come from a file or anywhere else. So \n
> and \r retain their traditional C style meaning within Perl programs
> regardless of what the external OS happens to use in text files.
>
> At least, that's how it *should* be, but I have a nagging feeling I
> overheard people on this group describing it quite differently. The way
> they described it was that, instead of the abstraction being in the file
> IO layer, the meaning of \n and \r would change depending on the
> operating system that the Perl program was running on. Yeuck! That's
> clearly a portability maintenance disaster, and if this is really the
> case, you'd end up having to avoid the broken \n and \r in favour of
> \x0a and \x0d, not to mention spending a good deal of you time hunting
> down bugs caused by the assumption that \n was a linefeed and \r a
> carriage return.
As far as I know, both paragraphs are true, at least in C. If you open a
file in text mode and read a line, it is terminated by '\n'. However,
the numeric value of '\n' depends on the C compiler, and the external
representation of text files may not even have an end-of-line marker. So
what really happens depends on your C compiler and the IO library. For
MacOS classic it seems that the IO library does no substitution, and
'\n' == 13 in C programs.
As perldoc perlport explains:
...
A common misconception in socket programming is that "\n" eq "\012"
everywhere. When using protocols such as common Internet protocols,
"\012" and "\015" are called for specifically, and the values of the
logical "\n" and "\r" (carriage return) are not reliable.
HTH, Lukas
------------------------------
Date: Sun, 12 Feb 2006 00:54:25 +0000
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <pan.2006.02.12.00.54.25.596001@bsb.me.uk>
On Sat, 11 Feb 2006 22:55:58 +0000, James Taylor wrote:
> Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>
>> Wes Groleau wrote:
>>
>> > That was it (I worked with him by e-mail). BBEdit defaults to
>> > old-style linebreaks (\r) so the kernel treated the entire file as the
>> > shell command, leaving perl nothing to execute.
>>
>> I'm not a Mac user, but I thought that \r does represent a newline on
>> Mac, at least according to "perldoc perlport".
>
> Surely, the point of \n is that it represents a newline on *any* platform.
> MacOS X is (NextStep/BSD unix) so newlines are linefeeds like any other
> sensible operating system.
Sadly no.
Of course that would not have helped since the problem was a \r not at \n.
In this particular case, of course, perl is blameless since (if the report
is correct) it was the kernel the missed the \r.
> The Perl programmer could just read a text file and then be able to
> use \n to refer to newlines within the data in memory whether it had come
> from a file or anywhere else. So \n and \r retain their traditional C
> style meaning within Perl programs regardless of what the external OS
> happens to use in text files.
This is not my experience, but I last used non-Unix perl many, many
version ago on an old Windows machine so I may be behind the times.
> At least, that's how it *should* be, but I have a nagging feeling I
> overheard people on this group describing it quite differently. The way
> they described it was that, instead of the abstraction being in the file
> IO layer, the meaning of \n and \r would change depending on the
> operating system that the Perl program was running on.
Sort of There are several places in Perl where "the right thing happens"
depending on where the script is running. Non-binary file IO is one.
Other places include ^ and $ which match (sometimes) after and before a
line ending. As far as I know, the meaning of \n and \r remain the same,
however. It is just that on Windows (for example) writing \n will cause
the file IO system to emit a line ending (\r\n). Matching for \n or \r
always means match that exact character.
BTW, this is simplified in Perl 6. \n matches "line end" (OS defined) and
^ and $ match the start and end of strings (^^ and $$ mean the same as the
old ^ and $).
> Yeuck! That's
> clearly a portability maintenance disaster, and if this is really the
> case, you'd end up having to avoid the broken \n and \r in favour of
> \x0a and \x0d, not to mention spending a good deal of you time hunting
> down bugs caused by the assumption that \n was a linefeed and \r a
> carriage return.
I don't think so. Perl gets it about right in most cases. Note that the
original posted problem turned out not to be with Perl! The fundamental
problem is hard and it is not obvious what solution yealds the most
useable results with the fewest surprises for programmers.
--
Ben.
------------------------------
Date: Sat, 11 Feb 2006 16:54:39 -0800
From: Scot Kamins <kamins@dogeared.com>
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <kamins-318168.16543911022006@sn-ip.vsrv-sjc.supernews.net>
Thanks to all for helping with this issue.
Special thanks to Wesley Groleau who solved the mystery and spent a
bunch of time and e-mails on it. Wesley provided several options as
solutions; I'll probably choose to have BBEDIT use Unix line terminators.
There are other problems associated with using Perl & Terminal in MacOS
X - Tiger having to do with permissions. I guess the world isn't simple.
Another possibility I see is to use MacPerl under the Classic (System 9)
Environment and learn how to translate line terminators before I move
the scripts to HTML (my ultimate application). These problems don't
exist in MacPerl, but I don't know enough yet to understand the
limitations of going that route.
It's all a great learning experience!
Thanks again to all,
- Scot Kamins
------------------------------
Date: Sat, 11 Feb 2006 21:29:53 -0500
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <E4xHf.67$mz.24@fe10.lga>
James Taylor wrote:
> Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>
>> Wes Groleau wrote:
>>
>>> That was it (I worked with him by e-mail).
>>> BBEdit defaults to old-style linebreaks (\r)
>>> so the kernel treated the entire file as the shell command,
>>> leaving perl nothing to execute.
>> I'm not a Mac user, but I thought that \r does represent a newline on
>> Mac, at least according to "perldoc perlport".
>
> Surely, the point of \n is that it represents a newline on *any*
> platform. MacOS X is (NextStep/BSD unix) so newlines are linefeeds like
> any other sensible operating system. Classic MacOS used carriage returns
> as newline markers. It was my understanding that the difference between
> binmode and err... "textmode" was that textmode performed the
> translation of newline chars so that the Perl programmer didn't have to
> concern himself with this issue. The Perl programmer could just read a
> text file and then be able to use \n to refer to newlines within the
> data in memory whether it had come from a file or anywhere else. So \n
> and \r retain their traditional C style meaning within Perl programs
> regardless of what the external OS happens to use in text files.
>
> At least, that's how it *should* be, but I have a nagging feeling I
> overheard people on this group describing it quite differently. The way
> they described it was that, instead of the abstraction being in the file
> IO layer, the meaning of \n and \r would change depending on the
> operating system that the Perl program was running on. Yeuck! That's
> clearly a portability maintenance disaster, and if this is really the
> case, you'd end up having to avoid the broken \n and \r in favour of
> \x0a and \x0d, not to mention spending a good deal of you time hunting
> down bugs caused by the assumption that \n was a linefeed and \r a
> carriage return.
>
> Can anyone put my mind at ease that the design of Perl is sensible, as
> described in the first paragraph, and not broken as described in the
> second paragraph? Thanks.
This seems confused.
"\n" is always \x0A or \u000A in RAM. (Unless, perhaps, on EBCDIC.)
"\r" is always \x0D or \u000A in RAM. (Unless, perhaps, on EBCDIC.)
The file system, properly speaking, is always neutral.
But the file functions/methods of various compilers/libraries, in text
mode, may translate inbound \x0D0A (DOS-Windows-OS/2) or \x0D (MacOS
Classic) into \x0A, and outbound \x0A into \x0D0A (DOS-Windows-OS/2) or
\x0D (MacOS Classic) into \x0D. (On IBM mainframes, file-system record
boundaries are used similarly.)
MacOS X uses \x0A, but I believe programs are expected to be forgiving
on input. I know the decent Windows text editors (ee.g., TextPad and
EmEditor) are.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
------------------------------
Date: Sun, 12 Feb 2006 04:53:24 +0000
From: usenet@oakseed.demon.co.uk.invalid (James Taylor)
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <1hampok.1851y0414tjrk6N%usenet@oakseed.demon.co.uk.invalid>
John W. Kennedy <jwkenne@attglobal.net> wrote:
> James Taylor wrote:
>
> > Surely, the point of \n is that it represents a newline on *any*
> > platform. MacOS X is (NextStep/BSD unix) so newlines are linefeeds like
> > any other sensible operating system. Classic MacOS used carriage returns
> > as newline markers. It was my understanding that the difference between
> > binmode and err... "textmode" was that textmode performed the
> > translation of newline chars so that the Perl programmer didn't have to
> > concern himself with this issue. The Perl programmer could just read a
> > text file and then be able to use \n to refer to newlines within the
> > data in memory whether it had come from a file or anywhere else. So \n
> > and \r retain their traditional C style meaning within Perl programs
> > regardless of what the external OS happens to use in text files.
> >
> > At least, that's how it *should* be, but I have a nagging feeling I
> > overheard people on this group describing it quite differently. The way
> > they described it was that, instead of the abstraction being in the file
> > IO layer, the meaning of \n and \r would change depending on the
> > operating system that the Perl program was running on. Yeuck! That's
> > clearly a portability maintenance disaster, and if this is really the
> > case, you'd end up having to avoid the broken \n and \r in favour of
> > \x0a and \x0d, not to mention spending a good deal of you time hunting
> > down bugs caused by the assumption that \n was a linefeed and \r a
> > carriage return.
> >
> > Can anyone put my mind at ease that the design of Perl is sensible, as
> > described in the first paragraph, and not broken as described in the
> > second paragraph? Thanks.
>
> This seems confused.
>
> "\n" is always \x0A or \u000A in RAM. (Unless, perhaps, on EBCDIC.)
>
> "\r" is always \x0D or \u000A in RAM. (Unless, perhaps, on EBCDIC.)
I assume you mean \u000D there.
> The file system, properly speaking, is always neutral.
>
> But the file functions/methods of various compilers/libraries, in text
> mode, may translate inbound \x0D0A (DOS-Windows-OS/2) or \x0D (MacOS
> Classic) into \x0A, and outbound \x0A into \x0D0A (DOS-Windows-OS/2) or
> \x0D (MacOS Classic) into \x0D. (On IBM mainframes, file-system record
> boundaries are used similarly.)
That's exactly what I would expect, and is exactly what I described in
my first paragraph. Which bit of my first paragraph did you think was
saying something different?
I don't see why this area confuses people so much because it really just
boils down to where the abstraction takes place: It's either at the file
i/o layer, or by mucking about with \n. Clearly the former would be
sensible and the latter would be crazy. However, I've seen the
luminaries of this group claim that \n does not mean linefeed on all
platforms and that it is therefore necessary to use \x0A or similar if
you want to be sure you're creating or matching a real linefeed rather
than whatever the local newline marker is. If it really is true that
some idiot porter decided to muck about with the meaning of \n instead
of abstracting the translation to the file i/o layer, then the result is
that we should all stop using \n throughout our code unless we know for
sure that we want a character sequence that changes according to the
platform our code happens to be running on.
--
James Taylor
------------------------------
Date: Sun, 12 Feb 2006 05:12:38 +0000
From: usenet@oakseed.demon.co.uk.invalid (James Taylor)
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <1hamqy2.ccvvfzn65gfiN%usenet@oakseed.demon.co.uk.invalid>
Lukas Mai <rwxr-xr-x@gmx.de> wrote:
> James Taylor <usenet@oakseed.demon.co.uk.invalid> schrob:
> >
> > Surely, the point of \n is that it represents a newline on *any*
> > platform. MacOS X is (NextStep/BSD unix) so newlines are linefeeds like
> > any other sensible operating system. Classic MacOS used carriage returns
> > as newline markers. It was my understanding that the difference between
> > binmode and err... "textmode" was that textmode performed the
> > translation of newline chars so that the Perl programmer didn't have to
> > concern himself with this issue. The Perl programmer could just read a
> > text file and then be able to use \n to refer to newlines within the
> > data in memory whether it had come from a file or anywhere else. So \n
> > and \r retain their traditional C style meaning within Perl programs
> > regardless of what the external OS happens to use in text files.
> >
> > At least, that's how it *should* be, but I have a nagging feeling I
> > overheard people on this group describing it quite differently. The way
> > they described it was that, instead of the abstraction being in the file
> > IO layer, the meaning of \n and \r would change depending on the
> > operating system that the Perl program was running on. Yeuck! That's
> > clearly a portability maintenance disaster, and if this is really the
> > case, you'd end up having to avoid the broken \n and \r in favour of
> > \x0a and \x0d, not to mention spending a good deal of you time hunting
> > down bugs caused by the assumption that \n was a linefeed and \r a
> > carriage return.
>
> As far as I know, both paragraphs are true, at least in C. If you open a
> file in text mode and read a line, it is terminated by '\n'. However,
> the numeric value of '\n' depends on the C compiler,
Which is the case in the second paragraph NOT the first.
Well, if the C compiler set a precedent for mucking about with the
meaning of \n then it is quite possible that perl porters missed the
opportunity to make this ugliness transparent to Perl. Given that Perl
prides itself on its platform independence, I would be surprised and
disappointed to discover that the porters got this wrong.
> and the external representation of text files may not even have an
> end-of-line marker.
Eh? How many platforms don't have the concept of lines in text files?
> So what really happens depends on your C compiler and the IO library.
> For MacOS classic it seems that the IO library does no substitution,
> and '\n' == 13 in C programs.
Oh, so it's the author of MacPerl that messed things up for us by not
getting the IO library to do the right thing? I wonder what temporary
insanity caused him to decide that mucking about with the meaning of \n
was a neater less problematic solution than getting textmode IO to
transliterate automatically. I wonder if it crossed his mind that his
decision would have the effect of killing off \n not just on Classic
MacOS, but also everywhere that programmers want to write platform
independent code.
> As perldoc perlport explains:
> ...
> A common misconception in socket programming is that "\n" eq "\012"
> everywhere. When using protocols such as common Internet protocols,
> "\012" and "\015" are called for specifically, and the values of the
> logical "\n" and "\r" (carriage return) are not reliable.
Damn. And there lies the problem. I shall have to go through all my code
changing \n into \x0A. What a right royal pain in the arse. Am I going
to have to change \r into \x0D everywhere too? Grrr... I'd like to get
my hands around the throat of whoever thought this was a good idea and
beat some sense into them.
--
James Taylor
------------------------------
Date: Sun, 12 Feb 2006 05:43:50 +0000
From: usenet@oakseed.demon.co.uk.invalid (James Taylor)
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <1hamrxr.1li73z7aw7chdN%usenet@oakseed.demon.co.uk.invalid>
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> On Sat, 11 Feb 2006 22:55:58 +0000, James Taylor wrote:
>
> > Surely, the point of \n is that it represents a newline on *any* platform.
> > MacOS X is (NextStep/BSD unix) so newlines are linefeeds like any other
> > sensible operating system.
>
> Sadly no.
Err... haven't we just established that \n *does* change to reflect the
local newline? On most sensible systems newline=linefeed but on some
weird ones it is a different character or character sequence.
> Of course that would not have helped since the problem was a \r not at \n.
> In this particular case, of course, perl is blameless since (if the report
> is correct) it was the kernel the missed the \r.
Yes, but the conversation has moved on since then. We're discussing
portability issues with \n now. The OP's question was solved by getting
his editor to save text files with linefeeds.
> Sort of There are several places in Perl where "the right thing happens"
> depending on where the script is running. Non-binary file IO is one.
Yes, I thought as much. So why was it necessary to muck about with \n?
> Other places include ^ and $ which match (sometimes) after and before a
> line ending. As far as I know, the meaning of \n and \r remain the same,
> however.
Do they? They certainly should, but I'm not so sure they do.
> It is just that on Windows (for example) writing \n will cause
> the file IO system to emit a line ending (\r\n). Matching for \n or \r
> always means match that exact character.
Really? Oh cool, then it's not as bad as I thought. However, so many
people have offered different interpretations of this that I'm not going
to believe it until I can test it on a dodgy newline system such as
Windows or MacOS Classic.
> BTW, this is simplified in Perl 6. \n matches "line end" (OS defined) and
> ^ and $ match the start and end of strings (^^ and $$ mean the same as the
> old ^ and $).
The Perl6 zero-width assertions are certainly better, but I don't think
that has any bearing on \n. You say that Perl6's \n matches "line end",
but that sounds like its meaning will be different on every system which
is just what's wrong with Perl5's \n. Couldn't they use a different
backslash escape for the magically changing newline sequence and leave
the old \n and \r with their traditional values?
> > Yeuck! That's
> > clearly a portability maintenance disaster, and if this is really the
> > case, you'd end up having to avoid the broken \n and \r in favour of
> > \x0a and \x0d, not to mention spending a good deal of you time hunting
> > down bugs caused by the assumption that \n was a linefeed and \r a
> > carriage return.
>
> I don't think so. Perl gets it about right in most cases.
But the average Perl program deals with data from all kinds of sources
so how can Perl possibly know whether the data you're dealing with has
come from a local text file, a socket, a foreign file format, or
something else entirely? It obviously can't so \n and \r should remain
with their traditional values, and either the IO layer should do the
localised conversions or the programmer should incorporate the
conversions in his file reading functions. Don't you agree?
> Note that the original posted problem turned out not to be with Perl!
Yes, but the conversation has moved on since then.
> The fundamental problem is hard and it is not obvious what solution
> yealds the most useable results with the fewest surprises for
> programmers.
Really? Can you think of anything better than having the whole newline
issue made transparent to the program because the IO layer handles the
transliteration? More to the point, can you think of anything worse than
breaking the meaning of \n and \r in all existing software?
--
James Taylor
------------------------------
Date: Sun, 12 Feb 2006 05:55:06 +0000
From: usenet@oakseed.demon.co.uk.invalid (James Taylor)
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <1hamtac.1y6hu8rptrp7nN%usenet@oakseed.demon.co.uk.invalid>
Scot Kamins <kamins@dogeared.com> wrote:
> There are other problems associated with using Perl & Terminal in MacOS
> X - Tiger having to do with permissions. I guess the world isn't simple.
Well, I'm using Perl and Terminal in MacOSX Tiger and permissions work
in the normal unix way for me. What is the problem you've encountered?
> Another possibility I see is to use MacPerl under the Classic (System 9)
> Environment and learn how to translate line terminators
Why make life hard for yourself when Tiger does everything normally?
If what we've learnt elsewhere in this thread about how duff MacPerl's
IO layer is true, then you'll only be teaching yourself a warped view of
how Perl should work. So unless you actually need your code to be
portable, it doesn't seem worth learning MacPerl.
> before I move the scripts to HTML (my ultimate application).
Not sure what you mean by moving them to HTML. Do you mean move them to
a web server environment where they generate HTML?
> These problems don't exist in MacPerl,
Eh? What do you mean? MacPerl is the *cause* of these portability
problems!
> It's all a great learning experience!
That's one way of putting it. ;-)
I'd call it pain and suffering.
--
James Taylor
------------------------------
Date: Sat, 11 Feb 2006 23:43:33 -0800
From: Scot Kamins <kamins@dogeared.com>
Subject: Re: Absolute Novice (Mac Tiger) Needs Help
Message-Id: <kamins-E17FBA.23433311022006@sn-ip.vsrv-sjc.supernews.net>
James,
I appreciate your comments. But you have to understand that I am such a
novice that I don't know what I don't know. The basic knowledge you
assume are yet my goals.
While I'm learning Perl I'm also learning Unix (at which I am also a
complete novice).
So while Tiger may do everything normally, I have yet to learn what
normal means.
In article <1hamtac.1y6hu8rptrp7nN%usenet@oakseed.demon.co.uk.invalid>,
usenet@oakseed.demon.co.uk.invalid (James Taylor) wrote:
> Scot Kamins <kamins@dogeared.com> wrote:
>
> > There are other problems associated with using Perl & Terminal in MacOS
> > X - Tiger having to do with permissions. I guess the world isn't simple.
>
> Well, I'm using Perl and Terminal in MacOSX Tiger and permissions work
> in the normal unix way for me. What is the problem you've encountered?
>
> > Another possibility I see is to use MacPerl under the Classic (System 9)
> > Environment and learn how to translate line terminators
>
> Why make life hard for yourself when Tiger does everything normally?
>
> If what we've learnt elsewhere in this thread about how duff MacPerl's
> IO layer is true, then you'll only be teaching yourself a warped view of
> how Perl should work. So unless you actually need your code to be
> portable, it doesn't seem worth learning MacPerl.
>
> > before I move the scripts to HTML (my ultimate application).
>
> Not sure what you mean by moving them to HTML. Do you mean move them to
> a web server environment where they generate HTML?
>
> > These problems don't exist in MacPerl,
>
> Eh? What do you mean? MacPerl is the *cause* of these portability
> problems!
>
> > It's all a great learning experience!
>
> That's one way of putting it. ;-)
> I'd call it pain and suffering.
------------------------------
Date: Sun, 12 Feb 2006 03:30:25 GMT
From: Tim Hammerquist <penryu@saiyix.ath.cx>
Subject: Re: Perl vs. Python
Message-Id: <slrndutauh.310d.penryu@haruko.saiyix>
Abigail <abigail@abigail.nl> wrote:
> Emmanuel Florac (eflorac@imaginet.fr) wrote:
>== > Both God and Allah have used Python to create the universe.
>==
>== Wait a minute, aren't they the same person
>
> You mean both Bush and Osama Bin Laden get their orders from
> the same god?
This all reminds me of an episode of Doctor Who where the
beautiful Princess Astra is imprisoned by the power-hungry
Marshall....
And all of a sudden, I want to charge the White House with
plagiarism...
Tim Hammerquist
------------------------------
Date: Sun, 12 Feb 2006 02:47:26 +0000 (UTC)
From: rgompa@steel.ucs.indiana.edu (Raghuramaiah Gompa)
Subject: Re: Program to generate buttons for sequence of commands
Message-Id: <dsm7ju$6kl$1@rainier.uits.indiana.edu>
Thank you so much for your kind help and encouragement.
I will follow your suggestions. .. Raghu
In article <s46su1tu4gesopqvs399j4btsbffsm1506@4ax.com>,
zentara <zentara@highstream.net> wrote:
>
>Well I don't have windows to test, but I'll try to get
>you going. In the script, where you go into the launch sub
>
>sub launch {
> my $key = shift;
> my $command = $commands{$key}{'com'};
> if(fork==0){ exec "xterm -hold -e $command" }
>}
>
>you need to change the line
>if(fork==0){ exec "xterm -hold -e $command" }
>
>to something compatible with Windows.
>
>The links I posted showed a few methods.
>The easiest was using system with 1
>
>system(1, $file_to_run );
>
>So first, try changing the sub to
>
>sub launch {
> my $key = shift;
> my $command = $commands{$key}{'com'};
> system( 1, $command }
>}
>
>and don't forget to change the 'com' assignments in the
>%commands hash to your programs
>
>'1-1' => {text => 'Latex test',
> com => "c:\texmf\miktex\bin\latex.exe test",
> color=> 'pink'},
>
>etc
>etc
>
>#######################################################
>If the system( 1, $cmd) dosn't work, you may have to use
>the code from the other node
>
>use Win32::Process;
>Win32::Process::Create($ProcessObj,
> "C:\winnt\notepad.exe",
> "c:\sample.txt",
> 0,
> DETACHED_PROCESS,
> ".") || die "cant find the application";
>
>
>#########################################################
>
>Finally, you may have to experiment a bit yourself.
>Setup a simple script, to see if it launches your app.
>Keep trying until you succeed. :-)
>
>Like:
>##############################################
>#!/usr/bin/perl
>use warnings;
>use strict;
>
>system( 1, "c:\texmf\miktex\bin\latex.exe test");
>
><>; #wait for keypress to simulate continued operation
>__END__
>
>
>#############################################
>You may find that you need something like
>"c:\texmf\miktex\bin\latex.exe", "test",
>
>due to the syntax peculiarities of the windows command line.
>
>Good luck. :-)
>
>
>
>--
>I'm not really a human, but I play one on earth.
>http://zentara.net/japh.html
------------------------------
Date: 12 Feb 2006 03:47:49 -0200
From: io <io@localhost.localdomain>
Subject: Trim whitespace with cookbook recipe does not result in trimmed array
Message-Id: <87irrlp1q2.fsf@localhost.localdomain>
Kind folks of Perlidom-
My intent is to slurp a big text file (say, a chapter from the
English literature). I then want to trim all the white space and
newlines, so I get an array of compact text. I've looked into the
Perl Cookbook, and came up with this.
However, it doesn't work. The array slurped up has as many spaces as
the original. In fact, it looks the same.
####################################
#!/usr/bin/perl
use warnings;
open INPUT, "textfile" or die $1;
my @data;
while(<INPUT>) {
my $fh = <INPUT>;
chomp $fh;
$fh =~ s/^\s+//;
$fh =~ s/\+$//;
push @data, $fh;
}
print @data, "\n";
###################################
Is the issue the print statement? Is it the stream? Is it a scope
issue with push @data?
I don't get it! Please help...
TIA.
------------------------------
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 V10 Issue 8944
***************************************
