[9068] in Perl-Users-Digest
Perl-Users Digest, Issue: 2688 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 22 11:07:45 1998
Date: Fri, 22 May 98 08:02:37 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 22 May 1998 Volume: 8 Number: 2688
Today's topics:
Re: sending mail with exchange <rootbeer@teleport.com>
Sequestration <tchrist@mox.perl.com>
SRC: capturing stdout and stderr differently <tchrist@mox.perl.com>
SRC: full duplex comminication with socketpair <tchrist@mox.perl.com>
SRC: printing to more than one filehandle <tchrist@mox.perl.com>
SRC: read a single key without echo or <ENTER> <tchrist@mox.perl.com>
Re: Stop Changing Subject Lines!! (John Porter)
Re: Stop Changing Subject Lines!! (Kevin Reid)
TIP: How to open files <tchrist@mox.perl.com>
TIP: Using magic <ARGV> <tchrist@mox.perl.com>
Re: Tom Christiansen attacks the free software communit (Kees Hendrikse)
Re: Who cares! (John Porter)
Re: Why NOT crypt??? (Jim Allenspach)
Re: Why NOT crypt??? (Mark-Jason Dominus)
Re: Why NOT crypt??? <jgoldberg@dial-but-dont-spam.pipex.com>
Re: Win32 NT Perl Wrapper <camerond@mail.uca.edu>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 22 May 1998 14:03:41 GMT
From: Tom Phoenix <rootbeer@teleport.com>
To: Francesc Guasch <frankie@etsetb.upc.es>
Subject: Re: sending mail with exchange
Message-Id: <Pine.GSO.3.96.980522070031.29577J-100000@user2.teleport.com>
On Fri, 22 May 1998, Francesc Guasch wrote:
> open (MAIL,"|/usr/lib/sendmail -t -f$From")
> or die "Can't send mail: $!";
> $mail->print(\*MAIL);
>
> Now I have to do the same with a NT box that's got
> exchange and I'm afraid.
>
> Will it work the same ?
Yes, if you install Linux first. :-)
If you wish to make a script which can send mail from such different
systems, you should probably consider using a module from CPAN. Even then,
you will likely find some systems which aren't supported. There's no
universal way to send mail, alas.
Good luck with it!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: 22 May 1998 14:29:38 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Sequestration
Message-Id: <6k424i$33n$1@csnews.cs.colorado.edu>
To try to make some amends for the ridiculous amounts of non-Perl crud
and destructive flaming that I was largely responsible for inciting over
the last two days, I have just posted a dozen useful pieces of tips for
doing cool things with Perl. Nearly all of them I've posted before in
one place or another, but often only to private mailing lists, or embedded
in larger messages where the code examples were likely to be missed.
Those examples will find their way into Perl Cookbook, which I must now
buckle down and finish. I won't be posting again until then. PCB is
the answer to the two missing chapters that were ``lost'' between the
first and second editions of the Camel. It has always been our intention
to restore those to you in some form, and this is that form. Actually,
the PCB is very much more than those two missing chapters. The book is
completely filled with quite literally *thousands* of examples, complete
with illustrative prose explanations, which were admittedly largely
omitted from the postings I just made. Its page count will likely be
somewhat higher than anticipated, but that just means more examples.
Here's a table of contents, not counting front-matter or back-matter:
Strings
Numbers
Dates and Times
Arrays
Hashes
Pattern Matching
File Access
File Contents
Directories
Subroutines
References and Records
Packages, Libraries, and Modules
Classes, Objects, and Ties
Database Access
User Interfaces
Process Management and Communication
Sockets
Internet Services
CGI Programming
Web Automation
We only have a week left to add polish before it goes out of our hands
and into that of the production crew. The book will be in print later
this summer, and yes, you'll pay for it. But it is my understanding
that the code segments, such as those I have just posted, will all be
available via anonymous ftp for downloading.
Enjoy.
--tom
http://www.oreilly.com/catalog/cookbook/
--
Unix is like a toll road on which you have to stop every 50 feet to
pay another nickel. But hey! You only feel 5 cents poorer each time.
--Larry Wall in <1992Aug13.192357.15731@netlabs.com>
------------------------------
Date: 22 May 1998 14:03:22 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: SRC: capturing stdout and stderr differently
Message-Id: <6k40ja$r1l$12@csnews.cs.colorado.edu>
To capture a command's stderr and stdout together:
$output = `cmd 2>&1`; # either with backticks
$pid = open(PH, "cmd 2>&1 |"); # or with an open pipe
while (<PH>) { } # plus a read
To capture a command's stdout but discard its stderr:
$output = `cmd 2>/dev/null`; # either with backticks
$pid = open(PH, "cmd 2>/dev/null |"); # or with an open pipe
while (<PH>) { } # plus a read
To capture a command's stderr and discard its stdout:
$output = `cmd 2>&1 1>/dev/null`; # either with backticks
$pid = open(PH, "cmd 2>&1 1>/dev/null |"); # or with an open pipe
while (<PH>) { } # plus a read
To exchange a command's stdout and stderr in order to capture the stderr
but leave its stdout to come out our old stderr:
$output = `cmd 3>&1 1>&2 2>&3 3>&-`; # either with backticks
$pid = open(PH, "cmd 3>&1 1>&2 2>&3 3>&-|");# or with an open pipe
while (<PH>) { } # plus a read
To read both a command's stdout and its stderr separately, it's easiest
and safest to redirect them separately to files, and then read from
those files when the program is done:
system("program args 1>/tmp/program.stdout 2>/tmp/program.stderr");
--tom
--
"SPARC" is "CRAPS" backwards --Rob Pike
------------------------------
Date: 22 May 1998 14:01:39 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: SRC: full duplex comminication with socketpair
Message-Id: <6k40g3$r1l$11@csnews.cs.colorado.edu>
Here's an example of a parent and child in full-duplex communication:
#!/usr/bin/perl -w
# bidirectional communication using socketpair
# "the best ones always go both ways"
use Socket;
use IO::Handle;
socketpair(CHILD, PARENT, AF_UNIX, SOCK_STREAM, PF_UNSPEC)
|| die "socketpair: $!";
CHILD->autoflush(1);
PARENT->autoflush(1);
if ($pid = fork) {
close PARENT;
print CHILD "Parent Pid $$ is sending this\n";
chomp($line = <CHILD>);
print "Parent Pid $$ just read this: `$line'\n";
close CHILD;
waitpid($pid,0);
} else {
die "cannot fork: $!" unless defined $pid;
close CHILD;
chomp($line = <PARENT>);
print "Child Pid $$ just read this: `$line'\n";
print PARENT "Child Pid $$ is sending this\n";
close PARENT;
exit;
}
Some systems have historically implemented pipes as two
half-closed ends of a socketpair. They essentially define
pipe(READER, WRITER) this way:
socketpair(READER, WRITER, AF_UNIX, SOCK_STREAM, PF_UNSPEC);
shutdown(READER, 1); # no more writing for reader
shutdown(WRITER, 0); # no more reading for writer
(NB: On Linux kernels before 2.0.34, the shutdown(2) system call was
broken.)
If you don't have socketpair, but do have pipe (do these people exist?),
you can do this:
#!/usr/bin/perl -w
use IO::Handle;
pipe(PARENT_RDR, CHILD_WTR);
pipe(CHILD_RDR, PARENT_WTR);
CHILD_WTR->autoflush(1);
PARENT_WTR->autoflush(1);
if ($pid = fork) {
close PARENT_RDR; close PARENT_WTR;
print CHILD_WTR "Parent Pid $$ is sending this\n";
chomp($line = <CHILD_RDR>);
print "Parent Pid $$ just read this: `$line'\n";
close CHILD_RDR; close CHILD_WTR;
waitpid($pid,0);
} else {
die "cannot fork: $!" unless defined $pid;
close CHILD_RDR; close CHILD_WTR;
chomp($line = <PARENT_RDR>);
print "Child Pid $$ just read this: `$line'\n";
print PARENT_WTR "Child Pid $$ is sending this\n";
close PARENT_RDR; close PARENT_WTR;
exit;
}
--tom
--
Tactical? TACTICAL!?!? Hey, buddy, we went from kilotons to megatons
several minutes ago. We don't need no stinkin' tactical nukes.
(By the way, do you have change for 10 million people?) --lwall
------------------------------
Date: 22 May 1998 13:50:20 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: SRC: printing to more than one filehandle
Message-Id: <6k3vqs$r1l$8@csnews.cs.colorado.edu>
Ever want one filehandle to connect to more than one file?
You could do this:
for $fh (*FH1, *FH2, *FH3) { print $fh "whatever\n" }
or you could do this:
open(MANY, "| tee file1 file2 file3 > /dev/null") || die $!;
print MANY "data\n" or die $!;
close(MANY) || die $!;
Or you could use a tied filehandle:
use Tie::Tee;
use Symbol;
@handles = (*STDOUT);
for $i ( 1 .. 10 ) {
push(@handles, $handle = gensym());
open($handle, ">/tmp/teetest.$i");
}
tie *TEE, 'Tie::Tee', @handles;
print TEE "This lines goes many places.\n";
Using this module:
package Tie::Tee;
sub TIEHANDLE {
my $class = shift;
my $handles = [@_];
bless $handles, $class;
return $handles;
}
sub PRINT {
my $href = shift;
my $handle;
my $success = 0;
foreach $handle (@$href) {
$success += print $handle @_;
}
return $success == @$href;
}
1;
Or you could have your own tee program, which is more powerful than
the regular one,
$ command | tctee file1 ">>file2" "|cmd" file3 "|cmd3" file4
using the tctee program below:
#!/usr/bin/perl
# tee clone that groks process tees (should work even with old perls)
# Tom Christiansen <tchrist@convex.com>
# 6 June 91
while ($ARGV[0] =~ /^-(.+)/ && (shift, ($_ = $1), 1)) {
next if /^$/;
s/i// && (++$ignore_ints, redo);
s/a// && (++$append, redo);
s/u// && (++$unbuffer, redo);
s/n// && (++$nostdout, redo);
die "usage tee [-aiun] [filenames] ...\n";
}
if ($ignore_ints) {
for $sig ('INT', 'TERM', 'HUP', 'QUIT') { $SIG{$sig} = 'IGNORE'; }
}
$SIG{'PIPE'} = 'PLUMBER';
$mode = $append ? '>>' : '>';
$fh = 'FH000';
unless ($nostdout) {
%fh = ('STDOUT', 'standard output'); # always go to stdout
}
$| = 1 if $unbuffer;
for (@ARGV) {
if (!open($fh, (/^[^>|]/ && $mode) . $_)) {
warn "$0: cannot open $_: $!\n"; # like sun's; i prefer die
$status++;
next;
}
select((select($fh), $| = 1)[0]) if $unbuffer;
$fh{$fh++} = $_;
}
while (<STDIN>) {
for $fh (keys %fh) {
print $fh $_;
}
}
for $fh (keys %fh) {
next if close($fh) || !defined $fh{$fh};
warn "$0: couldn't close $fh{$fh}: $!\n";
$status++;
}
exit $status;
sub PLUMBER {
warn "$0: pipe to \"$fh{$fh}\" broke!\n";
$status++;
delete $fh{$fh};
}
--
MS-DOS is CP/M on steroids, bigger bulkier and not much better.
Windows is MS-DOS with a bad copy of a Macintosh GUI.
NT is a Windows riddled with VMS.
------------------------------
Date: 22 May 1998 13:55:02 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: SRC: read a single key without echo or <ENTER>
Message-Id: <6k403m$r1l$9@csnews.cs.colorado.edu>
This works on any POSIX-conforming system. Term::ReadKey works
on even more.
package HotKey;
@ISA = qw(Exporter);
@EXPORT = qw(cbreak cooked readkey);
use strict;
use POSIX qw(:termios_h);
my ($term, $oterm, $echo, $noecho, $fd_stdin);
$fd_stdin = fileno(STDIN);
$term = POSIX::Termios->new();
$term->getattr($fd_stdin);
$oterm = $term->getlflag();
$echo = ECHO | ECHOK | ICANON;
$noecho = $oterm & ~$echo;
sub cbreak {
$term->setlflag($noecho);
$term->setcc(VTIME, 1);
$term->setattr($fd_stdin, TCSANOW);
}
sub cooked {
$term->setlflag($oterm);
$term->setcc(VTIME, 0);
$term->setattr($fd_stdin, TCSANOW);
}
sub readkey {
my $key = '';
cbreak();
sysread(STDIN, $key, 1);
cooked();
return $key;
}
END { cooked() }
1;
--
"I can only bend the rules so much before it starts looking like I'm breaking
the rules." --Larry Wall
------------------------------
Date: Fri, 22 May 1998 14:05:36 GMT
From: jdporter@min.net (John Porter)
Subject: Re: Stop Changing Subject Lines!!
Message-Id: <MPG.fcf51db3c97fbd69896e8@news.min.net>
On Fri, 22 May 1998 02:50:50 GMT,
in article <87wwbfvx11.fsf@bj2-64.rh.uchicago.edu>,
p-fein@uchicago.edu (Peter A Fein) wrote:
> Look, this GPL/Perl/FSF discussion is very entertaining, but it would
> make some of us *real* happy if you all would stop changing subject
> lines every post. It makes generating a useful killfile damn near
> impossible. I'm all for a good intellectual debate every now and
> then, but these threads have rapidly swamped the perl group.
I set mine to kill messages cross-posted to gnu.misc.discuss.
John Porter
------------------------------
Date: Fri, 22 May 1998 10:28:17 -0400
From: kpreid@ibm.net (Kevin Reid)
Subject: Re: Stop Changing Subject Lines!!
Message-Id: <1d9ej4h.1a1y9zpj2xq8N@slip-32-100-246-193.ny.us.ibm.net>
Peter A Fein <p-fein@uchicago.edu> wrote:
> Look, this GPL/Perl/FSF discussion is very entertaining, but it would
> make some of us *real* happy if you all would stop changing subject
> lines every post. It makes generating a useful killfile damn near
> impossible. I'm all for a good intellectual debate every now and
> then, but these threads have rapidly swamped the perl group.
I'm afraid I don't follow you. What does a kill file have to do with
killing individual threads?
BTW, I think subject lines _ought_ to be changed if the discussion has
strayed from the original topic.
--
Kevin Reid. | Macintosh.
"I'm me." | Think different.
------------------------------
Date: 22 May 1998 13:58:00 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: TIP: How to open files
Message-Id: <6k4098$r1l$10@csnews.cs.colorado.edu>
Every confused about how to get files opened in different
ways? You can use open for a few, but sysopen for most
niceties. To use sysopen, first load
use Fcntl;
To open file for reading:
open(FH, "< $path") || die $!;
sysopen(FH, $path, O_RDONLY) || die $!;
To open file for writing, create new file if needed or else truncate old file:
open(FH, "> $path") || die $!;
sysopen(FH, $path, O_WRONLY|O_TRUNC|O_CREAT) || die $!;
sysopen(FH, $path, O_WRONLY|O_TRUNC|O_CREAT, 0666) || die $!;
To open file for writing, create new file, file must not exist:
sysopen(FH, $path, O_WRONLY|O_EXCL|O_CREAT) || die $!;
sysopen(FH, $path, O_WRONLY|O_EXCL|O_CREAT, 0666) || die $!;
To open file for appending, create if necessary:
open(FH, ">> $path") || die $!;
sysopen(FH, $path, O_WRONLY|O_APPEND|O_CREAT) || die $!;
sysopen(FH, $path, O_WRONLY|O_APPEND|O_CREAT, 0666) || die $!;
To open file for appending, file must exist:
sysopen(FH, $path, O_WRONLY|O_APPEND) || die $!;
To open file for update, file must exist:
open(FH, "+< $path") || die $!;
sysopen(FH, $path, O_RDWR) || die $!;
To open file for update, create file if necessary:
sysopen(FH, $path, O_RDWR|O_CREAT) || die $!;
sysopen(FH, $path, O_RDWR|O_CREAT, 0666) || die $!;
To open file for update, file must not exist:
sysopen(FH, $path, O_RDWR|O_EXCL|O_CREAT) || die $!;
sysopen(FH, $path, O_RDWR|O_EXCL|O_CREAT, 0666) || die $!;
--tom
--
"I have many friends who question authority. For some reason most of 'em
limit themselves to rhetorical questions."
--Larry Wall
------------------------------
Date: 22 May 1998 14:10:16 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: TIP: Using magic <ARGV>
Message-Id: <6k4108$r1l$13@csnews.cs.colorado.edu>
Did you know that when you do:
while (<>)
it does
while (<ARGV>)
which auto-opens, pretty much like
open(ARGV, $ARGV = shift @ARGV);
Did you know that open takes arguments like "foo|" just as
happily as it does "foo"? Look at this:
$ cmd0 | myscript f1 - "cmd1 2>&1|" f2 "cmd2|cmd3|" f3
The program called *myscript* would first open and process the file
``f1''. Then it would open a file named ``-'', a magic file that means
to interpolate standard input, in this case the output from the command
``cmd0''. The next ``file'' in its @ARGV list is ``cmd1 2>&1|'', which
isn't a file at all, but a request to run ``cmd2'' with its standard
error copied into its standard out. Next comes the plain old file ``f2'',
followed by another pipe-looking specification, this one launching two
commands, ``cmd2'' feeding into ``cmd3'' and finally into ``myscript''.
We end finally with a normal file again.
All this is because Perl's *open* is ``magical''--it does special
things for you. And the magic ARGV processing just calls Perl's normal
`open', which means that ARGV, too, is magical! This is very powerful
and flexible. Compare with the tctee example posted a few minutes
ago, which uses the same technique but for output opening.
Of course, magic ARGV is probably not a good idea in a setuid program. Nor
is magic `open', for that matter. But since any security-conscious
program should run under taint mode, and both @ARGV and any user-input
are be default tainted, Perl would catch someone trying to do naughty
things here. For setuid scripts, in fact, it catches it automatically,
even without specifying -T on the command line.
--tom
--
What about WRITING it first and rationalizing it afterwords? :-)
--Larry Wall in <8162@jpl-devvax.JPL.NASA.GOV>
------------------------------
Date: Fri, 22 May 1998 14:15:52 GMT
From: kees@echelon.nl (Kees Hendrikse)
Subject: Re: Tom Christiansen attacks the free software community (was: Re: GNU attacks on the open software community)
Message-Id: <EtD3MG.J8v@echelon.nl>
In <6k3k7m$76l$1@justus.ecc.lu> Stefaan A Eeckels writes:
> In Dutch, some 'bleeding' of the meaning is present, however -
> to indicate that something doesn't accrue taxes, one would say
> 'belastingvrij' (litteraly 'tax free'), whereas the French would
> say 'hors taxe' (litteraly 'without taxes').
>
> It's safe to say that in Dutch the word 'vrij' (which descends
> from the same roots as 'free') has stayed closer to the original
> meaning (which isn't 'gratis') than in English.
I'm not so sure about that. Take for example the dutch 'vrij parkeren' (free
parking) which does mean: no charge for parking. I think in all western
languages the notion of free is dangerously close to 'gratis'.
--
Kees Hendrikse | email: kees@echelon.nl
| web: www.echelon.nl
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 43 37 415
------------------------------
Date: Fri, 22 May 1998 14:04:34 GMT
From: jdporter@min.net (John Porter)
Subject: Re: Who cares!
Message-Id: <MPG.fcf51a191614d219896e7@news.min.net>
On Fri, 22 May 1998 13:16:16 GMT,
in article <slrn6mauip.upr.charlie@cs.ed.datacash.com>,
charlie@antipope.org (Charlie Stross) wrote:
>
> "Given two unrelated technical terms, an internet search engine
> will retrieve only resumes." -- Schachter's Hypothesis
That's great! I've noticed another one:
Given two proper names, an internet search engine will
retrieve only genealogy entries.
John Porter
------------------------------
Date: 22 May 1998 09:05:24 -0500
From: jima@MCS.COM (Jim Allenspach)
Subject: Re: Why NOT crypt???
Message-Id: <6k40n4$3qi@Mercury.mcs.net>
>I agree that all of these are legitimate uses of crypt on sub-Unix (tm)
>systems, but I'm still not sure whether they are that important.
Okay, how about porting over a commercial Unix application that
contains tens of thousands of user names & passwords, the latter having
been crypt()ed? I'm currently having to deal with such a beast at my
place of employment, and a "sub-Unix" version of crypt() seemed to be
the easiest route (other than having the users re-enter their passwords,
which makes the job easier for us, but also causes us to look
technologically puny).
jma
------------------------------
Date: 22 May 1998 10:50:48 -0400
From: mjd@op.net (Mark-Jason Dominus)
Subject: Re: Why NOT crypt???
Message-Id: <6k43c8$365$1@monet.op.net>
In article <6k32ua$h0b$1@comdyn.comdyn.com.au>,
Martien Verbruggen <mgjv@comdyn.com.au> wrote:
>I think you might be talking about a different crypt() here. The C
>function crypt(3) (or 3C on some systems) is AFAIK available on every
>unix system (unless removed for security reasons), and is used to
>'encrypt' passwords. It uses a one way hashing algorithm. There is no
>decoding. The implementation might differ from platform to platform,
>and the value returned by crypt(3) might not be portable between
>systems.
That's right, and the one-way hashing function that it uses is to
DES-encrypt a constant string using your password as the key. Since
it is impossible to deduce the key ffrom knowledge of the plaintext
and ciphertext, this amounts to a one-way hash of your password from
which the original password cannot be recovered.
It's not exactly DES, because they change the S-boxes depending on the
way the salt works, and because the encryption process is iterated 25
times, but it is at the bottom DES, and if you export it you are
exporting the DES algorithm, or a variant of it.
Cite: ``Password Security: A Case History'', Robert Morris and Ken
Thompson. This used to be part of the standard Unix documentation. I
can post an excerpt here if people are interested.
------------------------------
Date: Fri, 22 May 1998 15:57:54 +0100
From: "Jeremy Goldberg" <jgoldberg@dial-but-dont-spam.pipex.com>
Subject: Re: Why NOT crypt???
Message-Id: <6k43r6$jja$1@plug.news.pipex.net>
>> When you want to test scripts locally on a Windoze machine.
>
>Yes, this might occasionally be useful, but if the script is going to be
tied
>that closely to UN*X security, it might be reasonable to test it on an UN*X
>machine.
Really? And if the remote machine doesn't keep error logs? Or if you have no
access beyond FTP? Or you have to do it over a modem when the phone bill is
starting to smoke?
>> When you want to be able to encrypt passwords and the like on scripts
>> running on a Windoze machine.
>
>I must admit that I'm not familiar with Windows technology, but I would
have
>thought that they have their own password encryption format, don't they?
Quite possible... but how do you access it from Perl, then, and still keep
it portable?
>> When you want to send passwords encrypted over the net, but can't (or
>> don't want to) use SSL or a higher-grade encrypt scheme.
>
>Sounds like a terrible idea, security-wise, unless you use it as a
>challenge/response scheme with one side sending the salt and the other
sending
>the encrypted password.
As a simple alternative to nothing at all, it can't be beaten.
>I agree that all of these are legitimate uses of crypt on sub-Unix (tm)
>systems, but I'm still not sure whether they are that important.
It's not a question of important, it's a question of being able to do it at
all. As it stands, you have to write your code, upload it, and then run it
and see if it works properly - no exhaustive testing offline, unless you can
install Linux - which isn't always a practical answer either, or none of us
would use Windoze in the first place.
------------------------------
Date: Fri, 22 May 1998 09:59:44 -0500
From: Cameron Dorey <camerond@mail.uca.edu>
To: Gurusamy Sarathy <gsar@engin.umich.edu>
Subject: Re: Win32 NT Perl Wrapper
Message-Id: <356592E0.CA9030E8@mail.uca.edu>
[cc'd to gs]
Good morning, Gurusamy,
Gurusamy Sarathy wrote:
>
[snip about AS Win32 port]
>
> As for the necessity of wrappers, consider the fact that file associations
> are broken for redirections. Or that they're not available in
> poor-mans-win32 (aka Windows95).
Maybe I misunderstand you here and/or file associations, but in using
your Win32 port under Win95, I "associated" .pl files with perl.exe just
like you do in NT and can double-click on a script and get it to run,
such as the simple example below (testassoc1.pl):
#!/dummy_path_to_perl -w
open (OUTFILE, ">c:/testfile.txt") || die "open: $!";
print OUTFILE "This is a test.";
close (OUTFILE) || die "can't close c:/testfile.txt: $!";
A DOS box appears for an instant, closes, and testfile.txt shows up in
the c: directory just fine. Am I missing something here, are we talking
apples and oranges?
>
> - Sarathy.
> gsar@umich.edu
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 2688
**************************************
