[31835] in Perl-Users-Digest
Perl-Users Digest, Issue: 3098 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 25 18:09:43 2010
Date: Wed, 25 Aug 2010 15:09:05 -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, 25 Aug 2010 Volume: 11 Number: 3098
Today's topics:
Odd file test behaviour on 64 bit windows <simon.andrews@bbsrc.ac.uk>
Re: Odd file test behaviour on 64 bit windows <NoSpamPleaseButThisIsValid3@gmx.net>
Re: Odd file test behaviour on 64 bit windows <simon.andrews@bbsrc.ac.uk>
Re: Odd file test behaviour on 64 bit windows sln@netherlands.com
Re: Odd file test behaviour on 64 bit windows (Malcolm Hoar)
Re: Odd file test behaviour on 64 bit windows <simon.andrews@bbsrc.ac.uk>
Re: Odd file test behaviour on 64 bit windows <NoSpamPleaseButThisIsValid3@gmx.net>
Re: Odd file test behaviour on 64 bit windows sln@netherlands.com
Re: Odd file test behaviour on 64 bit windows (Malcolm Hoar)
perl split <hslee911@yahoo.com>
Re: perl split <rvtol+usenet@xs4all.nl>
Re: perl split <klaus03@gmail.com>
Re: split on a string that should be interpreted as a r <sherm.pendley@gmail.com>
Writing or copying file to another directory <paul@pstech-inc.com>
Re: Writing or copying file to another directory <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 25 Aug 2010 02:21:33 -0700 (PDT)
From: Simon Andrews <simon.andrews@bbsrc.ac.uk>
Subject: Odd file test behaviour on 64 bit windows
Message-Id: <7bc0ff5a-ac92-49b1-972c-ca09429b139a@w30g2000yqw.googlegroups.com>
I'm assuming this is some magic I've not seen before, but I don't know
if it's perl or windows which is messing this up.
All I'm trying to do is to test for the existance of a directory in c:/
Program Files/ however the standard perl file tests seem to succeed
if a directory is present in either c:/Program Files or c:/Program
Files (x86).
M:\>dir "c:\Program Files"
Volume in drive C has no label.
Volume Serial Number is 862E-DA6A
Directory of c:\Program Files
25/08/2010 09:58 <DIR> .
25/08/2010 09:58 <DIR> ..
07/06/2010 12:21 <DIR> Broadcom
09/06/2010 15:47 <DIR> Common Files
14/07/2009 08:24 <DIR> DVD Maker
09/06/2010 15:41 <DIR> Hewlett-Packard
07/06/2010 14:13 <DIR> Hummingbird
09/06/2010 09:50 <DIR> ImageJ
14/07/2009 06:37 <DIR> Internet Explorer
08/06/2010 11:13 <DIR> Java
07/06/2010 12:59 <DIR> Microsoft Office
14/07/2009 06:32 <DIR> MSBuild
14/07/2009 06:32 <DIR> Reference Assemblies
07/06/2010 14:06 <DIR> SPSSInc
14/07/2009 06:37 <DIR> Windows Defender
14/07/2009 08:24 <DIR> Windows Journal
14/07/2009 06:37 <DIR> Windows Mail
14/07/2009 06:37 <DIR> Windows Media Player
14/07/2009 06:32 <DIR> Windows NT
14/07/2009 06:37 <DIR> Windows Photo Viewer
14/07/2009 06:32 <DIR> Windows Portable Devices
14/07/2009 06:37 <DIR> Windows Sidebar
0 File(s) 0 bytes
22 Dir(s) 138,471,190,528 bytes free
M:\Perl\VNTI Initialise>perl -e "print 'Exists' if (-d 'c:/Program
Files/Invitrogen')
Exists
M:\>perl -e "print 'Exists' if (-d 'c:/Program Files/MadeUp')
M:\>
The same thing happens with -e rather than -d.
How can I actually test if that directory *really* exists in that
location?
Cheers
Simon.
------------------------------
Date: Wed, 25 Aug 2010 11:50:34 +0200
From: Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net>
Subject: Re: Odd file test behaviour on 64 bit windows
Message-Id: <4c74e76a$0$6984$9b4e6d93@newsspool4.arcor-online.net>
On 25.08.2010 11:21, Simon Andrews wrote:
> I'm assuming this is some magic I've not seen before, but I don't know
> if it's perl or windows which is messing this up.
>
> All I'm trying to do is to test for the existance of a directory in c:/
> Program Files/ however the standard perl file tests seem to succeed
> if a directory is present in either c:/Program Files or c:/Program
> Files (x86).
>
> M:\>dir "c:\Program Files"
Have you tried to show all files (also hidden ones), i.e. are you sure
the directory isn't there?
Use "dir /a"
In Perl, you can also use readdir to show the contents of a directory.
Did you try to list the directory content that way?
Wolf
------------------------------
Date: Wed, 25 Aug 2010 04:05:23 -0700 (PDT)
From: Simon Andrews <simon.andrews@bbsrc.ac.uk>
Subject: Re: Odd file test behaviour on 64 bit windows
Message-Id: <f89237c4-c065-4fe2-ae08-1b4436696177@f6g2000yqa.googlegroups.com>
On Aug 25, 10:50=A0am, Wolf Behrenhoff
<NoSpamPleaseButThisIsVal...@gmx.net> wrote:
> On 25.08.2010 11:21, Simon Andrews wrote:
>
> Have you tried to show all files (also hidden ones), i.e. are you sure
> the directory isn't there?
>
> Use "dir /a"
M:\Perl\VNTI Initialise>dir /a "c:\Program Files\"
Volume in drive C has no label.
Volume Serial Number is 862E-DA6A
Directory of c:\Program Files
25/08/2010 09:58 <DIR> .
25/08/2010 09:58 <DIR> ..
07/06/2010 12:21 <DIR> Broadcom
09/06/2010 15:47 <DIR> Common Files
14/07/2009 05:54 174 desktop.ini
14/07/2009 08:24 <DIR> DVD Maker
09/06/2010 15:41 <DIR> Hewlett-Packard
07/06/2010 14:13 <DIR> Hummingbird
09/06/2010 09:50 <DIR> ImageJ
14/07/2009 06:37 <DIR> Internet Explorer
08/06/2010 11:13 <DIR> Java
07/06/2010 12:59 <DIR> Microsoft Office
14/07/2009 06:32 <DIR> MSBuild
14/07/2009 06:32 <DIR> Reference Assemblies
07/06/2010 14:06 <DIR> SPSSInc
14/07/2009 06:09 <DIR> Uninstall Information
14/07/2009 06:37 <DIR> Windows Defender
14/07/2009 08:24 <DIR> Windows Journal
14/07/2009 06:37 <DIR> Windows Mail
14/07/2009 06:37 <DIR> Windows Media Player
14/07/2009 06:32 <DIR> Windows NT
14/07/2009 06:37 <DIR> Windows Photo Viewer
14/07/2009 06:32 <DIR> Windows Portable Devices
14/07/2009 06:37 <DIR> Windows Sidebar
1 File(s) 174 bytes
23 Dir(s) 138,467,987,456 bytes free
> In Perl, you can also use readdir to show the contents of a directory.
> Did you try to list the directory content that way?
I did now, and this is just plain weird:
#!perl
use warnings;
use strict;
opendir DIR,'c:/Program Files' or die $!;
while ($_ =3D readdir DIR) {
print $_,"\n";
}
Gives me:
M:\>perl dir_test.pl
.
..
Broadcom
Common Files
desktop.ini
DVD Maker
Hewlett-Packard
Hummingbird
ImageJ
Internet Explorer
Invitrogen <-- Where did that come from???
Java
Microsoft Office
MSBuild
Reference Assemblies
SPSSInc
Uninstall Information
Windows Defender
Windows Journal
Windows Mail
Windows Media Player
Windows NT
Windows Photo Viewer
Windows Portable Devices
Windows Sidebar
So I have a directory which doesn't show up in cmd, or windows
explorer but is seen by perl??
Just to test further:
M:\>cd "c:\Program Files\Invitrogen"
The system cannot find the path specified.
So what is perl seeing that I'm not??
Simon.
------------------------------
Date: Wed, 25 Aug 2010 07:39:16 -0700
From: sln@netherlands.com
Subject: Re: Odd file test behaviour on 64 bit windows
Message-Id: <k6aa76914hv415uhp5il8uuoi04llveqrr@4ax.com>
On Wed, 25 Aug 2010 04:05:23 -0700 (PDT), Simon Andrews <simon.andrews@bbsrc.ac.uk> wrote:
>
>M:\>cd "c:\Program Files\Invitrogen"
>The system cannot find the path specified.
>
>So what is perl seeing that I'm not??
>
Perl is probably seeing what win32 api says is there.
And probably, the dir command and windows explorer respect
the registry with regard to show hidden and system files/folders.
Try to change folder options that enable viewing of hidden and system files/folders.
Reboot, then check again with the dir command and windows explorer.
If there is still the disparity, get Root Kit Revealer from SysInternals,
(bought out by Microsoft). Run the program and let it check the registry
and file system for root kits that may be hiding a friendly file from
viewing from win32. I doubt this is the problem though since Perl calls
win32 directly in the Windows implementation.
-sln
------------------------------
Date: Wed, 25 Aug 2010 14:58:13 GMT
From: malch@malch.com (Malcolm Hoar)
Subject: Re: Odd file test behaviour on 64 bit windows
Message-Id: <i53b252i572002malch@news.sonic.net>
In article <7bc0ff5a-ac92-49b1-972c-ca09429b139a@w30g2000yqw.googlegroups.com>, Simon Andrews <simon.andrews@bbsrc.ac.uk> wrote:
>I'm assuming this is some magic I've not seen before, but I don't know
>if it's perl or windows which is messing this up.
I'm pretty sure you're seeing some Windows magic that
takes place with 32-bit apps on a 64-bit O.S.
You are running Perl compiled in 32-bit, right?
If you want to see a true and accurate picture of the
system disk file system on 64-bit Windows, you need to
run a version of Perl compiled in 64-bit.
It's not just a Perl issue; you'll see this weirdness
with other 32 bit apps on 64-bit Windows.
--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar "The more I practice, the luckier I get". |
| malch@malch.com Gary Player. |
| http://www.malch.com/ Shpx gur PQN. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Wed, 25 Aug 2010 08:30:18 -0700 (PDT)
From: Simon Andrews <simon.andrews@bbsrc.ac.uk>
Subject: Re: Odd file test behaviour on 64 bit windows
Message-Id: <6d1e050c-d6f1-4d45-ad4b-d96be85d1d5c@5g2000yqz.googlegroups.com>
On Aug 25, 3:58=A0pm, ma...@malch.com (Malcolm Hoar) wrote:
> In article <7bc0ff5a-ac92-49b1-972c-ca09429b1...@w30g2000yqw.googlegroups=
.com>, Simon Andrews <simon.andr...@bbsrc.ac.uk> wrote:
>
> >I'm assuming this is some magic I've not seen before, but I don't know
> >if it's perl or windows which is messing this up.
>
> It's not just a Perl issue; you'll see this weirdness
> with other 32 bit apps on 64-bit Windows.
I kind of got a bit closer to this, but I'm still not clear exactly
what's happening. It doesn't seem to be a perl issue though so I'll
drop the thead in this group.
Basically any directories created programatically in Program Files
aren't showing up in Explorer or a cmd shell. If I use cygwin I can
see them (and delete them and create them), and the results agree with
what I see in perl, but they don't show up though the windows API. If
I create the directories through explorer then they show up
everywhere.
I suspect this is going to be some kind of security 'feature' - but
it's sure breaking a lot of stuff for me here!
Thanks for the pointers
Simon.
------------------------------
Date: Wed, 25 Aug 2010 17:44:53 +0200
From: Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net>
Subject: Re: Odd file test behaviour on 64 bit windows
Message-Id: <4c753a76$0$6975$9b4e6d93@newsspool4.arcor-online.net>
On 25.08.2010 17:30, Simon Andrews wrote:
> Basically any directories created programatically in Program Files
> aren't showing up in Explorer or a cmd shell. If I use cygwin I can
> see them (and delete them and create them), and the results agree with
> what I see in perl, but they don't show up though the windows API. If
> I create the directories through explorer then they show up
> everywhere.
Probably you do not have enough rights to write to that directory. There
is a folder called "VirtualStore" somewhere in your home directory. Look
there.
This is mainly for old programs which don't care about user profiles and
write directly into the program files folder.
------------------------------
Date: Wed, 25 Aug 2010 08:45:42 -0700
From: sln@netherlands.com
Subject: Re: Odd file test behaviour on 64 bit windows
Message-Id: <4lea7652q5o0osrts9i6a760vs4uvgq6g3@4ax.com>
On Wed, 25 Aug 2010 14:58:13 GMT, malch@malch.com (Malcolm Hoar) wrote:
>In article <7bc0ff5a-ac92-49b1-972c-ca09429b139a@w30g2000yqw.googlegroups.com>, Simon Andrews <simon.andrews@bbsrc.ac.uk> wrote:
>>I'm assuming this is some magic I've not seen before, but I don't know
>>if it's perl or windows which is messing this up.
>
>I'm pretty sure you're seeing some Windows magic that
>takes place with 32-bit apps on a 64-bit O.S.
>
>You are running Perl compiled in 32-bit, right?
>
>If you want to see a true and accurate picture of the
>system disk file system on 64-bit Windows, you need to
>run a version of Perl compiled in 64-bit.
>
>It's not just a Perl issue; you'll see this weirdness
>with other 32 bit apps on 64-bit Windows.
I hope this isn't the case for NTFS. Its basic.
I know someone who uses IE8 32 bit because Flash doesen't
have a 64 bit AX player. Unless you have the basic Office 2010,
most of the standard programs are going to be old 32-bit.
That M$ couldn't handle wow32 file i/o is a scarry thought.
-sln
------------------------------
Date: Wed, 25 Aug 2010 16:23:52 GMT
From: malch@malch.com (Malcolm Hoar)
Subject: Re: Odd file test behaviour on 64 bit windows
Message-Id: <i53g2o260p4002malch@news.sonic.net>
In article <4lea7652q5o0osrts9i6a760vs4uvgq6g3@4ax.com>, sln@netherlands.com wrote:
>>It's not just a Perl issue; you'll see this weirdness
>>with other 32 bit apps on 64-bit Windows.
>
>I hope this isn't the case for NTFS.
It is.
On 64-bit Windows, 64 and 32-bit apps get different
views of the file system because of the File System
Redirector. It doesn't matter if the file system is
NTFS or FAT32 etc.
I certainly found it annoying; my 32-bit file manager
can't see large chunks of the system disk. Try finding
the etc/hosts file with a 32-bit app for example.
But that's the way it is and you might as well get
used to it. If you want a clear view of the system
disk on 64-bit Windows, you'd better use an application
compiled in 64-bit mode.
Once you come to terms with that (which you will have
to do eventually) it will all seem a lot easier ;-)
--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar "The more I practice, the luckier I get". |
| malch@malch.com Gary Player. |
| http://www.malch.com/ Shpx gur PQN. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Wed, 25 Aug 2010 10:56:19 -0700 (PDT)
From: James <hslee911@yahoo.com>
Subject: perl split
Message-Id: <7ff5c1cf-0c05-422f-baf2-7abb152658cb@s17g2000prh.googlegroups.com>
This I understand,
$ perl -le '@a=split//,"abc"; print $#a; print for(@a)'
2
a
b
c
But why this behavior?
$ perl -le '@a=split/(.)/,"abc"; print $#a; print for(@a)'
5
a
b
c
TIA
-James
------------------------------
Date: Wed, 25 Aug 2010 20:28:57 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: perl split
Message-Id: <4c7560e9$0$22913$e4fe514c@news.xs4all.nl>
On 2010-08-25 19:56, James wrote:
> This I understand,
> $ perl -le '@a = split //, "abc"; print $#a; print for @a'
> 2 [...]
>
> But why this behavior?
> $ perl -le '@a = split /(.)/, "abc"; print $#a; print for @a'
> 5 [...]
See perldoc -f split, look for 'parentheses'.
--
Ruud
------------------------------
Date: Wed, 25 Aug 2010 11:32:05 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: Re: perl split
Message-Id: <4dce9bdc-a66c-4a4e-b115-f7e9fa90a9ab@x21g2000yqa.googlegroups.com>
On 25 ao=FBt, 19:56, James <hslee...@yahoo.com> wrote:
> But why this behavior?
> $ perl -le '@a=3Dsplit/(.)/,"abc"; print $#a; print for(@a)'
> 5
>
> a
>
> b
>
> c
Looks normal to me: you split with any character as separator, so you
get:
- an empty string before the separator 'a'
- then, because you have put brackets into the regex, the separator
('a' in this case) is added
- then another empty string between the two separators 'a' and 'b'
- then, again, you have put brackets into the regex, so you get the
second separator ('b' in this case)
- then yet another empty string between the two separators 'b' and 'c'
- finally you get the last separator 'c'
------------------------------
Date: Wed, 25 Aug 2010 11:28:25 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: split on a string that should be interpreted as a regex
Message-Id: <m2pqx6btk6.fsf@sherm.shermpendley.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Sherm Pendley <sherm.pendley@gmail.com>:
>> Klaus <klaus03@gmail.com> writes:
>>
>> > I was thinking that perl (at least perl 5.8) interprets the first
>> > parameter of the split function always as a regular expression, even
>> > if it is a simple string, i.e. if I say:
>> >
>> > split(":\s*", $_, 2)
>> >
>> > then perl interprets this automatically and without warning into
>> >
>> > split(/:\s*/, $_, 2)
>> >
>> > Is my thinking correct ?
>>
>> Nope, sorry. In most cases, if the first argument is a string, it's
>> not interpreted as a regex. The exception is " ", which is interpreted
>> as /s+/.
>
> No. " " is an exception, other strings are treated as a regex. See
> xthread.
Yep, you're right. Mea culpa. :-(
sherm--
--
Sherm Pendley
<camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Wed, 25 Aug 2010 17:25:43 -0400
From: "Paul E. Schoen" <paul@pstech-inc.com>
Subject: Writing or copying file to another directory
Message-Id: <KTfdo.82905$lS1.66031@newsfe12.iad>
I have a simple form mailing script that I've added to. I can get the
results formatted in HTML sent to stdout to appear on the new web page in
the IE8 browser, and I can write the same to a file in the cgi-bin
directory, which is "output.htm" and chdir 777. But I want to write the file
in the directory where the HTML for the submit form is located, and nothing
seems to work. Here is the script with things I tried. I have searched the
docs and FAQs and online but nothing seems to work for a different
directory, which also has the files with 777 permissions.
The HTML with JavaScript is live at
http://www.smart.net/~pstech/SCGBG/EventSubmitJS.htm It checks the Full Name
entry as a simple password. The correct name as coded below will actually
send an email to me.
Any help will be appreciated. Thanks!
Paul
----------------------------------------------------------------------
#!/usr/bin/perl
#
# mailer.pl-- A simple program to mail form data to an email address
#
# Written in 1997 by James Marshall, james@jmarshall.com
# For the latest, see http://www.jmarshall.com/easy/cgi/
#
# IMPORTANT: MAKE SURE THESE TWO VALUES ARE SET CORRECTLY FOR YOU!
# This is the location in smart.net
$mailprog= "/usr/bin/sendmail" ;
$recipient= "paul\@peschoen.com" ; # make sure to \ escape the @
# Get the CGI input variables
%in= &getcgivars ;
if($in{'Full_Name'} ne 'Paul E. Schoen') {
&HTMLdie("Unauthorized user: $in{'Full_Name'}");}
# Open the mailing process
open(MAIL, "|$mailprog $recipient")
|| &HTMLdie("Couldn't send the mail (couldn't run $mailprog).") ;
# Print the header information
$ENV{'HTTP_REFERER'} || ($ENV{'HTTP_REFERER'}= "www.peschoen.com") ;
print MAIL "From: $in{'Email'}\n",
"Subject: Form data from $in{'Full_Name'}\n\n",
"The following data was entered at $ENV{'HTTP_REFERER'}:\n\n" ;
# Find length of longest field name, for formatting; include space for colon
$maxlength= 0 ;
foreach (keys %in) {
$maxlength= length if length > $maxlength ;
}
$maxlength++ ;
# Print each CGI variable received by the script, one per line.
# This just prints the fields in alphabetical order. To define your own
# order, use something like
# foreach ('firstname', 'lastname', 'phone', 'address1', ... ) {
foreach ('Full_Name', 'Email', 'Event_Title','Event_Date','Event_Time',
'Event_Description') {
# If a field has newlines, it's probably a block of text; indent it.
if ($in{$_}=~ /\n/) {
$in{$_}= "\n" . $in{$_} ;
$in{$_}=~ s/\n/\n /g ;
$in{$_}.= "\n" ;
}
# comma-separate multiple selections
$in{$_}=~ s/\0/, /g ;
# Print fields, aligning columns neatly
printf MAIL "%-${maxlength}s %s\n", "$_:", $in{$_} ;
}
# Close the process and mail the data
close(MAIL) ;
# Print an HTML response to the user
$eTitle=$in{'Event_Title'};
$eDate=$in{'Event_Date'};
$eTime=$in{'Event_Time'};
$eDescr=$in{'Event_Description'};
print <<EOF ;
Content-type: text/html
<html>
<body>
<h3>Your data has been sent.</h3>
<p><h3>$eTitle</h3>
<h4>Date: $eDate</h4>
<h4>Time: $eTime</h4>
$eDescr</p>
</body>
</html>
EOF
########## Here's where the problems are; the rest seems to work OK
#################
# Print to the HTML file (write, append, create)
#chdir('/home/pstech/www/SCGBG/'); #still writes to cgi-bin
#open DATA1, '>', "/home/pstech/www/SCGBG/output.txt" or HTMLdie ("File
error: $!"); #No such file/dir
#open DATA1, '>', "output.txt" or HTMLdie ("File error: $!"); #Writes to
cgi-bin OK
open DATA1, '>', "output.htm" or HTMLdie ("File error: $!"); #Writes to
cgi-bin OK
#open my DATA1, '>', "output.htm" or HTMLdie ("File error: $!"); #Internal
server error
#open DATA1, '>', "//home//pstech//www//SCGBG//output.txt" or HTMLdie ("File
error: $!"); #No such file/dir
#copy("output.htm","/home/pstech/www/SCGBG/output.htm") or HTMLdie ("File
error: $!"); #doesn't work, no error
#copy("output.htm","/www/SCGBG/output.htm") or HTMLdie ("File error: $!");
#doesn't work, no error
open DATA1, '>', "output.htm" or HTMLdie ("File error: $!"); #Writes to
cgi-bin OK
print DATA1 <<EOF ;
Content-type: text/html
<html>
<body>
<p><h3>$eTitle</h3>
<h4>Date: $eDate</h4>
<h4>Time: $eTime</h4>
$eDescr</p>
</body>
</html>
EOF
close (DATA1);
#use File::copy; #Internal server error
#copy("output.htm","test.htm") or HTMLdie ("File error: $!"); #doesn't work,
no error msg, clears source file?
#copy("output.htm","../SCGBG/output.htm") or HTMLdie ("File error: $!");
#doesn't work, no error msg
copy("output.htm","output.txt") or HTMLdie ("File error: $!"); #doesn't
work, no error msg
exit ;
...(Subroutines)
------------------------------
Date: Wed, 25 Aug 2010 23:01:23 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Writing or copying file to another directory
Message-Id: <jeggk7-7hb2.ln1@osiris.mauzo.dyndns.org>
Quoth "Paul E. Schoen" <paul@pstech-inc.com>:
> I have a simple form mailing script that I've added to. I can get the
> results formatted in HTML sent to stdout to appear on the new web page in
> the IE8 browser, and I can write the same to a file in the cgi-bin
> directory, which is "output.htm" and chdir 777. But I want to write the file
> in the directory where the HTML for the submit form is located, and nothing
> seems to work. Here is the script with things I tried. I have searched the
> docs and FAQs and online but nothing seems to work for a different
> directory, which also has the files with 777 permissions.
>
> The HTML with JavaScript is live at
> http://www.smart.net/~pstech/SCGBG/EventSubmitJS.htm It checks the Full Name
> entry as a simple password. The correct name as coded below will actually
> send an email to me.
>
> Any help will be appreciated. Thanks!
>
> Paul
>
> ----------------------------------------------------------------------
>
> #!/usr/bin/perl
> #
> # mailer.pl-- A simple program to mail form data to an email address
> #
> # Written in 1997 by James Marshall, james@jmarshall.com
> # For the latest, see http://www.jmarshall.com/easy/cgi/
> #
Where is
use warnings;
use strict;
? Have you read the Posting Guidelines? (The fact you didn't write this
doesn't excuse you.)
> # IMPORTANT: MAKE SURE THESE TWO VALUES ARE SET CORRECTLY FOR YOU!
> # This is the location in smart.net
> $mailprog= "/usr/bin/sendmail" ;
>
> $recipient= "paul\@peschoen.com" ; # make sure to \ escape the @
>
> # Get the CGI input variables
> %in= &getcgivars ;
Don't call subs with '&'.
> if($in{'Full_Name'} ne 'Paul E. Schoen') {
> &HTMLdie("Unauthorized user: $in{'Full_Name'}");}
>
> # Open the mailing process
> open(MAIL, "|$mailprog $recipient")
> || &HTMLdie("Couldn't send the mail (couldn't run $mailprog).") ;
Use multi-arg open.
Use lexical filehandles.
open(my $MAIL, "|-", $mailprog, $recipient)
|| HTMLdie("...");
<snip>
> # Close the process and mail the data
>
> close(MAIL) ;
You are writing to MAIL, so you need to check the return value of close.
<snip>
> # Print to the HTML file (write, append, create)
> #chdir('/home/pstech/www/SCGBG/'); #still writes to cgi-bin
Does this directory exist? Can the CGI process see it? Is the CGI
process running chrooted?
> #open DATA1, '>', "/home/pstech/www/SCGBG/output.txt" or HTMLdie ("File
> error: $!"); #No such file/dir
...apparently not.
> #open DATA1, '>', "output.txt" or HTMLdie ("File error: $!"); #Writes to
> cgi-bin OK
> open DATA1, '>', "output.htm" or HTMLdie ("File error: $!"); #Writes to
> cgi-bin OK
> #open my DATA1, '>', "output.htm" or HTMLdie ("File error: $!"); #Internal
> server error
That's not the right syntax. Perl would at least have told you something
was wrong (the actual error message is less than helpful,
unfortunately).
> #open DATA1, '>', "//home//pstech//www//SCGBG//output.txt" or HTMLdie ("File
> error: $!"); #No such file/dir
Don't just make things up without some understanding of what you are
doing.
> #copy("output.htm","/home/pstech/www/SCGBG/output.htm") or HTMLdie ("File
> error: $!"); #doesn't work, no error
> #copy("output.htm","/www/SCGBG/output.htm") or HTMLdie ("File error: $!");
> #doesn't work, no error
Where do you expect copy() to come from? It's not a builtin.
> close (DATA1);
See above.
> #use File::copy; #Internal server error
Case matters. It's File::Copy.
> #copy("output.htm","test.htm") or HTMLdie ("File error: $!"); #doesn't work,
> no error msg, clears source file?
Unlikely. More likely it was never created in the first place, because
the script failed before it got that far.
Ben
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3098
***************************************
