[13924] in Perl-Users-Digest
No subject found in mail header
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Nov 10 17:48:05 1999
Date: Mon, 8 Nov 1999 15:05:20 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <942102319-v9-i1320@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 8 Nov 1999 Volume: 9 Number: 1320
Today's topics:
Re: @ISA <emschwar@rmi.net>
Re: A different turn ( WAS Re: Bye Tom? ) <gellyfish@gellyfish.com>
ANNOUNCE: Set::Object 1.01 <jll@skynet.be>
Re: Batch Program Execution <cassell@mail.cor.epa.gov>
Re: Beginner question - chomp <travis@entropy.atlantic.net>
Re: calling C-commands in perl <benedek@in.tum.de>
Re: CGI FAQ discussion, was Re: Problem with perl and M <gellyfish@gellyfish.com>
Re: CGI FAQ discussion, was Re: Problem with perl and M <flavell@mail.cern.ch>
Re: Do you now an affordable Perl editor for Windows NT <travis@entropy.atlantic.net>
Re: downloading pdf file with correct name (Kragen Sitaker)
Re: downloading pdf file with correct name <cassell@mail.cor.epa.gov>
Re: duplicates in an array <kbandes@home.com>
Re: FAQ 4.20: How do I expand function calls in a strin (M.J.T. Guy)
Re: FAQ 6.22: How can I match strings with multibyte ch (Kragen Sitaker)
Re: File Upload Without Using Modules? <cassell@mail.cor.epa.gov>
Re: File Upload Without Using Modules? <gellyfish@gellyfish.com>
Getting Present WOrking Directory krun@my-deja.com
Re: Getting Present WOrking Directory (Kragen Sitaker)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 08 Nov 1999 14:05:09 -0700
From: Eric The Read <emschwar@rmi.net>
Subject: Re: @ISA
Message-Id: <xkfu2mweltm.fsf@valdemar.col.hp.com>
"CS" <@mdo.net> writes:
> After looking through perlobj, perlmod, perlmodlib, and doing a search in
> the Perl CD Bookshelf, I failed to find discussion regarding @ISA (in
> otherwords, what is it, and what exactly does it do). Could someone please
> tell me where this is discussed.
I'll take your word for it about perlobj, though I'd have thought it said
*something*. Anyway, look in perltoot. There's a nice discussion of
inheritance there which should explain things for you.
-=Eric
--
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
-- Johnny Hart
------------------------------
Date: 8 Nov 1999 20:48:54 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: A different turn ( WAS Re: Bye Tom? )
Message-Id: <807cvm$fg9$1@gellyfish.btinternet.com>
On 8 Nov 1999 05:26:53 GMT David H. Adler wrote:
> In article <9IoV3.54879$23.2054646@typ11.nn.bcandid.com>, Kragen Sitaker wrote:
>>In article <m3ln9mo587.fsf@hank.yorku.ca>,
>>Steven Smolinski <sjs@yorku.ca> wrote:
>>>Elaine -HFB- Ashton <elaine@chaos.wustl.edu> wrote:
>>>[...a really fabulous post...]
>>>> I can't make love to my powerbook, sexy though it may be [...]
>>>
>>>You'd be surprised at the peripherals they're making nowadays.
>>>
>>>As long as you've got a PCMCIA slot free and a nice bottle of wine...
>>
>>http://www.fufme.com/ (via tbtf-irregulars from Jamie McCarthy)
>
> I note that the FAQ says that Mac and Linux compatable versions are
> still being developed, so that's probably not helpful to the powerbook
> owner... :-)
>
And its a little worrying that only Windoze is supported - what if it blue
screens at an inconvenient moment (as it always does anyway)
/J\
--
Jonathan Stowe <jns@gellyfish.com>
<http://www.gellyfish.com>
Hastings: <URL:http://dmoz.org/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: 08 Nov 1999 20:29:02 +0100
From: Jean-Louis Leroy <jll@skynet.be>
Subject: ANNOUNCE: Set::Object 1.01
Message-Id: <m3bt94zssh.fsf@enterprise.newedgeconcept>
I have just uploaded version 1.01 of Set::Object to CPAN.
DESCRIPTION
-----------
This modules implements a set of objects, that is, an unordered
collection of objects without duplication.
Changes
-------
There is no new functionality, but this version will work with the
current Perl development release (5.005_62). I've completely rewritten
the internals. They no longer use Perl arrays but C structs
instead. Using Perl arrays caused too much trouble each time the Perl
internal changed, because I did things which were not guaranteed to
work (realloc xpvav to make room for extra data).
The new version should work with older Perls (in fact I've tested it
with the current stable Perl).
1.01 should be completely backward-compatible. The only (undocumented)
thing that's changed is that Data::Dumper no longer displays the
buckets and their content. Anyway, that didn't contain all the
information necessary for reconstructing a Set::Object properly.
BTW, is it possible to register new types with Data::Dumper? I'll
check that out...
IMPORTANT
---------
Since everything's changed inside, this version is considered beta
software. If you upgrade and find no problems with it, please email
me. Of course, if you do find problems, email me also ;-)
--
V
VLR Jean-Louis Leroy
F http://users.skynet.be/jll
------------------------------
Date: Mon, 08 Nov 1999 14:31:20 -0800
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: Batch Program Execution
Message-Id: <38274F38.4666AC0B@mail.cor.epa.gov>
Vijay N Rao wrote:
>
> Hello,
>
> I need to execute a batch file in a perl script. How can this be done?
You will want to look up Perl's system() command, as well as
qx// . You can find these using the perldoc program at your
command prompt:
perldoc -f system
perldoc perlop [then search for qx]
Then consider whether Perl has the functionality to do what you
wanted without your needing to take the time to shell out to
your OS and run that batch file.
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Mon, 8 Nov 1999 06:43:28 -0500
From: <travis@entropy.atlantic.net>
Subject: Re: Beginner question - chomp
Message-Id: <Pine.LNX.4.10.9911080639570.15498-100000@entropy.atlantic.net>
I use the following command to "fix" files corrupted by windoze ftp.
perl -e -pi.bak 's#\cM##' badfile
-
Travis
On Wed, 20 Oct 1999, Yongsik Kim wrote:
>
>
> Boon Hoo wrote:
> >
> > Hi,
> >
> > I understand that chomp removes newline from the end of a string. I was
> > trying it one day to format some HTML files(grab each line, remove
> > newline, and write it to a text-file), when I found out that if I had
> > earlier "ftp" the files using binary mode, chomp doesn't seem to work -
>
> I think it worked.
> set $/ = "\r\n"; to change INPUT_RECORD_SEPARATOR
> (perldoc perlvar, and find the meaning of $/)
> or
> if you doesn't want to changed the value, just add s/\r$//; just
> above the chomp() line
>
> > i saw many ^M control characters instead in my output file. What is the
> > correct way to remove newlines from textfiles transferred through binary
> > mode?
> >
> > TIA,
> > Jonathan
>
>
------------------------------
Date: Mon, 08 Nov 1999 20:36:48 +0100
From: Thomas Benedek <benedek@in.tum.de>
Subject: Re: calling C-commands in perl
Message-Id: <38272650.82BAE102@in.tum.de>
Alex Rhomberg wrote:
> Dynaloader seems to search the file in ./blib etc.etc. you seem to be in
> the parent dir of you build directory, so the file is not found
>
> Try to edit the test.pl file as is suggested in the perlxstut manpage.
>
> And try to keep your lines at 80 chars.
>
> > I think it is a problem with the DynaLoader, is it?
>
> No, it's a problem with your current directory
>
> -Alex
Thanx for the answer, Alex.
But there is one problem:
I dont understand why the Dynaloader looks for the "SYMBOL" Perl_stack_sp
(referenced symbol not found at /tools/gnu/lib/perl5/DynaLoader.pm line 140)
I am puzzled because I tried exactly the same on the same system (SOLARIS at the
university) and it worked.
For what symbol is the Dynaloader looking for?
Is this symbol defined in ./blib bla...bla?
Sorry, but I want to understand this one in order to have a chance to do it
myself next time.
(And to help people who have the same probs!)
Thomas
------------------------------
Date: 8 Nov 1999 21:18:34 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <807ena$fgg$1@gellyfish.btinternet.com>
On Mon, 08 Nov 1999 10:54:56 -0800 voltemand@earthlink.net wrote:
> Uri Guttman wrote:
>
>>
>> there still has to be created a perl SDK with many of the more popular
>> and useful modules already built with perl for many common platforms.
>> that would make creating turnkey systems with perl that much easier.
>>
>
> Some of us newbies who haven't got our linux boxes up yet and are running on ,
> say, Macs would dearly appreciate something like that. Kind of hard to
> experiment
> with alot of this stuff without having one's own apache, etc.
>
I dont think that was what Uri meant - I think what he is talking about is
distributing a CD (say) with prebuilt binaries of Perl and a goodly selection
of modules. You dont need a web server at all to do most of the interesting
stuff with Perl infact I would go so far as to say that CGI stuff can be
decidedly uninteresting until you start looking at building real applications
and *then* most of it has nothing to do with the web anyhow - but thats me
I guess ...
/J\
--
Jonathan Stowe <jns@gellyfish.com>
<http://www.gellyfish.com>
Hastings: <URL:http://dmoz.org/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: Mon, 8 Nov 1999 22:58:35 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
To: perlfaq-suggestions@perl.com
Subject: Re: CGI FAQ discussion, was Re: Problem with perl and MSIE5
Message-Id: <Pine.HPP.3.95a.991108215649.28187G-100000@hpplus01.cern.ch>
[* Posted to clpm, and emailed to perlfaq-suggestions@perl.com
in accordance with the instructions in the FAQ itself *]
> On Fri, 5 Nov 1999, David Cassell wrote:
>
> > See? You do need to get these FAQs corrected.
OK, the discussion here seems to have died down, and it looks as if
discussion of the copy posted to the CGI authoring group never got
started, so I guess it's time to try and summarise this.
First an organisational point. If I follow Tom Phoenix's
regularly-posted pointer to the FAQs: http://www.cpan.org/doc/FAQs/ ,
I find myself at
http://www.perl.com/CPAN-local/doc/FAQs/FAQ/PerlFAQ.html
with a title that says I'm reading something that was last revised
1997/03/17.
However, the version distributed with a recent version of Perl
seems to be the one found here:
http://www.perl.com/pub/doc/manual/html/pod/perlfaq.html
Shouldn't this version discrepancy be resolved? It seems a pity
to send newbies to an obsolete version of the FAQ.
Here is a plain-text rendering of the specific FAQ item (from perlfaq9)
that's under review:
> ----
> How do I redirect to another page?
>
> Instead of sending back a Content-Type as the headers of your reply,
> send back a Location: header. Officially this should be a URI: header,
> so the CGI.pm module (available from CPAN) sends back both:
>
> Location: http://www.domain.com/newpage
> URI: http://www.domain.com/newpage
>
> Note that relative URLs in these headers can cause strange effects
> because of ``optimizations'' that servers do.
>
> $url = "http://www.perl.com/CPAN/";;
> print "Location: $url\n\n";
> exit;
>
> To be correct to the spec, each of those "\n" should really each be
> "\015\012", but unless you're stuck on MacOS, you probably won't notice.
>
> ----
> 0: Disclaimer
>
> The last thing I am aiming for is a stand-up argument with the respected
> authors, and as a relative newcomer to the Perl group I hope this won't
> be taken amiss. However, a couple of emails and your posting have
> suggested that this is a useful thing for me to do [...]
I must stress that the verbose discussion is NOT, repeat NOT, in itself
a proposal for a new version of the FAQ. At the end, I make a rather
terse proposal.
In the discussion it became clear that some usenauts believe that much
of the CGI-related material in this part of the Perl FAQ would best be
removed, and reference made to CGI-specific resources remote from the
Perl language. However, I have no particular recommendation on what to
refer people _to_ if that were to happen. Nick Kew's CGI FAQ is
reliable, but creaking a bit at the hinges by now (fair enough, he
probably has better things to do), while Tom Boutell's "OpenFAQ" is
quite a mixed bag - it does not seem to be subject to energetic peer
review nor strong editorial control.
1. Background and authoritative resources.
The specification of the CGI is found originally at
hoohoo.ncsa.uiuc.edu, and has served us well for many years, but it
leaves a number of significant details uncodified.
For best current practice I would prefer to cite K.Coar's draft RFC
for CGI/1.1, see http://web.golux.com/coar/cgi/ , see e.g
http://web.golux.com/coar/cgi/draft-coar-cgi-v11-03-clean.html
The specifications of HTTP/1.0 and 1.1 are in their respective
RFCs, rfc1945 and rfc2616.
2. What's wrong in general terms with the current FAQ item?
- it addresses some issues that are CGI-specific
and have nothing to do with the Perl language as such
- it omits to call attention to doing it with CGI.pm, which is surely
the safest approach for anyone who needs to consult the FAQ
- it omits to cite any of the authoritative specifications, thus it
fails the principle of "teaching to fish".
[An opinion was expressed that merely sending them to the specifications
was too drastic, there should be a CGI FAQ to send them to. However,
this is an open question: it's arguable that anyone who needs the Perl
FAQ should use CGI.pm, and anyone who wants to go beyond that needs to
be capable of reading at least the CGI spec, if not the HTTP spec.]
- it appears to be raising technical issues that are generic to CGI
scripts and have nothing specifically to do with redirecting.
- it seems to be confused about the distinction between the CGI
specification and the HTTP specification and/or about the distinction
between normal and NPH scripts)
- It omits to mention the possibility of influencing the status, e.g
to show that the redirection is permanent (301) rather than the default
which is documented to be 302 (temporary).
- it omits to mention the complications of issuing a redirection
in response to a POST transaction - a complex problem in which there
are incompatibilities between HTTP/1.0 and HTTP/1.1 specifications,
and between what happens in practice and what the specifications say
ought to happen.
3. What's wrong specifically with the answers given?
a. It is claimed that the response _ought_ to be a URI: response. I can
find no authoritative support for this claim. Both the NCSA and the
Coar specs document the proper response for producing an actual
redirection transaction as being a Location: header specifying an
absolute URI, optionally with a fragment-id. See for example
http://web.golux.com/coar/cgi/draft-coar-cgi-v11-03-clean.html#7.2.1.2
On the basis of the HTTP/1.0 spec (appendix D), the URI: header appears
to be informatory only, and in no way is it a request for the server to
perform a redirection. The correct (HTTP) protocol for performing a
redirection is an appropriate status-30x response in conjunction with an
HTTP Location: header specifying an absolute URI. The correct (CGI)
protocol for performing a redirection is a Location: CGI response
specifying an absolute URI, optionally with a fragment-id: the server
will supply the default 302 status if the CGI script does not set one.
b. It is claimed that "relative URLs in these headers can cause strange
effects", and there is some obscure reference to "optimizations".
BUT the CGI specification states clearly and unambiguously what shall
happen in response to two different kinds of URL in the Location: CGI
response, one of which MUST produce a network redirection transaction
(which is therefore what is wanted here), and one of which MUST be
performed internally by the server: relative URLs are not permitted, and
there is absolutely no scope for servers to implement "optimizations".
c. The FAQ claims, in effect, that newlines have to be represented
according to the HTTP spec. The CGI spec says this is wrong. And
anyway this has nothing specifically to do with issuing a redirection
response, so if it needs to be said, this is the wrong place for it.
-----
Proposal A. This specific FAQ, as corrected.
How do I redirect to another page?
The easiest way to get this right is to use the 'redirect' method
of the CGI.pm module.
If you insist on programming it yourself...
In your CGI response, instead of sending back a Content-Type, send a
Location: header specifying an absolute URI and optionally a
fragment-id:
Location: http://www.domain.com/newpage#spot
If you wish the redirection to use a status other than the default
redirection status 302 (temporary redirection), you may provide the
status explicitly (in a normal, non-NPH script, by including a
Status: in the CGI response).
Refer to the CGI specification for further detail.
Sending a redirection in response to a POST transaction is complex, due
to incompatibilities between HTTP/1.0 and 1.1 specifications, and
discrepancies in implementations. It is beyond the scope of this FAQ.
-----
What is closer to Perl however would be a proper explanation of how
a Perl script written to the CGI is supposed to return a response.
-----
Proposal B. (as addition)
[please compare this with my recent, relatively-language-free,
submission at http://www.boutell.com/openfaq/cgi/79.html , which was
prompted by the present discussion on clpm]
Q: How does a Perl CGI script return a response?
A: The easiest way of handling this is to use the CGI.pm module
to take care of the details for you.
There are two distinct kinds of CGI script, the normal kind and the
Non-Parsed Headers kind. The method of distinguishing between them is
implementation defined, so please consult the documentation for the
server that you use to discover which kind(s) it supports and how you
should tell the server which kind you want to use. With NCSA or Apache
servers, NPH scripts must be given names which begin with "nph-".
Normal (i.e non-NPH) scripts are much easier to handle, although there
may be a few obscure situations that can only be tackled by using NPH
scripts. Familiarity with the HTTP protocols is essential for
successful use of NPH scripts: that lies outside the scope of this FAQ.
The correct forms of response from a CGI script are documented in the
CGI specification. For a normal, non-NPH, script, the CGI specification
permits any of the common end-of-line conventions to be used, so you may
use "\n" in Perl on any platform.
In an NPH script, you are required to produce a complete and correct set
of HTTP protocol headers. The HTTP specification calls on servers to
use CR+LF as the only valid end-of-line representation (although it
advises clients to be tolerant of other conventions), and so in an NPH
script it would seem advisable to use binary output mode, and to
represent newlines with "\015\012" on all platforms, to assure proper
portability.
Do not confuse the CGI specification with the HTTP specification: the
similarities are intentional, but can sometimes be misleading.
[And then cite the URLs of the respective documents, as mentioned
above.]
-----
best regards
------------------------------
Date: Mon, 8 Nov 1999 06:49:02 -0500
From: <travis@entropy.atlantic.net>
Subject: Re: Do you now an affordable Perl editor for Windows NT
Message-Id: <Pine.LNX.4.10.9911080648410.15498-100000@entropy.atlantic.net>
I belive code magic is available as freeware.
See http://www.petes-place.com
On Wed, 20 Oct 1999, Johnny 'Loopy' Ooi wrote:
> What's wrong with Notepad? ;-)
>
> --
> Johnny Ooi. Aliases: Loopy, Tuxedo Mask, Quote Master.....
> E-Mail : jjyooi@dcs.qmw.ac.uk or jjyooi@yahoo.com
> WWW : http://www.dcs.qmw.ac.uk/~jjyooi/
> ICQ No : 6155774
>
> "Stay sane guys!"
>
> ===============================================================
>
>
------------------------------
Date: Mon, 08 Nov 1999 21:57:04 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: downloading pdf file with correct name
Message-Id: <QGHV3.58408$23.2199368@typ11.nn.bcandid.com>
In article <806cqi$pev$1@nnrp1.deja.com>, <martingormley@my-deja.com> wrote:
>I am opening a script called download.cgi.
>The script opens a socket which downloads a pdf file.
>
>Is there anyway that I can get the script to download the pdf without
>calling it download.pdf
Of course. When you open the file for write, instead of saying
open PDFOUT, '>download.pdf' or die "couldn't open download.pdf: $!\n";
say
open PDFOUT, ">$what_i_want_to_call_the_file"
or die "couldn't open $what_i_want_to_call_the_file: $!\n";
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: Mon, 08 Nov 1999 14:23:05 -0800
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: downloading pdf file with correct name
Message-Id: <38274D49.6C5DD3C3@mail.cor.epa.gov>
martingormley@my-deja.com wrote:
>
> I am opening a script called download.cgi.
> The script opens a socket which downloads a pdf file.
It 'opens a socket'? Are you sure? I mean, you can do HTTP
that way, but it sounds like more trouble than it is worth.
How are you going to re-write soemthing like that? You
might want to switch to a better-documented system, like
Perl's CGI.pm module.
> Is there anyway that I can get the script to download the pdf without
> calling it download.pdf
Sure. but you'd have to find the place in that script where
it names the file 'download.pdf' and edit that section
properly. The script you are using is probably not known
to the people here, since it sounds like one of the kludges
floating around the web like flotsam after a shipwreck.
The people here are more likely to use CGI.pm or write
the correct code from scratch. As far as I can tell from
way over here, the problem is that the script you picked
up is just not written well enough.
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Mon, 08 Nov 1999 14:59:02 -0500
From: Kenneth Bandes <kbandes@home.com>
Subject: Re: duplicates in an array
Message-Id: <38272B86.C133C9C0@home.com>
Baris Sumengen wrote:
> Yes, you are right. Everybody has to go over all the FAQ's once before
> posting here.
> But there is also another issue. I honestly sometimes don't understand the
> solution in the FAQ's. (I obviously don't know all the perl basics). But the
> idea behind perl is: "You don't have to know everything, but youy can still
> write useful programs".
I believe questions like "what does the FAQ mean when it says ..."
are treated kindly here. The FAQs are not always clear, or even
always right. If you've made the effort, you (probably) won't get
flamed and someone here will explain things for you (with at worst
a gentle trace of condescension).
Ken Bandes
------------------------------
Date: 8 Nov 1999 20:01:10 GMT
From: mjtg@cus.cam.ac.uk (M.J.T. Guy)
Subject: Re: FAQ 4.20: How do I expand function calls in a string?
Message-Id: <807a66$f14$1@pegasus.csx.cam.ac.uk>
Tom Christiansen <perlfaq-suggestions@perl.com> wrote:
>
> If you prefer scalar context, similar chicanery is also useful for
> arbitrary expressions:
>
> print "That yields ${\($n + 5)} widgets\n";
>
> Version 5.004 of Perl had a bug that gave list context to the
> expression in `${...}', but this is fixed in version 5.005.
Sadly, this bug *isn't* fixed, even in 5.005_62. And the description
of the bug is misleading: ${...} gives scalar context to the '...'
expression. The bug is that the \ operator always evaluates its
argument in list context, even if it is itself in scalar context.
Mike Guy
------------------------------
Date: Mon, 08 Nov 1999 21:45:05 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: FAQ 6.22: How can I match strings with multibyte characters?
Message-Id: <BvHV3.58368$23.2201627@typ11.nn.bcandid.com>
In article <38267f8b@cs.colorado.edu>,
Tom Christiansen <perlfaq-suggestions@perl.com> wrote:
> How can I match strings with multibyte characters?
> . . .
> So, the string of Martian "I am CVSGXX!" uses 12 bytes to encode
> the nine characters 'I', ' ', 'a', 'm', ' ', 'CV', 'SG', 'XX', '!'.
>
> Now, say you want to search for the single character `/GX/'. Perl
> doesn't know about Martian, so it'll find the two bytes "GX" in the
> "I am CVSGXX!" string, even though that character isn't there: it
> just looks like it is because "SG" is next to "XX", but there's no
> real "GX". This is a big problem.
>
> Here are a few ways, all painful, to deal with it:
. . .
If I had this problem, I would translate all my input strings to UTF-8
for internal processing. Then you won't have the 'GX' problem. This
also avoids the painful problems with things like S-JIS, in which you
have not just alignment but also shift-state to think about.
In UTF-8, no character's representation is a substring of any other
character's representation, or (as above) the concatenation of a suffix
of one character's representation and a prefix of another character's
representation. So Perl can happily pretend it's just an
undifferentiated string of bytes for regex matching, index(), substr(),
etc. (You just have to be careful not to accidentally chop characters
in half.)
It is nice, but not essential, if your input charset maps onto Unicode,
because then you might be able to get away with just outputting the
UTF-8 data, instead of having to translate it back into the grotty old
input charset.
On the other hand, I haven't tried this myself -- I haven't even read
the O'Reilly book on CJK information processing. Are there problems
with this approach that are not obvious to me?
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: Mon, 08 Nov 1999 14:14:18 -0800
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: File Upload Without Using Modules?
Message-Id: <38274B3A.1C08AA8@mail.cor.epa.gov>
Jon Hollcraft wrote:
>
> What is the sequence of events necessary to use the input=file option
> from a local machine to a server. What I have found thus far using
> examples found for modules transfers the file to my server's /tmp
> directory, and then promptly deletes it. While this is an interesting
> exercise, it does not copy the local file to the proper directory for
> future access. TIA Jon
It sounds to me like you *really* need to use the modules.
Whatever protocol you're using is going to be a lot more
complex than letting a module do the work for you. And there
are lots of different protocols which might be involved here,
so we can't give you concrete advice without knowing more.
Why don't you show this newsgroup a small chunk of code (30
lines max) which reproduces your problem, and perhaps we can
show you what went wrong. Most people find that using the
modules makes their lives *much* easier, so the problem may
just be a bug in your code.
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: 8 Nov 1999 21:29:45 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: File Upload Without Using Modules?
Message-Id: <807fc9$fgk$1@gellyfish.btinternet.com>
On Sun, 07 Nov 1999 18:32:54 -0800 Jon Hollcraft wrote:
> What is the sequence of events necessary to use the input=file option
> from a local machine to a server. What I have found thus far using
> examples found for modules transfers the file to my server's /tmp
> directory, and then promptly deletes it. While this is an interesting
> exercise, it does not copy the local file to the proper directory for
> future access. TIA Jon
I would then re-examine the documentation for CGI.pm which has a whole
section devoted to this subject.
/j\
--
Jonathan Stowe <jns@gellyfish.com>
<http://www.gellyfish.com>
Hastings: <URL:http://dmoz.org/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: Mon, 08 Nov 1999 20:44:44 GMT
From: krun@my-deja.com
Subject: Getting Present WOrking Directory
Message-Id: <807cnr$i39$1@nnrp1.deja.com>
Alright, this is my predicament. Different users are going to be
creating a randomnly named directory under the root directory. Under
this directory, there are 2 directories named archive and result. In
the archive directory, there are *.doc files. I need to write a perl
script program that is located in the archive folder. This script needs
to get the whole path of each *.doc file. Then, it needs to create a
directory under the Result directory, called MedTraceCenter. It lastly
needs to create a text file called ListWordDoc.txt and place it in the
MedTraceCenter directory. Writing some sort of code for any part of
this project would really help me out. Thanks for the help.
Krun
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 08 Nov 1999 22:13:23 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: Getting Present WOrking Directory
Message-Id: <7WHV3.58436$23.2205805@typ11.nn.bcandid.com>
In article <807cnr$i39$1@nnrp1.deja.com>, <krun@my-deja.com> wrote:
>Alright, this is my predicament. Different users are going to be
>creating a randomnly named directory under the root directory. Under
>this directory, there are 2 directories named archive and result. In
>the archive directory, there are *.doc files. I need to write a perl
>script program that is located in the archive folder. This script needs
>to get the whole path of each *.doc file.
I take it you want to find your current directory and work from that?
perldoc Cwd.
> Then, it needs to create a
>directory under the Result directory, called MedTraceCenter.
perldoc -f mkdir
> It lastly
>needs to create a text file called ListWordDoc.txt and place it in the
>MedTraceCenter directory.
perldoc -f open.
>Writing some sort of code for any part of
>this project would really help me out.
So would learning Perl, it looks like.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 1320
**************************************
