[24394] in Perl-Users-Digest
Perl-Users Digest, Issue: 6582 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed May 19 11:10:57 2004
Date: Wed, 19 May 2004 08:10:12 -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 Wed, 19 May 2004 Volume: 10 Number: 6582
Today's topics:
Re: SOLVED: How do I scope a variable if the variable n <spamtrap@dot-app.org>
Re: SOLVED: How do I scope a variable if the variable n (Randal L. Schwartz)
Re: SOLVED: How do I scope a variable if the variable n <gnari@simnet.is>
Re: Style question. moller@notvalid.se
Re: Telnet.pm question regarding buffer size (Anno Siegel)
test ignoreit plz <vendas.jeansoftware@globo.com>
Re: Testing whether given file is open? chris-usenet@roaima.co.uk
Re: Testing whether given file is open? <remorse@partners.org>
Re: Testing whether given file is open? <jwillmore@remove.adelphia.net>
Win32, FTP, line ends (Phil Hibbs)
Re: Win32, FTP, line ends <spamtrap@dot-app.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 19 May 2004 09:01:44 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: SOLVED: How do I scope a variable if the variable name contains a variable?
Message-Id: <auudnb1V--smxzbdRVn-hw@adelphia.com>
Uri Guttman wrote:
> the symbol table is really just a hash tree with special side effects.
A related question - I recall reading here that Perl has a limit on the
length of its symbols. There seems no logical reason to limit key lengths
for one particular hash tree when others are not limited; does that mean
the limitation is in the parser? Is it a lex issue?
Or did I imagine the whole thing? ;-)
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Wed, 19 May 2004 14:10:16 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: SOLVED: How do I scope a variable if the variable name contains a variable?
Message-Id: <4f65f7b13731f4c4a181e938f25e9352@news.teranews.com>
>>>>> "Sherm" == Sherm Pendley <spamtrap@dot-app.org> writes:
Sherm> A related question - I recall reading here that Perl has a
Sherm> limit on the length of its symbols. There seems no logical
Sherm> reason to limit key lengths for one particular hash tree when
Sherm> others are not limited; does that mean the limitation is in the
Sherm> parser? Is it a lex issue?
It was formerly 255 characters per symbol (between double-colons). It
has now been relaxed (as of Perl 5.6, if I recall). The problem was a
fixed-length buffer in the lexer, so it applied only to literal
symbols, not to symbolic symbols created at runtime. So
$aaaaaa ... 300 total ... aaaa = 1;
was formerly illegal, but (caution symref coming up):
${"a" x 300} = 1;
was legal. Now they both "work" for some definition of work.
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Wed, 19 May 2004 08:28:10 -0000
From: "gnari" <gnari@simnet.is>
Subject: Re: SOLVED: How do I scope a variable if the variable name contains avariable?
Message-Id: <c8f5nt$qb0$1@news.simnet.is>
"DavidFilmer" <IneverReadAnythingSentToMe@hotmail.com> wrote in message
news:bECqc.78074$iF6.6596044@attbi_s02...
[about finding answers to one's questions]
> Anyway, I didn't find the question answered, but one posting I found
> mentioned:
> perldoc -q 'variable as a variable'
> (which is a perfectly natural perldoc topic name, though I would have
> never thought of it).
this just proves once again:
a) put the subject of your article in the Subject of your article
b) one should read the FAQ entirely once in a while, at least
read the questions. the FAQ is a great resource, and it is useful
to be aware of its content.
gnari
------------------------------
Date: Wed, 19 May 2004 11:53:20 GMT
From: moller@notvalid.se
Subject: Re: Style question.
Message-Id: <ud6508wew.fsf@notvalid.se>
Ben Morrow <usenet@morrow.me.uk> writes:
> Quoth tadmc@augustmail.com:
> > moller@notvalid.se <moller@notvalid.se> wrote:
> > >
> > > What is the best practice regarding 'use module' statments.
> > >
> > > Should they be put at the top of the file
> >
> > Yes.
>
> Well, s/file/lexical scope in which they apply/, especially for pragmas.
>
> Note in particular that if you have several 'package' statements in a
> file you will need to re-use any modules you want available from both
> namespaces.
>
> > Putting compile-time stuff "way down" in the code is misleading,
> > you might end up fooling yourself that way.
>
> Yes.
>
> Ben
Thank You for your input.
Since I'm prone to reusing snippets of my own
code I have decided to write the modules used
in any particular code snippet or subs in the
comments of that code.
------------------------------
Date: 19 May 2004 11:07:00 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Telnet.pm question regarding buffer size
Message-Id: <c8ff4k$nm$1@mamenchi.zrz.TU-Berlin.DE>
Scott Clay <ranclay@nortelnetworks.com> wrote in comp.lang.perl.misc:
> #!/usr/bin/perl
>
> use Net::Telnet();
> use Net::FTP;
>
> $telnetObj->cmd("ll 12345678901234567890123456789012345678"); //works
>
> ## The above command works fine passing it to a second linux box (41 chars
> all together) . However, the command below (42 chars) errors out. I think it
> has to do with ## the strings length. Is there anyway to increase the buffer
> size that I need to pass the string?
>
> $telnetObj->cmd("ll 123456789012345678901234567890123456789"); //DOESN'T
> Work
So what does it do? Show the error message!
> Input.txt File From the Telnet Object (Longer Command I'm trying to pass on
> the 2nd machine):
> [cliuser3@pcaccli1 cliuser3]$ mkdir /tmp/public/20040518163708
> [cliuser3@pcaccli1 cliuser3]$ chmod 755 /tmp/public/20040518163708
> [cliuser3@pcaccli1 cliuser3]$ cd /tmp/public/20040518163708
> [cliuser3@pcaccli1 20040518163708]$ ll
> 12345678901234567890123456789012345678^M<163708]$ ll
> 123456789012345678901234567890123456789
> ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H
That looks pretty chaotic, at least after Usenet has had its way with it.
In any case, a buffer of 40 bytes size is pretty unlikely. The problem
is probably something else.
Anno
------------------------------
Date: 19 May 2004 14:54:46 GMT
From: Professor Jean Christian <vendas.jeansoftware@globo.com>
Subject: test ignoreit plz
Message-Id: <c8fsfm$apv$88@news-reader1.wanadoo.fr>
test only. do not spam please.
------------------------------
Date: Wed, 19 May 2004 10:42:49 +0100
From: chris-usenet@roaima.co.uk
Subject: Re: Testing whether given file is open?
Message-Id: <ppmrn1-n09.ln1@moldev.cmagroup.co.uk>
Charles Packer <mailbox@cpacker.org> wrote:
> A large data file is being pushed to us via FTP. We can assume that as
> long as the file is open, the FTP transfer hasn't completed.
No you can't. A network outage halfway through the transfer will
eventually cause the FTP daemon to abort the connection and implicitly
close the file. Most will not delete an aborted and only partially
transferred file.
There are only two meaningful ways of asynchronously determining whether
a file has been transferred in its entirely.
(a) You transfer the file with a temporary file name (e.g. suffix
".tmp" to its proper name) and when the transfer has completed,
the sender renames it. Receipients must be coded to ignore all
files ending with ".tmp".
(b) The sender transfers a zero length marker file when the real
data file has been successfully transferred. Recipients must be
coded to ignore the data file until the marker appears.
In both cases you need a cleanup process to delete stale ".tmp" files.
Chris
------------------------------
Date: Wed, 19 May 2004 10:15:51 -0400
From: Richard Morse <remorse@partners.org>
Subject: Re: Testing whether given file is open?
Message-Id: <remorse-995C76.10154819052004@plato.harvard.edu>
In article <ppmrn1-n09.ln1@moldev.cmagroup.co.uk>,
chris-usenet@roaima.co.uk wrote:
> Charles Packer <mailbox@cpacker.org> wrote:
> > A large data file is being pushed to us via FTP. We can assume that as
> > long as the file is open, the FTP transfer hasn't completed.
>
> No you can't. A network outage halfway through the transfer will
> eventually cause the FTP daemon to abort the connection and implicitly
> close the file. Most will not delete an aborted and only partially
> transferred file.
>
> There are only two meaningful ways of asynchronously determining whether
> a file has been transferred in its entirely.
>
> (a) You transfer the file with a temporary file name (e.g. suffix
> ".tmp" to its proper name) and when the transfer has completed,
> the sender renames it. Receipients must be coded to ignore all
> files ending with ".tmp".
>
> (b) The sender transfers a zero length marker file when the real
> data file has been successfully transferred. Recipients must be
> coded to ignore the data file until the marker appears.
>
> In both cases you need a cleanup process to delete stale ".tmp" files.
> Chris
One other option is to have the upload client send the size of the file
first, and then send the file. When the uploaded file is the same as
the sent size, it's been entirely transferred.
Ricky
--
Pukku
------------------------------
Date: Wed, 19 May 2004 10:33:10 -0400
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: Testing whether given file is open?
Message-Id: <pan.2004.05.19.14.33.08.318663@remove.adelphia.net>
On Tue, 18 May 2004 14:25:33 -0700, Charles Packer wrote:
> A large data file is being pushed to us via FTP. We can assume that as
> long as the file is open, the FTP transfer hasn't completed. How do we
> test whether the file is still open? We know about fuser and lsof, but
> we (my colleague, at least, who has to code the Perl) would prefer
> using a purely Perlish approach. Is there a Perl module out there
> somewhere that performs such a test?
I get the sense that, on the server side, you need to do something with
the file when the transfer is complete, right? If so, read on.
When the transfer is completed, you could send an empty file to the server
(like filename.extention.200). When the server goes about it's business,
and sees the file with the extention 200, it knows the file transfer is
completed and can remove the files with the 200 extention. I suggest
this because secure ftp sites won't allow you to remove files, just send
them (with good reason - you don't want someone to remove a file that was
just uploaded whenever they want :-) ). This also aids in the issue of
the network connection being droped during transfer - because no file with
the 200 extention will be sent unless the transfer is completed. Worse
case is the file needs to be resent - which is something you will most
likely do anyway in the case of a network outage :-)
I'm sure there's issues with this method I haven't thought of, but it
might fit the bill for what you're doing.
HTH
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
A lack of leadership is no substitute for inaction.
------------------------------
Date: 19 May 2004 07:09:58 -0700
From: gg@snark.freeserve.co.uk (Phil Hibbs)
Subject: Win32, FTP, line ends
Message-Id: <a9ec249e.0405190609.29ce6ae1@posting.google.com>
I'm using Net::FTP on ActiveState perl 5.8.0 and I'm having a problem
with line ends.
The source files are MS-style with CR/LF line ends, and I'm FTPing the
file to an MVS mainframe (EBCDIC). The files received at the other end
still have the CR x'0D' character at the end.
I have worked around the problem by making a temp copy of the file and
converting the line ends to Unix-style and then FTPing that file, but
how can I get Net::FTP to behave as though the local platform were
Microsoft (which it is)? It's behaving like a *nix FTP client.
Phil Hibbs
http://www.perlmonks.org/index.pl?node=PhilHibbs
------------------------------
Date: Wed, 19 May 2004 10:27:43 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Win32, FTP, line ends
Message-Id: <J_adnfTJWsZ88zbdRVn-gQ@adelphia.com>
Phil Hibbs wrote:
> I'm using Net::FTP on ActiveState perl 5.8.0 and I'm having a problem
> with line ends.
If you want automagic EOL translation, you need to enable ASCII mode - see
the description of the ascii() method in Net::FTP's docs.
> how can I get Net::FTP to behave as though the local platform were
> Microsoft (which it is)? It's behaving like a *nix FTP client.
If I recall correctly, binary/ASCII mode FTP dates from long before UNIX and
DOS/Windows were predominant. Its original purpose was to transfer text
files between EBCDIC and ASCII based machines - although obviously it did
quite a bit more than just munge EOL characters in that case.
In other words, Net::FTP isn't behaving like a *nix client, it's behaving
like any standard client that's set to default to binary transfers.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
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 6582
***************************************
