[6691] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 316 Volume: 8

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 16 14:17:21 1997

Date: Wed, 16 Apr 97 11:00:34 -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           Wed, 16 Apr 1997     Volume: 8 Number: 316

Today's topics:
     Re: "Dummies" book any good? <sfarrell@phaedrus.uchicago.edu>
     Re: Array Elements <dehon_olivier@jpmorgan.com>
     Camel Book example Question (P. Pitton)
     Re: Camel Book example Question <sib@worldnet.att.net>
     Re: HELP! Trying to automate creation of hundreds of ne (David Stoner)
     Re: HELP: Recursive directory mapping (David Stoner)
     Re: Needed: Perl-based mailto filter (Shaug Evans)
     Re: Newbie question (very stupid question I suppose) (Lars Gregersen)
     Re: Ousterhout and Tcl lost the plot with latest paper (Alaric B. Williams)
     Re: Ousterhout and Tcl lost the plot with latest paper (Scott Schwartz)
     Re: Perl and recursion (Amol Kabe)
     Q: How to make a dirhandle local to a subroutine? (David Stoner)
     Reading One Character at a time (David Waring)
     Re: Reply to Ousterhout's reply (was Re: Ousterhout and (Alaric B. Williams)
     Re: Reply to Ousterhout's reply (was Re: Ousterhout and (Alaric B. Williams)
     Shadow password probleme with Perl 5.003 on Solaris 2.5 <jfweber@if.insa-lyon.fr>
     Solved! -- questions about timelocal.pl <philipp@ntex.com>
     Re: Solved! -- questions about timelocal.pl <tchrist@mox.perl.com>
     Re: Unix and ease of use  (WAS: Who makes more ...) (Tom Wheeley)
     Re: Unix and ease of use  (WAS: Who makes more ...) (Tom Wheeley)
     Re: Unix and ease of use  (WAS: Who makes more ...) (Tom Wheeley)
     Re: What does "UNIX" stand for.. <ron@sensor.com>
     Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Wed, 16 Apr 1997 16:54:55 GMT
From: stephen farrell <sfarrell@phaedrus.uchicago.edu>
Subject: Re: "Dummies" book any good?
Message-Id: <87sp0qrjq8.fsf@phaedrus.uchicago.edu>

jon@amxdigital.com (Jonathan Peterson) writes:

> On Tue, 15 Apr 1997 20:20:44 -0700, "Charles F. Ritter"
> <critter@quack.kfu.com> wrote:
> 
> >Tom Christiansen wrote:
> >> 
> 
> >> Nonetheless, attempting to learn Perl from its reference
> >> work may be similar to learning English with only a dictionary.
> >> 
> 
> >The camel book is twice as interesting the second time through and ten
> >times as interesting on the third read.
> >
> >Come to think of it... so is the dictionary. :-)
> 
> Doubtless I'l get in trouble for this, but...
> 
> I learnt to program with Commodore64 basic. After my C64 broke down, I
> slowly forgot how to program, until I got an old 386, and learnt to
> program qbasic.
> 
> People familiar with either of these 'languages' will know that they
> are not elegant by todays standards. However, by the time I came to
> learn Perl ( initially from tutorials found on the net, then from the
> cammel), I realised just how much I knew. I knew what a variable was.
> I knew what an array was. I was familiar with for... next loops. I
> knew what a subroutine was (anyone remember gosub ? :).
> 
> Knowing this makes it MUCH easier to learn how to use Perl's list
> handling functions and regexps, because you feel so much more
> confident with the rest of it. For a real, genuine, absolutely never
> programmed before not even Dos batch files or Word macros person, I
> think you really need to start with stuff like what a variable is, and
> spend a long time on it.
> 
> If you have never programmed anything before, I think Perl is not an
> ideal starting place. This is NOT because Perl is inherently difficult
> (as many people think...), but because Perl is inherently clever, and
> writers of books are so eager to show the cleverness, they take the
> simple things as read.
> 
> Explaining to a real beginner that:
> 
> if ($a == 1) {
> 	print ("Whee!");
> 	}
> 
> is the same as
> 
> $a || print ("Whee!");

no it's not.

> 
> is not something that you can do in a few sentences. More like a few
> chapters.
> 
> I suggest you learn a clumsy, clunky old thing like basic. Then you'll
> be impressed by Perl's cleverness, and able to make use of it without
> getting confused over the basics.
> 
> 
> -----
> Jon Peterson.
> Views expressed are mine, not AMXdigital's.
> Look young! Feel young! Die young!
> ----
> AMXdigital: +44 171 613 5300 www.amxdigital.com
> jon@amxdigital.com


------------------------------

Date: 16 Apr 1997 18:29:31 +0100
From: Olivier Dehon <dehon_olivier@jpmorgan.com>
Subject: Re: Array Elements
Message-Id: <njzenca3mh0.fsf@jpmorgan.com>

tvs@lord.banki.hu (Tamas Vincze) writes:

> 
> In comp.lang.perl.misc Gary W. Chambers <geecee@gwi.net> wrote:
> : Can someone offer definitive information on obtaining the number of 
> : elements in an array?  Camel and Llama are vague, and I'm using:
> 
> If you have the array @array, then just say:
> 
> print "The number of elements is $#array\n";

>From the perldata manpage:

     $#days		# the last index of array @days

which can be, and is most of the time, different from the
number of elements of the array, since the first element of
an array has the index held in the predefined var $[.
This means that $#days is the number of elements minus 1 by default.

>From the perlvar manpage :
     As of Perl 5, assignment to "$[" is treated as a compiler directive,
     and cannot influence the behavior of any other file.  Its use is
     discouraged.

Use scalar(@array) to get the number of elements. This forces @array
to be evaluated in a scalar context.

Hope this helps.
Olivier Dehon.


------------------------------

Date: 15 Apr 1997 10:55:07 GMT
From: ppitton.quada@t-online.de (P. Pitton)
Subject: Camel Book example Question
Message-Id: <5ivmqb$v0n$1@news01.btx.dtag.de>

I have a question concerning an example in the Camel-Book, page 226
named "printing lines after a designated matching line".

There is the procedure:
  perl -ne 4print if (/REGEX/ ? ($c=LINES) : (--$c > 0))4 FILES

Could anyone who understands this explain it in detail to me ?
I don4t understand the inside of the parentheses, the ? and : look so
strange to me.

Thanks for any help in advance,

Peter




------------------------------

Date: Wed, 16 Apr 1997 13:42:19 -0400
From: Scott Blanksteen <sib@worldnet.att.net>
Subject: Re: Camel Book example Question
Message-Id: <33550F7B.6A6D@worldnet.att.net>

P. Pitton wrote:
> There is the procedure:
>   perl -ne 4print if (/REGEX/ ? ($c=LINES) : (--$c > 0))4 FILES
> 
> Could anyone who understands this explain it in detail to me ?
> I don4t understand the inside of the parentheses, the ? and : look so
> strange to me.

Let's start with the command-line switches:
  -e   Used to enter one or more line of Perl code directly to the
interpreter, rather than reading from a file.

  -n   Causes Perl to iterate over the file names specified on the
command line.

Next, let's look at the actual Perl code:

1.   CONDITION ? IF-YES : IF-NO

This expression, just as in C, evaluates to IF-YES if CONDITION is 
TRUE and IF-NO otherwise.


2.   /REGEX/

This is a pattern-matching (sometimes called 'regular expression'
operation.  By default, it tries to match 'REGEX' with the contents 
of the current line.  If it matches the current line, it evaluates
to TRUE, if not, FALSE.


3.   (--$c > 0)

This operation decrements the variable $c (reduces it by 1) and 
compares the result to 0.  Its value (TRUE or FALSE) is the result 
of the comparison.

4.   print if CONDITION

This prints the current line iff CONDITION is TRUE.


So, the program works as follows:
  for each FILE in FILES {
    for each LINE in FILE {
      If a LINE matches the REGEX you specify {
        Set $c to the number of lines you want to print
        Print the current line
      }
      Otherwise {
        decrement $c (reduce $c by 1)
        Print the current line if $c is still greater than 0
      }
    }
  }

> Thanks for any help in advance,

You're welcome.

Scott


------------------------------

Date: 15 Apr 1997 21:11:02 GMT
From: dstoner@marlin.utmb.edu (David Stoner)
Subject: Re: HELP! Trying to automate creation of hundreds of new email accounts
Message-Id: <5j0qt6$5kn@atlantis.utmb.edu>

Kirk Sansom (ksansom@worldnet.att.net) wrote:
: HELP! Trying to automate creation of hundreds of new email accounts

: This message is being cross-posted, please excuse any duplication.

: I'm desperate!  I've got to create hundreds of user e-mail accounts in the next few weeks on our SGI Origin 200 server running Irix 6.3.  No one on our staff is proficient in Unix or programming and they're all satisfied to do the steps manually, one-by
-one, the way our sorry excuse for a sales rep showed us.  I simply refuse to accept that in a made-for-programmers operating system, there's not an easier, more automated way to add directories with the proper ownership, mode, etc.

: Adding users is not the problem.  Even though the adduser applet does not exist in this system, it's still pretty easy to add users by editing the passwd file.
: But, I'll be darned if there isn't an easier, faster way to create, modify user directories for e-mail storage.  I've been experimenting with trying to automate the following on my linux machine at home with the bash shell:

: 1) create the new user's directory in /usr/people/
: 2) change directory owner from root to the new user
: 3) change directory mode to 500
: 4) change directory group to user
: 5) list the directory to insure changes are correct

: First I tried this running this executable script file:

: {
:  for file in $*
:    do
:    mkdir {$file}
:    chown {$file} {$file}
:    chmod 500 {$file} 
:    chgrp user {$file}
:  done
: }
: ls -l

: I entered the command with one variable, but it wouldn't work so I tried this:

: mkdir $1
: chown $1 $1
: chmod 500 $1
: chgrp user $1
: ls -l

: The first time, it worked perfectly, but would only execute the first line after that.

: I'm trying to teach myself Perl scripts in my spare time, but right now I just don't have any spare time to learn, and by the time I do, the user accounts will have to be finished.

: P.S.  Our SGI machine is setup for csh shell, I'm trying (learning) to install the bash shell and put it in the path, but for now, csh is it.

: Thanks for any suggestions,

: ks


My first suggestion would be not to use csh, especially not for root.  Most
systems I've seen recommend that root have the Bourne Shell /bin/sh for its
default shell.  Conventions for Irix may be different.  You can change any
account's default shell by editing that account's line in the /etc/passwd
file.  Look around and see if your system has the Korn Shell on it:

	find / -name ksh -ls

The Korn Shell syntax is much more like that of /bin/sh, and the lines you 
wrote above have a better chance of working.

The worst part about automating the creation of user accounts is setting the
passwords, since the passwd command insists on taking its input from a terminal.
The Expect language (an extension of Tcl) is good for things like that, but
that may be a long detour.  A trick you may be able to get to work (though
I never have) is to call passwd through rsh (remote shell).

David


--
__
UTMB Information Services
David.Stoner@utmb.edu
dms@atlantis.utmb.edu dstoner@marlin.utmb.edu  usenet@utmb.edu news@utmb.edu
help@marlin.utmb.edu




------------------------------

Date: 15 Apr 1997 20:48:22 GMT
From: dstoner@marlin.utmb.edu (David Stoner)
Subject: Re: HELP: Recursive directory mapping
Message-Id: <5j0pim$5kn@atlantis.utmb.edu>

Ameer Badri (abadri@worldnet.att.net) wrote:
: Hi,
: I will appreciate if someone can help me with the following problem.   I am
: looking for piece of  Perl code to recursively map a given directory for a
: specific file type (ex. *.html).

: Thanks for your time and help,

: Ameer


Below is a script that solves a similar problem.  Perhaps it will give you
some ideas.  My script searches a directory tree for directories with names
of a special form which indicates that they contain old mail folders.  Within
those directories it searches for folders containing old news-server daily
reports.  Within those reports it searches for the names of newsgroups accessed.
It prints a list of all groups found to have been accessed and a count of the
number of accesses.   Note that the "workdir" subroutine is recursive.

A problem I had with this script is that I could find no way to make the 
dirhandle MYDIR local to the subroutine "workdir", so different instances of
workdir clobbered each other's dirhandles.  The workaround for this is
what you see below:  workdir opens a directory and immediately reads all
entries into an array and closes the directory.  This is inefficient, and
it ultimately made the script useless for my purposes, since it meant that
Perl runs out of memory and stack space on moderate-sized filesystems.  I
commented out what should have been the main routine and substituted a line
that called workmf on a single file.

If anybody can tell us how to make dirhandles local, or if you only need to
search small directory trees, something like this may help you.   If you're
working with a Unixy system, something like this might suffice:

find . -name "*.exe" -print

David

================================= findbusy script =========================
#!/usr/bin/perl -w
$curdir = $ENV{'PWD'};
$ng = qq{(?:[\\w-]+)};
$ngs = qq{(?:$ng(?:\\.$ng)+)};
$startdir = $ARGV[0] || die("no directory specified");
$target = "big";
#&workdir($curdir . "/" . $startdir);
#print(%groups);
&workmf("/usr4/dms");
for $index (keys(%groups)) 
	{
	print($index,": ",$groups{$index},"\n");
	}

sub workdir
{
my($dir) = $_[0];
chdir($dir);
my($findex,$file,@files);
if (!opendir(MYDIR,"."))
	{
	die "cant open directory $dir \n" ;
	}
my($findex) = 0;
while($file = readdir(MYDIR))
	{
	$files[$findex++] = $file;	
	}
closedir(MYDIR);
for($findex = 0;$file = $files[$findex];$findex++)
	{
	if($file ne "." && $file ne "..")
		{
		if(-d("$file") )
			{
#			print("process directory",$dir,"/",$file,"\n");
			if($file =~ m{^mail\.d(\.\d+)?$})
				{
				&workmf($dir . "/" . $file);
				}
			workdir($dir . "/" . $file) ;
			}
		else
			{
#			print("uninteresting file",$dir,"/",$file,"\n");
			}
		}
	}
chdir("..");
}

sub workmf
{
my($dir) = $_[0];
chdir($dir);
my($findex,$file,@files);

if(-f($target))
	{
	print("FOUND ",$dir,"/",$target,"\n");
	if ( open(INFILE, "<$target" ) ) 
		{ 
		while(<INFILE>)
			{
			if(m{^Newsgroup request counts \(by newsgroup\)\s*$}) 
				{
#				print("found request counts\n");
				while(<INFILE>)
					{
					if(m{^($ngs)\s+(\d+)\s*$})
						{
#						print("::",$1,"::",$2,"::\n");
						if(exists($groups{$1}))
							{
						$groups{$1} = $groups{$1} + $2;
							}
						else
							{
							$groups{$1} = $2;
							}
						}
					else
						{
						last;
						
					}
				}
			}
		close(INFILE);
		}
	else
		{
		print("cant open input file",$dir,"/$target\n") ;
		}
	}
chdir("..");
}
================================================================================



--
__
UTMB Information Services
David.Stoner@utmb.edu
dms@atlantis.utmb.edu dstoner@marlin.utmb.edu  usenet@utmb.edu news@utmb.edu
help@marlin.utmb.edu




------------------------------

Date: 16 Apr 1997 00:49:36 GMT
From: shaug@callamer.com (Shaug Evans)
Subject: Re: Needed: Perl-based mailto filter
Message-Id: <5j17n0$a1a$1@zinger.callamer.com>

In article <slrn5kvhfp.187.cbbrowne@knuth.brownes.org>,
	cbbrowne@news.brownes.org (Christopher B. Browne) writes:

 ...
> 
> longname=name&email=address&phone=telno&contacttype=dunno&big6=&client=&compan
> y=&region=dunno&province=&city=&sapsystem=dunno&db=dunno&os=mscrap&connect=&tr
> avel=dunno&dresscode=dunno&paybasis=dunno&amount=&perwhat=year&vacation=dunno&
> text=
> 
 ...

> But if someone has written something that makes the data (for
> instance) look like what you'd have going into a CGI script, 'twould
> be nice to be able to "Steal this Code."  I'd written a Perl CGI
> script to process the form; it would be really nice to be able to use
> that code.

 If you already have a form parser that does what you want, shouldn't you
 be able to pass it the body of your "mailto" message (i.e. header stripped
 out), and get the results you're looking for?  If your form parser can
 read "POST" CGI input, than it should be expecting a string such as your
 example on STDIN.

 As a side note, your question really belongs in comp.infosystems.www.
 authoring.cgi.



------------------------------

Date: Thu, 10 Apr 1997 12:42:29 GMT
From: lg@kt.dtu.dk (Lars Gregersen)
Subject: Re: Newbie question (very stupid question I suppose)
Message-Id: <334cde5e.111693106@130.228.3.8>

On Thu, 10 Apr 1997 03:51:18 -0600, sikke600@hio.tem.nhl.nl wrote:

>Hi,
>I am new to perl and I have a question:
You don't say :-)

< lots of text irrelevant to this group deleted>
>The bit I am curious about is the if-it, the rest I understand I think.
You can test the equality of strings using the operator
  eq  (which means equal)
  ne  (which means not equal)
Only for the comparison of numbers can you use == and !=

So if you want to check if $foo is not equal to "bar" you write
if ($foo ne "bar")
 ...

Get a book (on perl that is) or at least read the documentation that
comes with perl (perlop).

You problem started out with something being CGI related (which it
isn't). Try to post those questions in:
comp.infosystems.www.authoring.cgi

For your counter/CGI problems you might also try to look at the site:
http://www.worldwidemart.com/scripts/

I hope this helps

  Lars

Lars Gregersen
Technical University of Denmark
Department of Chemical Engineering
E-mail  : lg@kt.dtu.dk
Homepage: http://www.gbar.dtu.dk/~matlg/


------------------------------

Date: Wed, 16 Apr 1997 17:09:56 GMT
From: alaric@abwillms.demon.co.uk (Alaric B. Williams)
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Message-Id: <3355045a.1739551@news.demon.co.uk>

On 15 Apr 1997 12:26:24 +1000, Chris Bitmead
<Chris.Bitmead@alcatel.com.au> wrote:
>alaric@abwillms.demon.co.uk (Alaric B. Williams) writes:

>> How do you defined "power"? I have seen two definitions in languages:

>I personally would definitely go with 2) as the correct definition. 1)
>has it's uses but I wouldn't call that general purpose
>"power". According to that definition, assembler is a super-powerful
>language. To me this is absurd. Assembler has it's uses, but powerful
>isn't an adjective I'd use.

The major attitude I find amongst UNIX/C people is that assembler is
the ultimate in power, but also hard to use. C is pandering to
the user's needs, and thus drops in power. I have been told that
Linux is hard to configure because it is "so powerful", in that
you have to tell it the intimate details of your system - such
as telling X the dot clock rate for your graphics system!!!

When they look at languages like Scheme, TCL, or whatever, the
immediate reaction is "What an unpowerful language". I've got
an ongoing discussion thread with a long time C user archived,
but it gets a bit personal in places, so I'd better not post
it :-)

>> Low Level Power:

>> 1) C++

>Ok, most people would put C++ first in the so-called "low-level" power
>stakes. But it doesn't all go C++'s way. You define low level power as
>the power to control implementation. Consider that C++ is a strictly
>stack based language. Unlike Scheme, (or assembler with some tricky
>mucking around), you can't have multiple "stack-like" environments all
>existing at once. (i.e. continuations and call/cc).
>
>This is a powerful low level feature that C took away from assembler,
>but Scheme allows.

Yes, good point; however, C++ people don't realise it's a useful
feature (no offence, guys!)

I think the difference is that C++ has lost this "power" since the
problems for compiler generation against little perceived use 
(back then, structured programming was the ultimate technology,
so I guess people got a little overexcited :o) made it seem
worthless, a "nasty" implementation detail of assembler we could
do best without. Continuations are a nice way of providing this
power without getting into hairy addresses and stack pointers.

>> High Level Power:

>In the high level power stakes, I think we must still put TCL last. If
>we take your definition of being able to do major things with simple
>pieces of code, I think TCL lacks the ability to do major things. TCL
>can nicely _control_ major things, where those major things are
>implemented in say C, but it can't nicely _implement_ major things.

Huh - from all the retorick here, I had a better impression of it.
Can't judge a book by it's cover :-(

But then again, perhaps we need to define the distinction of the
edge of the language better. A tiny gluing language with an immense
set of freely available libraries is, evidently, quite a powerful
tool. Like Scheme with /optional/ Common Lisp libraries! In this
case, the design of the language is to glue bits together, and as
such it's not expected to do much on it's own. So we would hope
that TCL gets things done by delegation.

However, I suspect the model is more of providing specific-purpose
tools to TCL programs, and then letting them control the overall
flow of execution. This is where it gets poor, since we have
monolithic foundations, which a house of TCL straw is then built
upon. If these modules were more abstract, general, things -
such as the way that arithmetic operators are added to a simple
LISP core system, and now it can do arithmetic just like any other
language, rather than coding all the arithmetic in C and linking
it into LISP - then we would have perhaps acheived a useful goal.

>So.. 1) Scheme 2) C++ (reluctantly) 3) TCL.

:-(

>The extent to which TCL is "powerful" is basicly because it is
>typeless. It gives programmers the illusion that they can do a lot
>without a lot of preparation and mucking around. This is a good thing!
>But I wouldn't like to sacrifice true language "power" to get it if I
>didn't have to.

Agreed.

ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."

(Windows for Early Warning and Defence User's manual P26)

Alaric B. Williams Internet : alaric@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>


------------------------------

Date: 16 Apr 1997 13:41:19 -0400
From: schwartz@galapagos.cse.psu.edu.NO-SPAM (Scott Schwartz)
To: wilson@cs.utexas.edu (Paul Wilson)
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Message-Id: <8g4td66f28.fsf@galapagos.cse.psu.edu>

wilson@cs.utexas.edu (Paul Wilson) writes:
| The main defense seems to be that "I use it already, and other
| people use it already, so we're going to stick with it and
| recommended it to others, whether or not it's fundamentally lame."
| (Sorry to put it in such an extreme way, but that's pretty much how
| I see it.)

Most langauges are lame, and their proponent's positions sound just
like what you've described.



------------------------------

Date: Wed, 16 Apr 1997 17:32:17 GMT
From: kabe@netcom.com (Amol Kabe)
Subject: Re: Perl and recursion
Message-Id: <kabeE8qrDt.DxJ@netcom.com>

David Alan Black (dblack@icarus.shu.edu) wrote:
: kabe@netcom.com (Amol Kabe) writes:
: Hello -

: %aliases is going to soak up all the values in @_, so
: nothing will be assigned to $alias or $members.

: Either pass a reference to %aliases, or put your non-greedy
: variables first:

: my ($alias, $members, %aliases) = @_;

: (and adjust function calls accordingly)


	That was it!  Thanks for saving my sanity.
-- 

	Amol Kabe  		-oO0Oo-			kabe@netcom.com     
	         "we can speak of an object as a blessed thingy." 
			Programming Perl, 2nd ed. 


------------------------------

Date: 15 Apr 1997 21:31:40 GMT
From: dstoner@marlin.utmb.edu (David Stoner)
Subject: Q: How to make a dirhandle local to a subroutine?
Message-Id: <5j0s3s$5kn@atlantis.utmb.edu>

How can I make a dirhandle local to a subroutine?

As mentioned in a previous article, I wrote a recursive subroutine in Perl to
traverse a tree of directories, but I could find no way to make the dirhandle
local to the subroutine, so different instances of the subroutine clobbered
each other's dirhandles.  I worked around the problem by having the subroutine
read the entire directory into an array and close it before the subroutine
called itself.  That makes the routine a memory hog, so it fails on moderate-
sized filesystems.

Any help much appreciated.

David


--
__
UTMB Information Services
David.Stoner@utmb.edu
dms@atlantis.utmb.edu dstoner@marlin.utmb.edu  usenet@utmb.edu news@utmb.edu
help@marlin.utmb.edu




------------------------------

Date: Wed, 16 Apr 1997 10:35:42 -0700
From: dwaring@fhcrc.org (David Waring)
Subject: Reading One Character at a time
Message-Id: <dwaring-1604971035420001@140.107.20.146>

I'm new to Perl, so forgive me if this question is simple, but I have
consulted the camel and the llama without finding the answer. I am writing
a CGI where I receive as one variable, a sequence of characters (it is DNA
sequence)  I have to check that all the characters are in the set of
acceptable characters (16 characters).  What is the best way to do this?

As best I can tell I must test each character individually. If I could
read them into an array it would be easy, but there will be no spaces
between them and thus no delimiter.

Any suggestions would be appreciated.

David Waring


------------------------------

Date: Wed, 16 Apr 1997 17:09:47 GMT
From: alaric@abwillms.demon.co.uk (Alaric B. Williams)
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <3354fe65.214638@news.demon.co.uk>


On 15 Apr 1997 13:46:39 GMT, bspencer@bassun.perfect.att.com (Brad
Spencer) wrote:

>   Remember LOGO; a LISP derivative used for teaching youngsters to
>   program...
>
>Hmmmm...
>
>I think that this was later.  I seem to recall that the original goal
>of LOGO was to control a robot arm [at, I believe, MIT].

I didn't say it was a design goal at first. But education
was what it became famous for!

ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."

(Windows for Early Warning and Defence User's manual P26)

Alaric B. Williams Internet : alaric@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>


------------------------------

Date: Wed, 16 Apr 1997 17:09:52 GMT
From: alaric@abwillms.demon.co.uk (Alaric B. Williams)
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <3354feb6.295514@news.demon.co.uk>


On 15 Apr 1997 06:30:47 GMT, Tom Christiansen <tchrist@mox.perl.com>
wrote:

>In comp.lang.perl.misc, 
>    alaric@abwillms.demon.co.uk (Alaric B. Williams) writes:
>:OTOH, for the penultimate extension of LISP, look at Common LISP and
>:Emacs!

>Since when does penultimate mean anthing other that second-to-last?

Ultimate is reserved for future use. Future proofing, you see;
something bigger may yet arise.

>--tom
>-- 

ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."

(Windows for Early Warning and Defence User's manual P26)

Alaric B. Williams Internet : alaric@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>


------------------------------

Date: Wed, 16 Apr 1997 20:14:20 +0200
From: Jean-Francois Weber <jfweber@if.insa-lyon.fr>
Subject: Shadow password probleme with Perl 5.003 on Solaris 2.5
Message-Id: <335516FC.5D5D@if.insa-lyon.fr>

Hi,

I'd compiled Perl 5.003 on a Solaris 2.5 box.
When I use the getpwuid function, I get the password filed of my
/etc/passwd, not the field in /etc/shadow as said in the faq.
Had anybody the same problem ?
Can someone help to work around it ?

Answer by mail if possible.

Thanks in advance
--
Jean-Francois Weber               INSA de LYON              Sys-Admin
Dept If -F69621 VILLEURBANNE		e-mail: jfweber@if.insa-lyon.fr


------------------------------

Date: Wed, 16 Apr 1997 00:28:53 -0700
From: "Philip A. Prindeville" <philipp@ntex.com>
Subject: Solved! -- questions about timelocal.pl
Message-Id: <33547FB5.46A3@ntex.com>

Philip A. Prindeville wrote:
> 
> I have a question about timelocal.pl.

I've solved this problem.  A module that I was including via "use"
was also requiring this file.  It was doing a straight:

require 'timelocal.pl';

In my program I was also requiring this file.  But since the
module was being "use"d (and hence got evaluated at compile time),
and was including the file after a "package" declaration (and hence
in its own name space), the symbols "timegm" and "timelocal" were
local to that module/package.

Later, when the main program finally gets around to the "require
'timelocal.pl';" (at runtime) it sees that the file has already
been loaded (albiet into a private name space), and doesn't load it
again.

The reason this worked when I used the absolute path below was
that it tricked perl into thinking this was a different file, so
the file did indeed get loaded twice into both main's address
space as well as the incidental module that imported it.

So, what did I learn from this?

In a module, you are better off importing files *before* the
"package" declaration, so as to not make (otherwise) global
functions private.

At the same time, it doesn't hurt to declare globally visible
functions like:

*main'timelocal = *timelocal'timelocal;
*main'timegm = *timelocal'timegm;

to ensure that the functions are visible to everyone, even when
they are imported to a private namespace.

Unless I'm missing something obvious.

-Philip

> 
> I have a setuid(root) (CGI) script that does a:
> 
> require 'timelocal.pl';
> 
> in it.  I noticed that the script gets past the require, and
> executes up to the point where:
> 
>   $now = time;
>   @x = localtime($now);
>   $today = &timelocal(0, 0, 0, $x[3], $x[4], $x[5]);
> 
> and then complains about:
> 
> Undefined subroutine &main::timelocal called at ./form.cgi line 87.
> 
> So, I noticed that this goes away if I change the require to:
> 
> require '/usr/local/lib/perl5/timelocal.pl';

[ snip ]

> I'm curious as to why it doesn't work if I require the file via
> an unqualified path, but if I give an absolute path then it works.
> If it can't find the file, then why doesn't the 'require' statement
> bomb out then and there?
> 
> I understand that "use" is compile time whereas "require" is only
> run time, but still... this shouldn't have anything to do with it.
> 
> Can someone please explain what's going on?  What am I missing here?
> 
> Thanks,
> 
> -Philip


------------------------------

Date: 16 Apr 1997 17:01:29 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Solved! -- questions about timelocal.pl
Message-Id: <5j30l9$k6g$1@csnews.cs.colorado.edu>

 [courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc, 
    "Philip A. Prindeville" <philipp@ntex.com> writes:
:So, what did I learn from this?
:
:In a module, you are better off importing files *before* the
:"package" declaration, so as to not make (otherwise) global
:functions private.
:
:At the same time, it doesn't hurt to declare globally visible
:functions like:
:
:*main'timelocal = *timelocal'timelocal;
:*main'timegm = *timelocal'timegm;
:
:to ensure that the functions are visible to everyone, even when
:they are imported to a private namespace.
:
:Unless I'm missing something obvious.

Yes, you are.  You're globbering namespaces.  That's all VERY BAD,
and why we invented use.  All foo.pl files have this problem.

You should be using Time::Local not timelocal.pm

--tom
-- 
	Tom Christiansen	tchrist@jhereg.perl.com


I know I'm a pig-ignorant slut.  --Andrew Hume


------------------------------

Date: Wed, 16 Apr 97 01:06:24 GMT
From: tomw@tsys.demon.co.uk (Tom Wheeley)
Subject: Re: Unix and ease of use  (WAS: Who makes more ...)
Message-Id: <861152784snz@tsys.demon.co.uk>

In article <5iu1e3$17du@pulp.ucs.ualberta.ca>
           akwong@ee.ualberta.ca "Mandr" writes:

> If the WINE fans were into the WINE project because of fun, then they
> sould stick to it.  If they are in because they want to beat Microsoft,
> they should start writing Pure Java applications instead.  Corel by
> itself cannot make a big difference.

AFAICS, WINE is there for the probably quite large number of people who run
and prefer Linux most of the time, but *need* to run certain Windows
programs, and so are forced to dual boot Linux / Win95.

WINE and even Linux are no MS beaters; they are just catering for people
who like computers.  Increasingly, Linux is also catering for people who
want to run solid network servers -- this is the area which MS won't like
and is irrespective of WINE.

-- 
:sb)



------------------------------

Date: Wed, 16 Apr 97 01:10:00 GMT
From: tomw@tsys.demon.co.uk (Tom Wheeley)
Subject: Re: Unix and ease of use  (WAS: Who makes more ...)
Message-Id: <861153000snz@tsys.demon.co.uk>

In article <01bc491a$6a263f00$87ee6fce@timpent.a-sis.com>
           tim@a-sis.com "Tim Behrendsen" writes:

> > : Hm; compare PKZIP and gzip (PKZIP includes the gzip algorithm, I
> > : believe).  PKZIP includes support for multiple files, spanning
> > : multiple floppies, and a zillion other features.
> > 
> > All of which are unnessacery on the Unix systems for which gzip
> > was intended.  That's "tar"'s job.
> 
> I understand that, and it's a lot less flexible that way.  Can
> "tar | gzip" span multiple floppies?  No, unless you tar it
> again after you make the file (assuming your tar supports the
> feature).  Can I replace files within an archive?  Can I extract
> one file without having to stream the whole silly file?

Unless you have a truly large tar file, the time taken is minimal.  Perhaps
you could write a better tar, more suited to a disk environment than tapes,
which is what tar was originally designed for.

Of course, can you pkzip to a raw disk device?

> And it's also extremely fragile.  One corrupted byte and the
> rest of the file is trash.  With a reasonable tool like pkzip,
> you can often access files even if part of it is corrupt, and
> sometimes even rebuild the directory structure.

I've only ever once been able to recover a tiny part of a file from an
archiver; and that was with ARJ a far more flexible archiver than pkzip
could hope to be.

> Or how about self-extracting archives?

Do me a favour.  tar is part of the OS -- you don't need self extractors.

> Don't get me wrong; I use the tar-gzip combination quite often,
> but it's inferior as a tool compared to archive tools, particularly
> in combination with something like WinZip.

Well, I thought WinZip supported tar.gz files.  Or is it just a limited
support? (I've never used winzip).

-- 
:sb)



------------------------------

Date: Wed, 16 Apr 97 01:16:36 GMT
From: tomw@tsys.demon.co.uk (Tom Wheeley)
Subject: Re: Unix and ease of use  (WAS: Who makes more ...)
Message-Id: <861153396snz@tsys.demon.co.uk>

In article <5j07ci$ltr@bcrkh13.bnr.ca>
           kaz@vision.crest.nt.com "Kaz Kylheku" writes:

>     source code; default extraction of directory trees (with a switch to defeat
> ->  ***********
> ->  ***********
> 
>     this, rather than the reverse); OS/2, VMS, Unix, RISC OS and Macintosh ex-

Almost as important is the next feature along.  I distribute DOS
versions of my software using PKZIP, and am forced to keep everything in
a single directory due to the fact that 9 out of 10 people will not use
the -d switch (despite copious notice) and so any carefully crafted
directory structure would be ignored.

I find myself always typing `pkzip -d' whatever.  Now if I had the source...

-- 
:sb)



------------------------------

Date: Wed, 16 Apr 1997 13:14:20 -0400
From: Ron Natalie <ron@sensor.com>
Subject: Re: What does "UNIX" stand for..
Message-Id: <335508EC.1B87@sensor.com>

>      unix is based on a high portability
>      design philosophy ...

Actually, while UNIX ended up being portable, I don't
think that was the design philosophy.  UNIX's design
philosophy (unfortunately lost in the bloated systems
of today) was to make a series of small, interoperable
tools, to be combined into powerful operations by the
user.

Much of early UNIX wasn't exactly portable.  Large
chunks were still in assembler (and C had yet to be widely
ported either).  Goofy PDP-11 specific features abounded
and still exist to this day in things like the UNIX
signal names.

The portability came from the design of C being very
light weight and the openness of UNIX (for those who
could get their hands on UNIX at all in those early
days, they could get the source code as well).

-Ron "Not A Typewriter" Natalie
UNIX hacker since 1977.


------------------------------

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 316
*************************************

home help back first fref pref prev next nref lref last post