[6737] in Perl-Users-Digest
Perl-Users Digest, Issue: 362 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Apr 24 09:07:13 1997
Date: Thu, 24 Apr 97 06:00:29 -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 Thu, 24 Apr 1997 Volume: 8 Number: 362
Today's topics:
Re: check command line options? <a.aitken@unl.ac.uk>
Re: How the !@#$%^&* does this relate to comp.lang.java <netscape@oakland.edu>
Re: Lisp is neither (was Re: Ousterhout and Tcl lost th <prasadm@polaroid.com>
Re: Lisp is neither (was Re: Ousterhout and Tcl lost th <prasadm@polaroid.com>
Re: Lisp is neither (was Re: Ousterhout and Tcl lost th (Henry Baker)
Re: Lisp is neither (was Re: Ousterhout and Tcl lost th <colin.oliver@gecm.com>
Re: Lisp is neither (was Re: Ousterhout and Tcl lost th <prasadm@polaroid.com>
Re: NEWBIE regexp q: (David Alan Black)
Re: Perl as its own metalanguage? (Gary D. Duzan)
recursive directtory tree walk (Kevin Mulholland)
Strings everywhere (was Re: Reply to Ousterhout's reply <fbonnet@irisa.fr>
Re: They both suck! (was: Borland or Microsoft compiler <carla@ici.net>
Re: Unix and ease of use (WAS: Who makes more ...) <pattenier@medicine.LeidenUniv.nl>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 24 Apr 1997 12:41:33 +0100
From: Alastair Aitken <a.aitken@unl.ac.uk>
Subject: Re: check command line options?
Message-Id: <335F46ED.6DFD@unl.ac.uk>
Jason Yutao Li wrote:
> I am writting a Perl script which has an -device option. It allows
> users to specify their own tape device name if different than
> the default name:
>
> readtape -device=<tape_device_name>
>
> Inside the script, it looks like this:
>
> $tapeDevice="/dev/mt/tape" # default tape drive name
> $tapeDevice=$device if($device) # user specified tape drive
>
> The problem is, if I mistype the option keyword -device, this script
> will use the default tape drive. In this case, as far Perl is concerned,
> I've never specified -device option. This is NOT a disirable behavior.
>
> How does one trap command-line-option typos ?
Are you using @ARGV to collect the option? If so then you could check
that "-device=<something>" was
in fact received:
if ($ARGV[1]) {
($opt,$val) = split(/=/,$argv[1]);
if ($opt eq "-device") {
$device = $val;
}
}
Alastair.
------------------------------
Date: Thu, 24 Apr 1997 08:35:22 -0400
From: Varner Computer Center <netscape@oakland.edu>
Subject: Re: How the !@#$%^&* does this relate to comp.lang.java.advocacy was Who will win? Borland or Microsoft or Programmers?
Message-Id: <335F538A.70D0@oakland.edu>
John Carling wrote:
>
> rickp@versant.com wrote:
>
> >On Tue, 22 Apr 1997 06:47:18 -0600, Tom Crosman <wcrosman@tecoinc.com>
> >wrote:
> >
> >>M A wrote:
> >>>
> >>> Hi,
> >>> My company is planning to start a project. We have a big question
> >>> about our investments. We don't know if we should use Microsoft
> >>> compiler or Borland. Some myth we heard over the net.
> >>>
> >>> 1) 90% of the programmer uses Microsoft Compiler.
> >>> 2) Borland will vanish in 2 years (NASDAQ:BORL)
> >>> 3) Borland has better compiler
> >>> 4) 99% of the College in US have/use Borland Compiler.
> >>>
> >>> Some one show us the way?
> >>>
> >>> I myself use Borland Compiler and haven't thought about Microsoft yet!
> >>How about not cross posting to groups that are not related.
> >
> >I second the motion. I have seen postings for Sybase, Oracle and
> >other relational databases that were spammed into
> >comp.databases.object. Look at the newsgroups list here. I see only
> >one C++ group.
> >
> >Rick Price
> >
> >
> I AGREE.
I also agree.
------------------------------
Date: Thu, 24 Apr 1997 07:28:00 -0400
From: "M. Prasad" <prasadm@polaroid.com>
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Message-Id: <335F43C0.65D0@polaroid.com>
William Clodius wrote:
>
> Learn your grammar. cpu's is the singular posesive. To prove his point
> all he has to do is give one example. It is a bit much to ask him to
> give examples for a majority of the CPU's available on the market.
Have you learned yours? If it is singular possesive,
it is just bad grammar in the given sentence.
If it is plural (as I assume yours is in the last
sentence above), it means more than one.
------------------------------
Date: Thu, 24 Apr 1997 07:39:25 -0400
From: "M. Prasad" <prasadm@polaroid.com>
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Message-Id: <335F466D.5213@polaroid.com>
Erik Naggum wrote:
> the other day, we could read the following fascinating comments from him:
>
> How about you stop giving Lisp a bad name with these tactics of yours?
> It gives the impression that Lisp is only used by fanatics.
This message of mine was preceded by several quotations
from you, which to me appeared ample justification.
I did not make a target of you for no good reason.
You were out there inserting personal attacks (on
one Mr. Ousterhout) in a technical discussion -- you
should be ready to take your own medicine.
You obviously have a following on the Usenet from
those who enjoy seeing the personal attacks. But
I still don't think Lisp'ers do their cause any
favors by showing wild support to an attitude
like this.
------------------------------
Date: Thu, 24 Apr 1997 13:03:06 GMT
From: hbaker@netcom.com (Henry Baker)
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Message-Id: <hbaker-2404970503060001@10.0.2.1>
In article <yd3esg6hqz.fsf@CLYDE.BOLTZ.CS.CMU.EDU>, Scott Fahlman
<sef@clyde.boltz.cs.cmu.edu> wrote:
> The Lisp Machines had a hellacious learning curve. If you could
> invest the months required to learn all their tricks, they provided a
> software-development environment that has still not been surpassed.
> But even some accomplished Lisp programmers never had time to get over
> "the hump", and non-Lispers faced a really frightening barrier.
> The documentation was designed for people who already knew the answer,
> and Symbolics was remarkably unhelpful unless you wanted to spend a
> week and a few thousand dollars for a training course.
Gee, the courses that Novell & many others teach cost as much or more,
and when you get out, all you know is some real niggly bit-pushing stuff.
I agree that the LispM documentation could have been better for beginners,
but I think that most would agree it left the documentation of most
competitors--including some pretty large companies--in the dust.
------------------------------
Date: 24 Apr 1997 13:23:29 +0100
From: CsO <colin.oliver@gecm.com>
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Message-Id: <u4tcwd2ym.fsf@gecm.com>
"M. Prasad" <prasadm@polaroid.com> writes:
[about Erik Naggum]
> You obviously have a following on the Usenet from
> those who enjoy seeing the personal attacks. But
> I still don't think Lisp'ers do their cause any
> favors by showing wild support to an attitude
> like this.
I don't this Eric has a 'following' or 'wild support' for his
attitude. A few individuals have simply pointed out that if you read
what he says it is often spot on.
BTW I think Eric may have done a lot more for Lispers & their cause
than you give him credit for. Try asking him a question & he might
well try his best to help *you* out.
------------------------------
Date: Thu, 24 Apr 1997 08:22:37 -0400
From: "M. Prasad" <prasadm@polaroid.com>
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Message-Id: <335F508D.717A@polaroid.com>
Rajappa Iyer wrote:
> Erik may have an attitude problem, but what he writes is generally
> right on. Why don't you take the high road and address the relevant
> portions of his post and ignore the attitude?
I have watched this individual insert personal attacks
on an opponent (most recently on Ousterhout,) for no
good reason, in a discussion on something technical.
Personally, I don't like this -- and I think at some point
that _is_ an important issue in itself. Erik very often knows
what he is talking about, but this does not give him
the right to needlessly attack others. I don't
think this should be encouraged.
------------------------------
Date: 24 Apr 1997 10:55:46 GMT
From: dblack@icarus.shu.edu (David Alan Black)
Subject: Re: NEWBIE regexp q:
Message-Id: <5jne7i$kfb@pirate.shu.edu>
Hello -
Eric Kischell <keesh@cs.cmu.edu> writes:
>Hello,
>I am currently reading the "Camel" book in order to learn Perl.
>I have a simple regexp parsing problem.
>I wish to extract specific taggged lines(may include embedded newlines)
>from a file up to but not including the next tagged line(unless the next
>tagged line is the tag that I am currently looking for).
I'm going on the assumption that blank lines occur only as record
separators. This may be wishful thinking, but bear with me.
$/="\n\n";
while (<IN>) { push @found, $_ if /^$mytag/ };
The idea here is to change the input record separator to
two consecutive newlines, and then preserve the desired chunks.
This will result in an array, @found, whose elements will be all
\n\n-separated chunks which begin with $mytag. (You could
add code to strip trailing newlines, if you want.)
If you want to go the route of bringing the whole thing into an
array, make it a hash:
$/="\n\n";
while (<IN>) {
/^(\w+):/;
push @{$taghash{$1}}, $_;
}
This saves the tag in $1, and then uses it as a hash key. The hash
values are list references; the lists contain the found chunks.
So, to get at a list element, you might say:
print $taghash{Report}->[0];
which would print the first element of the list of entries which had
matched "Report".
>Two questions:
>1) Is there anyway to read multiple lines(with embedded newlines) at one
>time up to some tag designation or should I read the file into an array?
>(ie do I need to maintain state info myself?)
See above - I think there are some semi-quasi-answers there. If I'm
wrong about \n\n being uniquely a record separator, then you'd have
to adjust things a bit....
>2) What is wrong with my regexp?
A few things :-)
First, though I haven't tested it, I would think that any regex with
that many alternatives would be monumentally slow.... You should
find another way to make sure that $mytag is a legitimate tag,
outside of the regex (if I'm indeed grasping what you're trying
to do).
>while ( $line = <FILE> ){
> while ( $line =~ m/^$mytag .+? [^$mytags]/gosx )
You're misunderstanding the functioning of the character class.
What you've got there is a pattern which will try to match
exactly *one* character, based on the criterion that the
character not be any of the characters contained in $mytags.
And that's probably most of the letters in the alphabet :-)
The character class isn't going to expand $mytags into
a regex subexpression; it's going to chew it up and spit
out a list of characters.
> {
> print "$1 \n";
There's no $1, because (in addition to the other problems) you
haven't grouped any subexpression in parentheses.
> print "$& \n";
The grizzled sages strongly recommend not using the $&, $`, and
$' variables, because once you use them, subsequent regex
processing becomes less efficient (because it continues to match
and store them, even when you don't need them).
I hope this grabbag is of some help.
David Black
dblack@icarus.shu.edu
------------------------------
Date: 24 Apr 1997 11:50:57 GMT
From: gary@wheel.tiac.net (Gary D. Duzan)
Subject: Re: Perl as its own metalanguage?
Message-Id: <5jnhf1$21b@news-central.tiac.net>
In article <ysizpvvlwai8.fsf@bufo.usc.edu>,
Terrence M. Brannon <brannon@bufo.usc.edu> wrote:
=>Tom Christiansen <tchrist@mox.perl.com> writes:
=>
=>>
=>> [courtesy cc of this posting sent to cited author via email]
=>>
=>> In comp.lang.perl.misc, michaeli@dra.com writes:
=>> :Can you elaborate on this? In C++, at least, you can't overload based on
=>> :return type. I'm having trouble thinking of a construct in C that would
=>> :act differently based on a 'singular' or 'plural' context.
=>>
=>> int i = (1,2);
=>is this C syntax? what does it mean?
In an expression, the "," is a sequencing operator, evaluating the LHS,
then the RHS, and returning the value on the RHS as the expression result.
So, except for evaluating and throwing away the 1, the above is the same
as:
int i = 2;
The parentheses are just there for fun, and provide the usual
subexpression context.
I believe the point was that just by looking at a bunch of values
separated by commas inside parentheses you can't tell if the values
are being kept and passed to a function or thrown away except for the
last one, i.e. "'singular' or 'plural' context."
Gary D. Duzan
Humble Practitioner of the Computing Arts
------------------------------
Date: 24 Apr 1997 12:29:13 GMT
From: kevin@dvstsol.demon.co.uk (Kevin Mulholland)
Subject: recursive directtory tree walk
Message-Id: <5jnjmp$6nf$1@despair.u-net.com>
I am quite new to perl, and I am playing about with it at the moment,
before I have to use it in anger (as it were) however I am getting just a
bit confused at the moment. I am trying to write a subroutine that will
recurse through a directory tree adding file names to a passed in array.
So the subroutine starts
dir_walk( @allfiles, "start directory") ;
I want all the directory filelists to go into @allfiles.
My probleb seems to be that when I recurse into the subroutine again, the
results from the opendir call are not 'saved' into the local 'my' variable
but they are reused, I thought the purpose of my was to make a variable
only for one instance of a subroutine call ?
My other problem is that nothing gets added to my array (@allfiles), do I
need to dereference it to pass it into the subroutine, to allow its use
by all other instances of the subroutine. Using a global is of course
unacceptable as this function will be part of a library (module).
If anyone can give me some (any), advice, pointers, books to read etc.
that would be very helpful.
kpm
included code of what I have got so far
-------------------------------------------------------------------------
#!/usr/bin/perl -w
# quick perl script to test recursive directory tree walk
use English ;
sub dir_walk
{
my( $dir_path, $entry, $recurse) ;
my( @current_dir) ;
# load up the function parameters
( $dir_path, @dir_list) = @_ ;
# open the directory
if( !opendir( DIR, $dir_path))
{
print "dir ", $dir_path, " does not exist\n" ;
return 0 ;
}
#read in entire directory contents
@current_dir = readdir( DIR) ;
closedir( DIR) ;
# find out if directory content is a file or another directory
foreach( @current_dir)
{
# put current value into a handy scaler
$entry = $_ ;
if( -d $entry) # test if a directory
{
print "dir $dir_path/$entry \n" ;
if( $_ ne "." && $entry ne "..")
{
$recurse = join( "", $dir_path, "/", $entry) ;
print " recurse $recurse\n" ;
dir_tree( @dir_list, $recurse) ;
}
}
elsif( -f $entry) # test if a file
{
print "file $entry \n" ;
push( @dir_list, $entry) ;
}
else
{
# catch all for other things like links, devices etc.
print "what $entry\n" ;
}
}
}
# ok here is were we walk through the directory tree.
dir_walk( @alist, ".") ;
foreach( @alist)
{
print "list ", $_, "\n" ;
}
--------------------------------------------------------------------------
end of included code
--
Read the manual - hah - software engineers don't read manuals.
Ah so THAT explains windows95
-----------------------------------------------------------------
homepages http://www.dvstsol.demon.co.uk/kevin
------------------------------
Date: Thu, 24 Apr 1997 13:47:28 +0200
From: Frederic BONNET <fbonnet@irisa.fr>
Subject: Strings everywhere (was Re: Reply to Ousterhout's reply)
Message-Id: <335F4850.2924@irisa.fr>
Hi all,
Erik Naggum wrote:
>
> * Charles Lin
> | Now, perhaps I completely misunderstood what Ousterhout did, but I was
> | under the impression that he said everything in Tcl (the external
> | representation) is a string. Why are we talking about internal
> | representations at all?
>
> because the internal representation in Tcl is the string.
This was true some times ago, but not anymore. See below for more complete
explanation.
> | Internal representations aren't going to be important because they are
> | hidden from the user (mostly).
>
> I think you're missing the point all over the place. Tcl's purpose is to
> glue different applications together, but also to do something with the
> returned "values" (i.e., output) of these programs. of course we're
> dealing with interfaces where external representations will be used, but
> Tcl uses the same external representations for internal purposes, too.
> when you execute a numeric operation, the string is converted to a number,
> the operation is performed, and then converted back to a string. in
> contrast to this view, AWK converts a string to a number when it is used
> for a numeric purpose, and a number to a string when it is used for a
> string purpose, but not otherwise. (at least, this is what I have
> understood from what I have read about Tcl.)
Same as above.
> | The point is that (almost) no one wants to write a program whose
> | *external* representation is numbers.
>
> nobody has suggested they do, and nobody in their right mind would.
Former discussion in this thread was rather ambiguous on this point. Some
suggested to use lists (as in Lisp). Some to use numbers, and gave a way
to represent strings as numbers. But nobody wants to code in numbers! (as
an external representation). Anyway, to be a little extremist, I could
pretend that there's a bijection between every data representation, since
everything in a computer is a vector of _bits_ ;-) Just to caricaturate
former aguments. Enough on that point.
> | Strings are more flexible, if they're the only type you have, as external
> | representation.
>
> but external representations _aren't_ typed!
They are "semantically typed": see below.
> I'd venture that that's the whole point in using an _untyped_ string (or
> even byte-sequence) representation is that whoever reads it would be able
> to interpret it, indeed that type would emerge from the interpretation.
Yes, that's the point.
Ok. Now, why did JO choose strings as external representation?
Let me remind everybody that Tcl means Tool Command Language, and was
intended to glue apps together. JO then choosed to use an external interface
similar to the main() function in C programs, and THAT is the great point
of Tcl, because this kind of interface is well known and widely used since
every C program HAS to use it as an entry point. This was the best choice
IMHO as an external interface for a glue language, and I don't think we
can argue against that. JO didn't choose lists or numbers, not because they
are bad or whatsoever, but because command lines arguments are strings, and
string are the only data structure that is common to any programming language
_as an external interface_ and that there's (nearly) always a string
representation of any data structure. Without performance considerations,
you can represent strings, numbers, lists, trees, and so on, using Tcl lists,
provided you use proper conventions.
Tcl's first intent was to glue programs together. Thus, one programs could
be written in Fortran, one another in C, even in Lisp or anything. Then
every program had to export its external interface as Tcl commands. This
is very easy since it's like writing a main() function. Then you had to
write the Tcl script to glue things together (calling programs via their
external interfaces, passing string arguments and getting back string
results).
Tcl was not intended to act as a programming language by itself. But it's
a fact that many apps that use Tcl are Tcl-only, because there are enough
primitives in Tcl for that. But since everything in Tcl is a string, there's
a huge overhead if the whole program is written in Tcl, while there's little
overhead if Tcl only acts as a glue.
Thus, strings are the only external interface in Tcl, and were the only
internal representation as well until some months ago. Tcl-only procedures
were strings. Number were strings. Lists were strings. And so on. This
wasn't a big deal if Tcl was used as a glue language, but Tcl was quite slow
if used as a stand-alone programming language.
So, and AFAIK due to the increasing number of Tcl-only projects, the Tcl
Team decided to change the internal representation of data. This was a
long time planed project, and many attempts were made before, but the main
challenge was to keep the "everything is a string" semantic of Tcl from
an external point of view, especially regarding the metaprogramming and
dynamic capabilities of Tcl (along with pass-by-name stuff).
So, the current version of Tcl (version 8.0, still in alpha, but soon beta.
First public release in Dec 1996) introduces several changes:
- internal representation is now "objects" (not in the usual meaning).
Now, an "object" still has an external string representation, but can
internally be a string, a list, an integer, program bytecode... And
internal representation can be ubiquitous (it is cached).
- former Tcl strings were C strings. This prevented Tcl from processing
binary strings/data, due to the terminating null char. Now, Tcl strings
know their length and can contain arbitrary characters.
- former Tcl lists were space-separated strings, with {}'s for nesting.
access was in O(n). Now, lists are _real_ lists and access is O(1).
Strings are "aggressively" parsed, and although they remain strings from
an external point of view, they can be used as lists and vice versa. This
results in a major speedup on list commands, and now lists can be used as
compound types, for which arrays were formerly used for performance issue
(use of hash tables).
- Data is now "semantically typed" : string "1" is first a string, then an
integer representation is generated if it's used eg in a math. expression.
"my name is Fred" is a string that is turned into a list when list commands
are used. "puts foo" is a string that can be turned into bytecode if it's
eval'd, and similarly into a list. And so on.
For example :
set i 0
while {$i < 50} {
incr i
puts $i
}
* variable i is set to the string "0"
* "while" command is called with 2 arguments: the strings "{$i < 50}" and
"{\n incr i \n puts $i \n}". While then evaluates the 1st as a logical
expression, thus generates an int representation of i, that is used in
the comparison expression. If the result is true, it then evaluates the
second argument. A bytecode representation is then generated by the
bytecode compiler, and evaluated. "incr i" adds 1 to the value of i, but
it already has an int representation, so it's used instead of the string
representation. "puts $i" prints the string representation of i, but since
it has changed, it has been invalidated and another representation is generated
from the current int representation (well, I think so). Then we test again
the expression {$i < 50} and reevaluate the loop body and so on.
Note that only the first iteration is slightly slower than in previous Tcl
versions, due to the extra computations. But following iterations are much
faster. So if you use Tcl as a glue language, the speed difference is not
significant, but if you use it as an extension language or a standalone
language, then there's a significant speed boost.
So, I think that the "string is bad as an external representation" argument is
irrelevant. Lisp has lists. Prolog has predicates. And so on. I think that the
only relevant argument is what you can do with the language (which has something
to do with the internals), and not which external representation you use.
Last point: there _are_ several implementations of Tcl. Ioi Lam is working on
a promising Tcl interpreter written in Java, called Jacl (Jackal). Its internal
structures will be arbitrary Java objects. See:
http://simon.cs.cornell.edu/home/ioi/Jacl/
So the whole point on "Tcl is bad because everything is a string" is irrelevant.
It's not because an implementation of Tcl uses strings as its internal
representation that it's a Tcl problem: it's the implementation's.
Sorry for the length of this message, but many things that were said about Tcl
(eg "Tcl is a glorified preprocessor") made me wonder which language we were
talking about. Sometimes it was a bit too close to Tcl-bashing on irrelevant
points. There have been major changes in Tcl since its first release. I hope I
refreshed many people's mind.
See you, Fred
--
Frederic BONNET fbonnet@irisa.fr
Ingenieur Ecole des Mines de Nantes/Ecole des Mines de Nantes Engineer
IRISA Rennes, France - Projet Solidor/Solidor Project
------------------------------------------------------------------------
Tcl: can't leave | "Theory may inform but Practice convinces."
$env(HOME) without it! | George BAIN
------------------------------
Date: Mon, 21 Apr 1997 23:21:43 -0400
From: Alicia Carla Longstreet <carla@ici.net>
To: Santiago Mediodia <moony@maptel.es>
Subject: Re: They both suck! (was: Borland or Microsoft compilers ?)
Message-Id: <335C2EC7.4A63@ici.net>
Santiago Mediodia wrote:
>
> Da Borg <vla_di_mip@uniserve.com> escrituras: > [.............]
> > > > My company is planning to start a project. We have a big question
> > > > about our investments. We don't know if we should use Microsoft
> > > > compiler or Borland. Some myth we heard over the net.
> > > >
> > > > 1) 90% of the programmer uses Microsoft Compiler.
> > > > 2) Borland will vanish in 2 years (NASDAQ:BORL)
> > > > 3) Borland has better compiler
> > > > 4) 99% of the College in US have/use Borland Compiler.
> > > >
> > > > Some one show us the way?
> I cant understand why is people still using Microsoft or Borland to
> make projects.
Just maybe they are writing for the largest installed base of PC in the
world, Windows?
> Just, if I see the size of an integer in my Pentium with
> Borland, it gives me 2 bytes so 16 bits, and isnt the size of the integer , the
> the size of the data bus? Something is wrong 'cause Linux gives me 4 bytes
> so 32 bits, and thats really the size of the data bus in a Pentium...
Current versions of Borland C++, and Microsoft Visual C++ both use 32
bit ints. Older versions, which maintain compatability with all
versions of the 80x86, use 16 bit ints.
> Another one, Borland gives me restrictions when i ask for memory. Only 64
> k I think, but not it linux, you can ask for 1, 2 Megas, it doesnt matter
Again, current versions of Borland and Microsoft compilers support full
32 bit flat model memory, so what is the problem.
> Another one. Linux is free so, very cheap, Microsoft or Borland ....
Doesn't help if you need to develop for Windows 95 or Windows NT.
--
********************************************
* Alicia Carla Longstreet carla@ici.net
********************************************
We do not quite forgive a giver.
The hand that feeds us ...
is in some danger of being bitten.
Ralph Waldo Emerson.
------------------------------
Date: Thu, 24 Apr 1997 13:29:06 +0200
From: Hans_Pattenier <pattenier@medicine.LeidenUniv.nl>
Subject: Re: Unix and ease of use (WAS: Who makes more ...)
Message-Id: <335F4402.41C67EA6@medicine.LeidenUniv.nl>
Why the heck is this thread being posted in 14 newsgroups ??
Please restrict your messages to the newsgroups where they belong.
Hans Pattenier
------------------------------
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 362
*************************************
