[16833] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 4245 Volume: 9

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Sep 7 03:05:24 2000

Date: Thu, 7 Sep 2000 00:05:10 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <968310310-v9-i4245@ruby.oce.orst.edu>
Content-Type: text

Perl-Users Digest           Thu, 7 Sep 2000     Volume: 9 Number: 4245

Today's topics:
    Re: "dashed" params... (Eric Bohlman)
    Re: Beating the perlcc dead horse again... <bcaligari@my-deja.com>
    Re: help with a hash? (Daniel Chetlin)
    Re: help with a hash? <christopher_j@uswest.net>
    Re: Help with Expect Perl Script (Charles DeRykus)
        help with net::ftp->login <chres00@dmi.usherb.ca>
    Re: help with net::ftp->login (Eric Bohlman)
    Re: how could I convert a string to a hex ASCII (Eric Bohlman)
        Is this a bug or a feature? elliotfinley@my-deja.com
    Re: Is this a bug or a feature? <wyzelli@yahoo.com>
    Re: Is this a bug or a feature? (Logan Shaw)
    Re: Is this a bug or a feature? (Gwyn Judd)
    Re: My Perl looks like C! <anmcguire@ce.mediaone.net>
    Re: newbie: redirect problem (Randal) <godzilla@stomp.stomp.tokyo>
    Re: newbie: redirect problem (Randal) <godzilla@stomp.stomp.tokyo>
    Re: newbie: redirect problem (Randal L. Schwartz)
    Re: Read text file to array (Logan Shaw)
    Re: Read text file to array <wyzelli@yahoo.com>
        Secure IMAP Connection <matthew.ramadanovic@yale.edu>
    Re: VBA conversion to Perl <nkh@cpen.com>
        Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)

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

Date: 7 Sep 2000 04:58:42 GMT
From: ebohlman@netcom.com (Eric Bohlman)
Subject: Re: "dashed" params...
Message-Id: <8p77a2$u1b$2@slb1.atl.mindspring.net>

Uri Guttman (uri@sysarch.com) wrote:
: just assign all the args to a hash and deal with them then.
: 
: sub a_routine {
: 
: 	my( $self, %args ) = @_ ;
: 
: 	$foo_arg = $args{'-foo'} || $default_foo ;
: 
: that works unless you want to be able to pass in a false value to
: $foo_arg. then use:
: 
: 	$foo_arg = exists $args{'-foo'} ? $args{'-foo'} : $default_foo ;

Better yet:

my $self=shift;
my %args=(-foo=>$default_foo, -bar=>$default_bar, -baz=>$default_baz, @_);

which relies on the fact that if you initialize a hash from a list and 
there are duplicate entries, the last one is used.




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

Date: Thu, 07 Sep 2000 05:58:58 GMT
From: Brendon Caligari <bcaligari@my-deja.com>
Subject: Re: Beating the perlcc dead horse again...
Message-Id: <8p7aqr$jct$1@nnrp1.deja.com>

In article <8p5or6$o59$1@nnrp1.deja.com>,
  vi_2000@hotmail.com wrote:
>
> >
> > > How can I perlcc and include my Net::FTP etc.  Modules???
> >                                ^^^^^^^^^^^
> > 							   ^^
> > MY Net::FTP has a copyright notice:
> >
> > # perldoc Net::FTP
> > [snip]
> > COPYRIGHT
> >        Copyright (c) 1995-1998 Graham Barr.
> > [snip]
> >
> > You are making a joke, aren't you? Please tell me you are! Please???
> > Pretty please... My trust in human nature is low enough as it is.
> >
>
> By stating "my Net::FTP", I was simply stating that I installed the
> module and used it in a program.  This was odviously a mistake.

Oh...I thought you were trying to lexically scope net::ftp

>
> Perl must suck since the three posts to my question offer nothing of
> value except criticism which in itself is totally worthless when I am
> trying to build a useful program!

I have absolutely nothing against getting paid for code (that's how I
earn part of my living)......where someone needs a solution to a
problem, and that solution might include some code in some
language...from a couple of lines of shell script or win32 batch file
to a perl script to compiled C code.  What I cannot understand is why
you feel so bad about having others see your code, especially if
they're going to pay for it.....and let's face it...if your programme
is in perl, and you're using the ftp module, I seriously doubt you have
some highly sensitive intellectual property issue with that code.

>
> So Long Perl humpers.  I'm going back to C++ where I can get real work
> done!

You can try visual basic......it's meant to be a real 'business tool'
(sic)


Brendon
++++


Sent via Deja.com http://www.deja.com/
Before you buy.


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

Date: Thu, 07 Sep 2000 04:55:18 GMT
From: daniel@chetlin.com (Daniel Chetlin)
Subject: Re: help with a hash?
Message-Id: <WcFt5.1329$p8.137148@news-west.usenetserver.com>

On Wed, 6 Sep 2000 20:17:10 -0700,
 Christopher M. Jones <christopher_j@uswest.net> wrote:
>Very true, but it's always good to keep the ol' chops in shape.
>
>Let's try this one last time (for the sake of completeness)
>
>=~ s{<a[^>]*?      (?# find <a[anything]href, but don't skip past the >)
> href\s*\=\s*      (?# allow padded whitespace around the =)
> (?:\")?           (?# ", but if it's not there don't)
> ([\w\.\%\@\:\?\&\+\-\=/]+?)   (?# the meat, find something url-ish)
> (?:\")?           (?# ", but if it's not there don't)
> [^>]*?            (?# all the characters past the end of the url to the)
>                    (?#  end of the tag, but don't go past the end)
> >                 (?# end of the tag)
> (.*?)             (?# any characters, up to the </a>)
> </a>}             (?# the matching end anchor tag)
> {}six             (?# replace with nothing)
>
>
>That should do the trick.

Well, I hate to keep critiquing, but I keep thinking about the people
keeping score at home.

Firstly, and most minorly, the ?# style of REx comments is fairly
deprecated.  You can just use a plain # just as in normal Perl code.
Doing that would have saved your first error, which is that the last two
comments aren't inside of the expression and therefore cause a
compile-time error.

Secondly, after removing those comments, we get this:

  [~] $ perl -nle's{<a[^>]*?href\s*=\s*(?:")?([\w.%@:?&+=/-]+?)
                    (?:")?[^>]*?>(.*?)</a>}{}si&&print$1'
  <a href="foo.bar.com">baz</a>
  f

Aside from scrunching it down, the only other thing I did was remove the
superfluous backwhacking.

So what's happening here? Well, frankly, it's a nasty case of too much
non-greedy matching. We grab the '<a' and as many non-'>' chars as
possible until we hit an 'href'. So far so good, except in a negated
character class like '[^>]' that there's not much point in your
non-greedy match; it will match the same thing greedy and non-greedy. So
then we match some whitespace optionally, an equal sign, some more
optional whitespace, and an optional doublequote.  Finally, we're ready
to start recording $1. First thing in that first set of capturing parens
is a large character class that is attempting to be URL-ish.  It's
quantified by a non-greedy +. OK, so the REx engine says "I'm non-greedy
here, so I'll grab the first character and then see if I can stop." It
grabs the 'f' in 'foo.bar.com'. It sees an optional doublequote, can't
match it, and sees the '[^>]' negated character class again. OK, it
says, I can match this, and proceeds to match the rest of 'oo.bar.com',
finally hitting the greater than that ends the anchor tag.

Oops.

Again, the short version of the story is to use HTML::Parser. The long
version is, quit with the non-greedy matching. But even if you do that,
you're still going to have trouble. Here's just one more tidbit of
trouble that you're going to have:

  <a name="foo>bar" href="http://foo.bar.com">baz</a>
  
Guess what? Your REx, even without the non-greediness, doesn't match
that guy.  And it's valid HTML 3.2!

I understand wanting to "keep the ol' chops in shape", but I really
think that it's best left on one's own machine, rather than shown on
Usenet. Now, if you'd posted these specifically asking for critique,
that'd be a different story (and I wouldn't feel like the bad guy here).
But presenting them as possible solutions is just dangerous in my mind.

See my sig for how easy it is to do it right.

-dlc

-- 
#!/usr/bin/perl -wl
use HTML::Parser;use strict;my(@u);my $p=HTML::Parser->new(api_version => 3);
$p->handler(start=>sub{push @u,shift->{href}if shift eq 'a'},'tagname,attr');
local $/;$p->parse(<>);print join("\n",@u);#Just another URI finding scheme:)




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

Date: Wed, 6 Sep 2000 23:34:10 -0700
From: "Christopher M. Jones" <christopher_j@uswest.net>
Subject: Re: help with a hash?
Message-Id: <zFGt5.2016$Ok5.421037@news.uswest.net>


"Daniel Chetlin" <daniel@chetlin.com> wrote:
> Well, I hate to keep critiquing, but I keep thinking about the people
> keeping score at home.

Bleh, I suck.  Damn sleep deprivation.

Yes, people should use the modules and HTML::Parser, but someone's
gotta write those.


Now, here's a much better snippet of code for the original task.

###
$htmlfile = "[[html file source]]";
%hrefhash = ();

while ( $htmlfile =~ s{<a\s(.*?)>(.*?)</a>}{}is )
    {
    my ($params, $insidecode) = ($1, $2);

    # change "href =  link.html" and the like to href=link.html
    $params = s/\s+\=\s+/=/g;

    my @params = split(/\s/, $params);
    foreach (@params)
        {
        my ($pname, pval) = split(/\=/, $_);

        # remove leading and trailing whitespace
        $pname =~ s/^\s*(\S|\b)/\1/s; $pname =~ s/(\S|\b)\s*$/\1/s;
        $pval =~ s/^\s*(\S|\b)/\1/s; $pval =~ s/(\S|\b)\s*$/\1/s;

        $pname = "\L$pname";
        # actually, you'd want to use if($pname =~ /^href$/i) in
        #  this case, but this has more general purpose functionality
        if ($pname eq 'href')
            {
            # remove leading and trailing "s or 's (if there)
            $pval =~ s/^"//; $pval =~ s/^'//;
            $pval =~ s/"$//; $pval =~ s/'$//;
            $hrefhash{$pval} = $insidecode;
            }
        }
    }






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

Date: Thu, 7 Sep 2000 04:21:32 GMT
From: ced@bcstec.ca.boeing.com (Charles DeRykus)
Subject: Re: Help with Expect Perl Script
Message-Id: <G0I1Fw.6uv@news.boeing.com>

In article <u99drs8a6bu6pctah80damaamiocd502hr@4ax.com>,
Thomas George  <ygguh@aol.com> wrote:
>Below is a snippet of my script which doesn't work correctly, or should I say,
>it doesn't return the information I require. What the script does is connect up
>to a UNIX box and runs a perl script which checks a userid against a reservation
>file, similar to struct passwd. 
>
>If the userid is not in the reservation file, it is then entered and I will
>receive a return message of: "0, USERID reserved".
>
>If the userid is already in the reservation file, I will then receive a return
>message of: "1, USERID exists".
>
>And, if both the above two conditions fail, or if the userid is not within a
>predefined format, I will then receive a return message of: "#, Error <REASON>"
>where "#" is a number between 2 and 20 and "REASON" is a test error message.
>
>As you will see, I have tried several ways of capturing the return code from my
>expect command with no positive results.
>
>Any help would be appreciated.
>
>#!/usr/local/bin/perl
>
>use Expect;     # This is a module, needs supporting modules too.
>
>$Expect::Log_Stdout=1;
>$Expect::Debug=3;
>$Expect::Exp_Internal=1;
>
># Basic stuff to setup session.
>$cmd = "/usr/bin/telnet" ;
>$host = "smtp.server.net." ;
>$login = "george" ;
>$passwd = "abc123" ;
>
># Our arguments.
>$NAME = $ARGV[0] ;
>
># Count the command line args, if there's not enough, give usage and exit.
>$count = @ARGV ;
>if ($count < 1) {
>    print "Usage: usercheck.pl NAME\n" ;
>    exit 0 ;
>    } else { # Connect to the remote host.
>         $expect = Expect->spawn("$cmd $host") || die "Can't connect to $host" ;
>          $expect->log_stdout(0) ; # Log to STDOUT.
>          unless ($expect->expect(5, "login:")) {     # Wait for login prompt.
>                print "Error: host timed out waiting for $host\r"
>          }
>          print $expect "$login\r" ; # Send our username.
>          unless ($expect->expect(5, "Password:")) {    # Wait for Password.
>                print "Error: login timed out waiting for $host\r"
>          }
>        print $expect "$passwd\r" ;  # Send our passwd.
>        unless ($expect->expect(5, "\$")) {
>                print "Error: passwd timed out waiting for $host\r"
>        }
>
>        #($code,$message)=$expect->expect(5,"./usercheck $NAME\n") ;
>         print $expect "./usercheck $NAME\n" ;
>         ($code,$message)=$expect->expect(5,'-re','[0-9]*');
>        
>        $status = $code;
>        
>        if ($status == 0) {
>                print "Okay\r";
>        } else {
>                print "Not $message\r";
>        }
>
>          print $expect->exp_match();
>          # $expect->soft_close() ;
>      }
>exit 0 ;


Not to dissuade if you've got a compelling reason for
Expect.pm, but Net::Telnet would be easier here
I believe. Here's a rough, unwarrantied cut at it: 

 
#!/usr/local/bin/perl -w

use Net::Telnet;
use strict;

my $NAME = $ARGV[0] or die "usuage: ....";
my $host = "smtp.server.net";

my $telnet = new Net::Telnet (Timeout => 60,
                              Prompt => "/$host\$ $/",
                              #Dump_log =>*STDOUT, 
                             );

$telnet->open($host);
$telnet->login($acct, $password);
my ($code, $msg) = $telnet->cmd("./usercheck $NAME");
$telnet->close;
__END__



hth,
--
Charles DeRykus


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

Date: Thu, 07 Sep 2000 05:21:55 GMT
From: "Simon Chrétien" <chres00@dmi.usherb.ca>
Subject: help with net::ftp->login
Message-Id: <TBFt5.17666$nw6.565846@carnaval.risq.qc.ca>

Hi, I'm using net::ftp with activePerl and would like to know why the login
method ends
my script when I call it with a good IP with bad port or some ip where
theres no ftp.
I mean if I try ftp.cdrom.com and port 1000 it will give me an error like
<Can't call method
"login" on an undefined value at test.pl line 74.>
Putting login into eval brackets wont change anything so is there any way to
just let the script
continue and not stop. I'm a perl newbie but I think this is ridiculous
hehe. Thanks

If it could help here's what I do:
$ftp = Net::FTP->new($ip, Port, $port, Timeout, 200, Debug, 1);
 eval { $status = $ftp->login($login, $password) }; warn $@ if $@;





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

Date: 7 Sep 2000 06:48:46 GMT
From: ebohlman@netcom.com (Eric Bohlman)
Subject: Re: help with net::ftp->login
Message-Id: <8p7doe$u1b$5@slb1.atl.mindspring.net>

Simon Chrétien (chres00@dmi.usherb.ca) wrote:
: Hi, I'm using net::ftp with activePerl and would like to know why the login
: method ends
: my script when I call it with a good IP with bad port or some ip where
: theres no ftp.
: I mean if I try ftp.cdrom.com and port 1000 it will give me an error like
: <Can't call method
: "login" on an undefined value at test.pl line 74.>
: Putting login into eval brackets wont change anything so is there any way to
: just let the script
: continue and not stop. I'm a perl newbie but I think this is ridiculous
: hehe. Thanks
: 
: If it could help here's what I do:
: $ftp = Net::FTP->new($ip, Port, $port, Timeout, 200, Debug, 1);
:  eval { $status = $ftp->login($login, $password) }; warn $@ if $@;

What you need to do is check if $ftp is defined (actually, checking if it 
has a non-zero value will do) after the call to new().  If the attempt to 
connect failed, $ftp will be undefined and needless to say you won't be 
able to call any of its methods.  The situation is quite analogous to 
opening a filehandle; you need to check whether the operation succeeded 
before going further.



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

Date: 7 Sep 2000 05:12:21 GMT
From: ebohlman@netcom.com (Eric Bohlman)
Subject: Re: how could I convert a string to a hex ASCII
Message-Id: <8p783l$u1b$3@slb1.atl.mindspring.net>

Lucas Tsoi (lucas@cplhk.com) wrote:
: how could I convert a string to a hex ASCII?

It's not entirely clear what you want to do, as "convert a string to a 
hex ASCII" could mean several different things, but I'd suggest that you 
consult the docs for sprintf to see if its hex conversion is the kind of 
thing you want.  If it isn't, consult the docs for pack, which does a 
different sort of hex conversion.  If that still isn't what you want, ask 
back here with a more precise formulation of your requirements 
(including, but *not* limited to, an example case).



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

Date: Thu, 07 Sep 2000 05:13:40 GMT
From: elliotfinley@my-deja.com
Subject: Is this a bug or a feature?
Message-Id: <8p785o$gj1$1@nnrp1.deja.com>

#!/usr/bin/perl -w

use strict;

main();
exit;

sub main {
    my $v = 10;

    while($v > 0) {
        {
            if ($v > 5) {
                print "One\n";
                $v--;
                next;
            }
        }
        {
            if ($v > 0) {
                print "Two\n";
                $v--;
                next;
            }
        }
        last;
    }
}

The output from this program is:
One
Two

I expected it to be:
One
One
One
One
One
Two
Two
Two
Two
Two

This is Perl 5.005_03 on FreeBSD 4.1-stable

Is this a bug?  Does this code behave the same on
5.6?


Sent via Deja.com http://www.deja.com/
Before you buy.


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

Date: Thu, 7 Sep 2000 14:41:00 +0930
From: "Wyzelli" <wyzelli@yahoo.com>
Subject: Re: Is this a bug or a feature?
Message-Id: <YMFt5.23$8S.3791@vic.nntp.telstra.net>

<elliotfinley@my-deja.com> wrote in message
news:8p785o$gj1$1@nnrp1.deja.com...
> #!/usr/bin/perl -w
>
> use strict;
>
> main();
> exit;
>
> sub main {
>     my $v = 10;
>
>     while($v > 0) {
>         {
>             if ($v > 5) {
>                 print "One\n";
>                 $v--;
>                 next;
>             }
>         }
>         {
>             if ($v > 0) {
>                 print "Two\n";
>                 $v--;
>                 next;
>             }
>         }
>         last;
>     }
> }
>
> The output from this program is:
> One
> Two
>
> I expected it to be:
> One
> One
> One
> One
> One
> Two
> Two
> Two
> Two
> Two
>
> This is Perl 5.005_03 on FreeBSD 4.1-stable
>
> Is this a bug?  Does this code behave the same on
> 5.6?
>

Actually I think it's just a weird indenting style and strange use of
blocks.

This does what you are trying to achieve:-

#!/usr/bin/perl -w
use strict;

main();
exit;

sub main {
    my $v = 10;
        while($v > 0) {
        if ($v > 5) {
            print "One\n";
            $v--;
            next;
        }
        if ($v > 0) {
            print "Two\n";
            $v--;
            next;
        }
    last;
    }
}

You have superfluous opening and closing braces which means you are not
"next"ing into what you think you are.

Also the "last" is really not doing much since $v must be <= 0 to get
there anyway.

Wyzelli




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

Date: 7 Sep 2000 00:51:58 -0500
From: logan@cs.utexas.edu (Logan Shaw)
Subject: Re: Is this a bug or a feature?
Message-Id: <8p7adu$9uk$1@provolone.cs.utexas.edu>

In article <8p785o$gj1$1@nnrp1.deja.com>,  <elliotfinley@my-deja.com> wrote:
>#!/usr/bin/perl -w
>
>use strict;
>
>main();
>exit;
>
>sub main {
>    my $v = 10;
>
>    while($v > 0) {
>        {
>            if ($v > 5) {
>                print "One\n";
>                $v--;
>                next;
>            }
>        }
>        {
>            if ($v > 0) {
>                print "Two\n";
>                $v--;
>                next;
>            }
>        }
>        last;
>    }
>}
>
>The output from this program is:
>One
>Two
>
>I expected it to be:
>One
>One
>One
>One
>One
>Two
>Two
>Two
>Two
>Two

From "perldoc perlsyn":

     A BLOCK by itself (labeled or not) is semantically
     equivalent to a loop that executes once.  Thus you can use
     any of the loop control statements in it to leave or restart
     the block.

Thus, your "next"s just finish the blocks immediately outside of the if
statements, rather than finishing the block for the while loop.

So, the first time through the loop, the "next" jumps to just outside
the first closing brace in the same column as the "e" of "while".  The
second "next" jumps to just outside the second such closing brace, and
that takes you to "last", which ends the loop.

  - Logan


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

Date: Thu, 07 Sep 2000 05:54:58 GMT
From: tjla@guvfybir.qlaqaf.bet (Gwyn Judd)
Subject: Re: Is this a bug or a feature?
Message-Id: <slrn8rebka.ta.tjla@thislove.dyndns.org>

I was shocked! How could elliotfinley@my-deja.com <elliotfinley@my-deja.com>
say such a terrible thing:

<snip>

>    while($v > 0) {
>        {
>            if ($v > 5) {
>                print "One\n";
>                $v--;
>                next;
>            }
>        }

<snip>

>        last;
>    }
>}
>
>The output from this program is:
>One
>Two
>
>Is this a bug?

No

>Does this code behave the same on 5.6?

Yes.

see the file "perl -f next" for the reason why (it's near the bottom).

-- 
Gwyn Judd (print `echo 'tjla@guvfybir.qlaqaf.bet' | rot13`)
Fortune's real live weird band names #485:

Nomad Nipples


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

Date: Wed, 6 Sep 2000 23:49:22 -0500
From: "Andrew N. McGuire " <anmcguire@ce.mediaone.net>
Subject: Re: My Perl looks like C!
Message-Id: <Pine.LNX.4.21.0009062330050.4440-100000@hawk.ce.mediaone.net>

On 6 Sep 2000, Ilmari Karonen quoth:

~~ Date: 6 Sep 2000 13:14:46 GMT
~~ From: Ilmari Karonen <iltzu@sci.invalid>
~~ Reply-To: Ilmari Karonen <usenet11206@itz.pp.sci.fi>
~~ Newsgroups: comp.lang.perl.misc
~~ Subject: Re: My Perl looks like C!
~~ 
~~ In article <Pine.LNX.4.21.0008312324100.28238-100000@hawk.ce.mediaone.net>, Andrew N. McGuire  wrote:
~~ >efficient ways to do many things.  Hashes are a strong point with
~~ >Perl, yes, but Perl is not the only language to implement hashes.
~~ 
~~ Indeed.  Java also has hashes, and I use them whenever they suit the
~~ job.  But I don't use them nearly as much as in Perl, simply because
~~ the syntax is a pain in the ass.  Perl hashes are not only efficient
~~ but also extremely convenient.  _That's_ why they should be used.

Agreed, my only point is don't use a hash when you need an array,
and vice versa.  For example what if you need duplicate elements
in you list?  Hash keys will not do.  The flip side to that coin is:
what if you want to simulate a mathematical set?  Hash keys are an
easy way to do that as each element of a set is by defintion unique.
When testing for existence, nothing beats a hash.  When implementing
a stack, use an array, etc...


~~ Perl:  $hash{key}++;
~~ 
~~ Java:  Integer temp = (Integer) hash.get("key");
~~        if (temp == null) temp = new Integer (0);
~~        hash.put("key", new Integer(1 + temp.intValue()));

Python: dict = {'key':1}
        dict['key'] = dict['key'] + 1

I do like one thing about Pythons dict's.  The key must be
immutable, but the value can be ANY type of object.  And of
course, if it must be Java, write it in Python, and compile
it into Java bytecode.

anm
-- 
Andrew N. McGuire
anmcguire@ce.mediaone.net
perl -le'print map?"(.*)"?&&($_=$1)&&s](\w+)]\u$1]g&&$_=>`perldoc -qj`'



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

Date: Wed, 06 Sep 2000 23:27:54 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: newbie: redirect problem (Randal)
Message-Id: <39B7356A.14941C56@stomp.stomp.tokyo>

"Randal L. Schwartz" wrote:
 
> > Godzilla! writes:

(snipped a bit here and there)

> Godzilla!> specialized nph-client, a type of script, which
> Godzilla!> is rarely used anymore. I believe this style is rare
> Godzilla!> because so few know how to work with nph-client scripts.

> Or perhaps because modern versions of Apache made them nearly obsolete.
> From the docs at http://www.apache.org/docs/upgrading_to_1_3.html
 
>     Apache now provides an effectively unbuffered connection for CGI
>     scripts....
 
>     "nph-" CGIs, which formerly provided a direct socket to the client
>     without any server post-processing, were not fully compatible with
>     HTTP/1.1 or SSL support....
 
> So, not only obsolete, but they interfere with HTTP/1.1, which is the
> current approved HTTP standard (although most interfaces are backwards
> compatible).


This is most interesting Randal. I have certainly pulled some
tricks at times to have an nph-client do as I wish. This server
I use personally, runs an older version of Apache with some
more modern patching, rather odd combinations. Not surprising
there is some creative root programming going on; my server is
owned and operated by a woman, as ecentric as myself.

What I am using for a header is a bare minimum:

     "HTTP/1.0 200 OK\n",
     "Server: Chahta Chat via CERN/3.0\n",
     "Content-Type: text/html\n\n";

If I follow up with a print of a Location: ...etc
a visitor sees the print Location stuff on a blank
page, but in an html type format. Switching over
to this format Ms. Chalmers posted, does the trick.
My output would appear:

HTTP/1.0 200 OK
Server: Chahta Chat via CERN/3.0
Content-Type: text/html

HTTP/1.1 302 Redirected
Location: <url goes here>

(blank line above)

Should I leave out "HTTP/1.1 302 Redirected"
and insert a Location: only, FUBAR. I have
not tried rearranging header info and, this
is not an area of my expertise. I have a
solution, it works, what the heck.

At one time, I printed a meta tag refresh
to redirect under an nph-client. Works ok
save for older browsers. Only reason I use
this or need this redirect is to keep my
script size down. I only use it for denied
access or denial of proxy servers. With
a redirect, I can send these offenders
to another script, and keep my master
script size down as much as possible.
It is currently, one-hundred-twenty
kilobytes in size, just short of
four thousand lines of code.

I run a lot of cgi scripts which are not
nph style. Really cannot tell any difference
between performance. However, not using
nph is so much easier and more logical
as you indicate.

This style I use is a pensive thing, perhaps
a wish for glory days. Use of nph-client, for
me, dates back a few years to the rip roaring
days of 1995 when Michael Fremont of the
Internet Roundtable Society released his
first chat version, eighteen kilobytes at
six-hundred lines, and Netscape 1.2 was
the hottest browser going. Still have a
copy of 1.2 and all subsequent versions.

Suppose I should let go of the past, move
towards what our future brings. Certainly
nph-clients are dusty relics now. No reason
not to update. Only requires removal of
a few lines of code and an address change;
removal of nph in the script name.

Still, it is hard to let go. I miss those
days when our 'internet' was plain text,
all plain text. I miss those days when
Mozilla didn't have Java, miss those days
of chat crashers and AOHell. I certainly
miss those days before 'spam' became an
internet term and 'me too' was never read.

Thanks for your information. Cannot say all
of it makes sense but I have bookmarked your
link and will study up. Suppose all which is
left to do is remove nph from my script names
and join this dubious future of our internet.

 ...won't give up Perl 4 though!

Don't you miss Perl 4 Randal? Miss all those
challenges of real tough programming?

Kira


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

Date: Wed, 06 Sep 2000 23:51:32 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: newbie: redirect problem (Randal)
Message-Id: <39B73AF4.5F373F62@stomp.stomp.tokyo>

"Godzilla!" wrote:

( more snippage )

> "Randal L. Schwartz" wrote:
> > > Godzilla! writes:
 
> > Godzilla!> specialized nph-client, a type of script, which
> > Godzilla!> is rarely used anymore. I believe this style is rare
> > Godzilla!> because so few know how to work with nph-client scripts.
> 
> > Or perhaps because modern versions of Apache made them nearly obsolete.
> > From the docs at http://www.apache.org/docs/upgrading_to_1_3.html


A follow up for you Randall. I removed my nph header
stuff from my script, removed nph from the script name
and am testing it as a standard cgi. 

I found printing Location: .. etc alone works just fine.
Not sure on performance of course. However, I am going
to write a redirect to this new script name, actually
same name sans nph, have my friends and other visitors
try this for a period of time and see what they think.
It would be nice if I could categorically state I have
noticed a speed improvement, which I have noticed. Still,
this could be contributed to many external factors, such
as general internet conditions and current server load.

Should I note an overall improvement in performance,
I will certainly commend you for inspiring me to take
a few steps towards *shudders* Perl... umm.. uhh..
*sputters* Perl 5. GAK! I choke on that expression.
Perl 4 slips off my tongue smoother than lies.

Anyhow, after a few weeks, I will be in a position to
better comment on any noticable differences in speed
and the such. For now, it is nice to boot butts out
with a simple print Location. 

So, you see, if I am approached in a positive manner,
sometimes I listen, but not often.

Thanks Randal. I know this is odd but you have inspired
me to change a few of my staunch notions on Perl. I will
give this a fair test and, I will need time to make up
excuses why I should continue to write nph-clients.

Who knows, I might even be nice and upload a more
public version of my Perl draw poker game. I know
this program will raise eyebrows in surprise.

Godzilla!

-- 
Shazamina Fatima Alabimbo, Internet Mind Reader.
  http://la.znet.com/~callgirl/mindread.cgi


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

Date: 06 Sep 2000 22:37:47 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: newbie: redirect problem
Message-Id: <m11yywiwyc.fsf@halfdome.holdit.com>

>>>>> "Godzilla!" == Godzilla!  <godzilla@stomp.stomp.tokyo> writes:

Godzilla!> [...] It's a neat
Godzilla!> trick when working with your own headers via a 
Godzilla!> specialized nph-client, a type of script, which
Godzilla!> is rarely used anymore. I believe this style is rare
Godzilla!> because so few know how to work with nph-client scripts.

Or perhaps because modern versions of Apache made them nearly obsolete.
From the docs at <URL:http://www.apache.org/docs/upgrading_to_1_3.html>:

    Apache now provides an effectively unbuffered connection for CGI
    scripts. This means that data will be sent to the client as soon
    as the CGI pauses or stops output; previously, Apache would buffer
    the output up to a fixed buffer size before sending, which could
    result in the user viewing an empty page until the CGI finished or
    output a complete buffer. It is no longer necessary to use an
    "nph-" CGI to get unbuffered output. Given that most CGIs are
    written in a language that by default does buffering (e.g., perl)
    this shouldn't have a detrimental effect on performance.

    "nph-" CGIs, which formerly provided a direct socket to the client
    without any server post-processing, were not fully compatible with
    HTTP/1.1 or SSL support. As such they would have had to implement
    the transport details, such as encryption or chunking, in order to
    work properly in certain situations. Now, the only difference
    between nph and non-nph scripts is "non-parsed headers".

So, not only obsolete, but they interfere with HTTP/1.1, which is the
current approved HTTP standard (although most interfaces are backwards
compatible).

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


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

Date: 7 Sep 2000 01:13:13 -0500
From: logan@cs.utexas.edu (Logan Shaw)
Subject: Re: Read text file to array
Message-Id: <8p7blp$a32$1@provolone.cs.utexas.edu>

In article <CeGt5.493$4s.2181@news1.onlynews.com>,
Michael C. Blair <blairmc@ispchannel.com> wrote:
>Could someone give me a sample of how to read a text file directly into an
>array?

It's pretty easy:

	open (MYFILE, "my-text-file.txt")
		or die "Can't open my-text-file.txt ($!)\n";
	@lines = <MYFILE>;
	close MYFILE;

You might want to trim newlines or something too, in which case
you would replace one of the lines with this:

	chomp (@lines = <MYFILE>);

Or clearer (I think) is to add this to the end instead:

	foreach (@lines) { chomp; }

Hope that helps.

  - Logan


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

Date: Thu, 7 Sep 2000 15:46:53 +0930
From: "Wyzelli" <wyzelli@yahoo.com>
Subject: Re: Read text file to array
Message-Id: <jLGt5.26$8S.3805@vic.nntp.telstra.net>

"Logan Shaw" <logan@cs.utexas.edu> wrote in message
news:8p7blp$a32$1@provolone.cs.utexas.edu...
>
> You might want to trim newlines or something too, in which case
> you would replace one of the lines with this:
>
> chomp (@lines = <MYFILE>);
>
> Or clearer (I think) is to add this to the end instead:
>
> foreach (@lines) { chomp; }
>

or even:

chomp @lines;

Wyzelli




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

Date: Thu, 7 Sep 2000 02:18:42 -0400
From: "Matthew Ramadanovic" <matthew.ramadanovic@yale.edu>
Subject: Secure IMAP Connection
Message-Id: <8p7cas$5oi$1@news.ycc.yale.edu>


Folks,
    I would like to user perl to create a secure web page capable of
authenicating a user.
I need to authenticate by connecting to an IMAP server (a different server
than the web
server). The whole thing worked fine (read easy) using the modules available
from CPAN. Now I
need to do the same thing securely (just the authenication part so that
there are no passwords
going over the wire a la clear text).

The server supports SSH client connections. Is there an elegant way to do
this with PERL
and Apache or do I need to shell out to something and hack away?

Any ideas?

-Matt






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

Date: Thu, 7 Sep 2000 07:52:57 +0200
From: "Nadim Khemir" <nkh@cpen.com>
Subject: Re: VBA conversion to Perl
Message-Id: <39b72d29.1@d2o68.telia.com>

"David Hedtke" <dhedtke@birch.com> wrote in message
news:srdhsrm7ljn62@corp.supernews.com...
> I am unable to find any additional references to assist me in converting
> this VBA macro for Excel in to Perl code...

Check if th ActiveState help called "Usig  OLE with Perl" could help.




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

Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>


Administrivia:

The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc.  For subscription or unsubscription requests, send
the single line:

	subscribe perl-users
or:
	unsubscribe perl-users

to almanac@ruby.oce.orst.edu.  

| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.

For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V9 Issue 4245
**************************************


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