[9589] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 3183 Volume: 8

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jul 17 05:58:09 1998

Date: Thu, 16 Jul 98 21:01:43 -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, 16 Jul 1998     Volume: 8 Number: 3183

Today's topics:
    Re: Perl Beautifier Home Page <tim.maher@halcyon.com>
    Re: Perl Beautifier Home Page <tim.maher@halcyon.com>
    Re: Perl Beautifier Home Page <tim.maher@halcyon.com>
    Re: Perl Beautifier Home Page <tim.maher@halcyon.com>
    Re: Perl Beautifier Home Page <rra@stanford.edu>
    Re: Perl Beautifier Home Page <tim.maher@halcyon.com>
    Re: Perl Beautifier Home Page <tim.maher@halcyon.com>
    Re: Perl Beautifier Home Page <tim.maher@halcyon.com>
    Re: Perl Beautifier Home Page <tim.maher@halcyon.com>
    Re: Perl Beautifier Home Page <tim.maher@halcyon.com>
    Re: Perl Beautifier Home Page lvirden@cas.org
    Re: perl IDE and compiler (Eric Weiss)
        running C functions in PERL <bqd0915@is.nyu.edu>
    Re: when i use htaccess to do authentication (Martien Verbruggen)
        Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)

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

Date: Thu, 16 Jul 1998 19:57:25 +0100
From: Tim Maher <tim.maher@halcyon.com>
To: Kevin Reid <kpreid@ibm.net>
Subject: Re: Perl Beautifier Home Page
Message-Id: <35AE4D15.A3356D34@halcyon.com>



Kevin Reid wrote:

> Tim Maher <tim.maher@halcyon.com> wrote:
>
> > I've got my Perl Beautifier running, with a reasonable set
> > of default options, on
> > http://www.consultix.wa.com/yumpy/cgi-pvt/pbeaut.cgi.
> >
> > It's been tested primarily with the 66 modules of the standard
> > Perl distribution, so I'm interested to see what happens when
> > it's confronted with other programming styles.
> >
> > Please help me test it by whipping some of your code at
> > it!  I'll be Emailed progrmaany syntax errors that my beautifier
> > introduces, which could help me improve it, prior to making
> > it more generally available.
> >
>
> It appears not to handle prototypes on subroutines correctly.

That wouldn't surprise me, as I've spent 0 effort on handling them
and never conducted any tests to see what would happen.  Thanks
for reminding me! 8-}

>
>
> Try it on this program:
>
> sub AUTOLOAD {join+"",reverse+split//,$_
> [0].q. ..($AUTOLOAD =~ /^.*::(.*)$/)[0]}
> print tsuJ(qq)\n).hacker(rehtona(lreP)))
>
> --
>   Kevin Reid.      |         Macintosh.
>    "I'm me."       |      Think different.



--
====================================================
|  Tim Maher         Email: Tim.Maher@halcyon.com  |
====================================================




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

Date: Thu, 16 Jul 1998 19:58:47 +0100
From: Tim Maher <tim.maher@halcyon.com>
To: Ronald J Kimball <rjk@coos.dartmouth.edu>
Subject: Re: Perl Beautifier Home Page
Message-Id: <35AE4D66.3A9F2491@halcyon.com>



Ronald J Kimball wrote:

> Zenin <zenin@bawdycaste.org> wrote:
>
> >   The syntax @{ expression } becomes:
> >     @
> >       {
> >       expression
> >       }
> >   Funky yes, but I'm not even sure that would compile... :-)
>
> Why wouldn't it?
>
> ~> perl -c
> @
>        {
>         expression
>        }
> __END__
> - syntax OK
>
> --
>  _ / '  _      /         - aka -         rjk@coos.dartmouth.edu
> ( /)//)//)(//)/(     Ronald J Kimball      chipmunk@m-net.arbornet.org
>     /                                  http://www.ziplink.net/~rjk/
>         "It's funny 'cause it's true ... and vice versa."

 This perverse formatting is a flashback to a previous bug that I
have long since fixed, and apparently, recently broken again!
Thanks for bringing it to my attention!

--
====================================================
|  Tim Maher         Email: Tim.Maher@halcyon.com  |
====================================================




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

Date: Thu, 16 Jul 1998 20:05:44 +0100
From: Tim Maher <tim.maher@halcyon.com>
To: Zenin <zenin@bawdycaste.org>
Subject: Re: Perl Beautifier Home Page
Message-Id: <35AE4F08.8563FB00@halcyon.com>



Zenin wrote:

> [posted & mailed]
>
> Tim Maher <tim.maher@halcyon.com> wrote:
> : I've got my Perl Beautifier running, with a reasonable set
> : of default options, on
> : http://www.consultix.wa.com/yumpy/cgi-pvt/pbeaut.cgi.
>
>         Quite impressive.
>
>         >snip<
> : Please help me test it by whipping some of your code at
> : it!  I'll be Emailed any syntax errors that my beautifier
> : introduces, which could help me improve it, prior to making
> : it more generally available.
>
>         A few comments.
>
>         If this is to be a generalized application, user defined
>         settings (indent length, indent style (all tab vs all space vs
>         mixed tabs and spaces (ala the perl source)), block style (same
>         line vs next line vs indented), etc.  All my comments below
>         might be such option settings for instance.

Most of these characteristics are already configurable, although you
cannot specify what you want from the Web page.

>
>
>         Puts spaces before -> operators.  Most common Perl code has no
>         whitespace here.  It also makes a distention between:
>                 $foo ->[list];
>         and
>                 $foo -> $method (@args);
>
>         The syntax @{ expression } becomes:
>                 @
>                         {
>                         expression
>                         }
>         Funky yes, but I'm not even sure that would compile... :-)

As I said in a different posting, this is a resurgence of a previously fixed
bug, which I'll address when I get some time . . .

>
>
>         Changes $foo = {} to:
>                 $foo =
>                 {
>                 };
>
>         Not everyone (myself included:-) likes zero space between functions
>         and parens:
>                 foo(@args)
>         vs
>                 foo (@args)
>         or sometimes
>                 foo ( @args )

This is configurable, via a command-line option.

>
>
>         The statement:
>                 if (scalar @{ $foo } != scalar @{ $bar }) {
>         got changed to:
>                 if (scalar @
>                         {
>                         $foo
>                         }
>                         != scalar @
>                         {
>                         $bar
>                         }
>                 )
>                 {
>         Ack! :-)

Again, that's the @{} bug I mentioned earlier, which I already fixed once! 8-}

>
>
>         Hmm, what about an interactive command line version?  One that
>         would show the line to be changed with what it wants to change
>         it into, and asks the user yes, no, or insert new text?

If the beautifier gets to the point of being really good, this would just be a
dragon its usage, since you'd express your stylistic desires at invocation
time.
If it never gets that good, this might be useful! 9=}

> --
> -Zenin (zenin@archive.rhps.org)           From The Blue Camel we learn:
> BSD:  A psychoactive drug, popular in the 80s, probably developed at UC
> Berkeley or thereabouts.  Similar in many ways to the prescription-only
> medication called "System V", but infinitely more useful. (Or, at least,
> more fun.)  The full chemical name is "Berkeley Standard Distribution".



--
====================================================
|  Tim Maher         Email: Tim.Maher@halcyon.com  |
====================================================




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

Date: Thu, 16 Jul 1998 20:01:36 +0100
From: Tim Maher <tim.maher@halcyon.com>
To: "M.J.T. Guy" <mjtg@cus.cam.ac.uk>
Subject: Re: Perl Beautifier Home Page
Message-Id: <35AE4E10.64320205@halcyon.com>



M.J.T. Guy wrote:

> Zenin  <zenin@bawdycaste.org> wrote:
> >
> >       The statement:
> >               if (scalar @{ $foo } != scalar @{ $bar }) {
> >       got changed to:
> >               if (scalar @
> >                       {
> >                       $foo
> >                       }
> >                       != scalar @
> >                       {
> >                       $bar
> >                       }
> >               )
> >               {
> >       Ack! :-)
>
> It's obviously trying to tell you that your code is being rendered
> difficult to read by unnecessary clutter.        :-)
>
>                 if (@$foo != @$bar) {
>
> Mike Guy

And that version survives the beautification nicely! (I just checked)


--
====================================================
|  Tim Maher         Email: Tim.Maher@halcyon.com  |
====================================================




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

Date: 16 Jul 1998 20:16:32 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Perl Beautifier Home Page
Message-Id: <m3g1g1upyn.fsf@windlord.Stanford.EDU>

Zenin <zenin@bawdycaste.org> writes:

>                                  But we're not talking about your standard
>                                  paragraph width here, we're talking about
>                                  code.
>                                      Code which is likely going to have deep
>                                      nesting at some points.

Anything that's nested more than four levels needs rewriting.

I've encountered *very, very* few exceptions to that principle that can be
justified.  If you use a four-space indent, you should be able to handle
four level nesting without continuation with very little difficulty.

> 	Should anything and everything of such deep nesting be pulled out
> 	into its own function/method?  Maybe, maybe not.  It might just be a
> 	big default data structure.  If you're embedding other languages
> 	such as SQL it gets worse:

That's what heredocs are for.  :)

> 	You don't need to be using any other languages however to have
> 	nesting deep enough to cause problems.  Hell, long variable names
> 	that make code easier to read and understand can start causing
> 	such problems with >80 text very quickly.

Ew.  Not *that* long.

>       And then there's working with same line comments:
	
> 	$myWhatever = new What::Ever::Module (
> 	    SomeOption      => 'some value',    ## Some comments that may
> 	    SomeOtherOption => 'something else, ## not even be big, but if you
> 	    SomeThing       => 'foobar',        ## are restricted to >80
> 	    SomeFoo         => 'dog',           ## columns,
	    
> 	    ## They must start looking like this in order that you don't
> 	    SomeBar         => 'foo',
	    
> 	    ## "violate" the no-man zone after the 80 column point
> 	    YaRight         => 'cat',
> 	);

(Studly caps.  Ick.)  Again, this is a case of readable line width.
You're trying to put more than 80 columns of information on a line, which
I think is a bad idea from a readability standpoint.  I'd put the comment
before the block you're commenting if it really had to be that long.

> 	It takes very, very little to blow away 80 columns, with no
> 	single statement ever being close to 80 columns in length.

I've been programming for nearly sixteen years now and have yet to have a
need to use more than 80 columns in any of my code.  Unsurprisingly, I
disagree with this statement.  :)

-- 
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print


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

Date: Thu, 16 Jul 1998 20:09:42 +0100
From: Tim Maher <tim.maher@halcyon.com>
To: brian d foy <comdog@computerdog.com>
Subject: Re: Perl Beautifier Home Page
Message-Id: <35AE4FF6.CCD0F275@halcyon.com>



brian d foy wrote:

> In article <35A87D71.1D8DBD36@halcyon.com>, Tim Maher <tim.maher@halcyon.com> posted:
>
> >I've got my Perl Beautifier running, with a reasonable set
> >of default options, on
> >http://www.consultix.wa.com/yumpy/cgi-pvt/pbeaut.cgi.
> >
> >It's been tested primarily with the 66 modules of the standard
> >Perl distribution, so I'm interested to see what happens when
> >it's confronted with other programming styles.
> >
> >Please help me test it by whipping some of your code at
> >it!  I'll be Emailed any syntax errors that my beautifier
> >introduces, which could help me improve it, prior to making
> >it more generally available.
>
> some oddities i noticed:
>
>    * it uses an 8 column tab (perlstyle leans towards 4)
>
>    * it turns $obj->method into $obj -> method.
>
>    * complains about __END__

Really?  I've never seen that . . .

>
>
>    * takes formatted code such as
>
>          $a     = 4;
>          $bee   = 5;
>
>       and makes it
>
>          $a = 4;
>          $bee = 5;
>
>       which is not good.

You can put a #LIT at the end of any line, to disable any beautification on it.
(Although you wouldn't know that from the web page unless you had violated
one of pbeaut's "limitations" (such as using s;;;, in a context where it causes
confusion), which gets you a dump of all its current limitations.)  I suppose I
should put a button on the web page youcan push just to view the limitations!

>
>
>    * it mangled lines that looked like:
>
>       print "calendar: family free is [$family_free]\n" if $debug > 0;
>
>    to
>
>       print "calendar: family free is [$family_free]\n" if $debug
>          >0;
>
>    which lost the space after the > (not good!) and removed it from
>    the construct it belongs to.
>
> --
> brian d foy                                  <comdog@computerdog.com>
> CGI Meta FAQ <URL:http://computerdog.com/CGI_MetaFAQ.html>
> Comprehensive Perl Archive Network (CPAN) <URL:http://www.perl.com>
> Perl Mongers Travel Deals! <URL:http://www.pm.org/travel.html>



--
====================================================
|  Tim Maher         Email: Tim.Maher@halcyon.com  |
====================================================




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

Date: Thu, 16 Jul 1998 20:11:06 +0100
From: Tim Maher <tim.maher@halcyon.com>
To: brian d foy <comdog@computerdog.com>
Subject: Re: Perl Beautifier Home Page
Message-Id: <35AE504A.BD14E953@halcyon.com>



brian d foy wrote:

> In article <35A87D71.1D8DBD36@halcyon.com>, Tim Maher <tim.maher@halcyon.com> posted:
>
> >I've got my Perl Beautifier running, with a reasonable set
> >of default options, on
> >http://www.consultix.wa.com/yumpy/cgi-pvt/pbeaut.cgi.
> >
> >It's been tested primarily with the 66 modules of the standard
> >Perl distribution, so I'm interested to see what happens when
> >it's confronted with other programming styles.
> >
> >Please help me test it by whipping some of your code at
> >it!  I'll be Emailed any syntax errors that my beautifier
> >introduces, which could help me improve it, prior to making
> >it more generally available.
>
> some oddities i noticed:
>
>    * it uses an 8 column tab (perlstyle leans towards 4)
>
>    * it turns $obj->method into $obj -> method.
>
>    * complains about __END__
>
>    * takes formatted code such as
>
>          $a     = 4;
>          $bee   = 5;
>
>       and makes it
>
>          $a = 4;
>          $bee = 5;
>
>       which is not good.
>
>    * it mangled lines that looked like:
>
>       print "calendar: family free is [$family_free]\n" if $debug > 0;
>
>    to
>
>       print "calendar: family free is [$family_free]\n" if $debug
>          >0;
>
>    which lost the space after the > (not good!) and removed it from
>    the construct it belongs to.

Usually, it handles that kind of case pretty well.  It might be that you ran into
the 80-column max line length limit, and it made a bad choice about how
to split it.  I'll look further into this .. .

>
>
> --
> brian d foy                                  <comdog@computerdog.com>
> CGI Meta FAQ <URL:http://computerdog.com/CGI_MetaFAQ.html>
> Comprehensive Perl Archive Network (CPAN) <URL:http://www.perl.com>
> Perl Mongers Travel Deals! <URL:http://www.pm.org/travel.html>



--
====================================================
|  Tim Maher         Email: Tim.Maher@halcyon.com  |
====================================================




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

Date: Thu, 16 Jul 1998 20:19:06 +0100
From: Tim Maher <tim.maher@halcyon.com>
To: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Perl Beautifier Home Page
Message-Id: <35AE5229.9BE6BB10@halcyon.com>



Tom Christiansen wrote:

>  [courtesy cc of this posting sent to cited author via email]
>
> In comp.lang.perl.misc,
>     Rick Delaney <rick.delaney@shaw.wave.ca> writes:
> :    %hash=(a=>'A',ab=>'AB',abc=>'ABC',);
> :    $var=10;
> :    $longvar=10;
> :
> :Beautified?:
> :
> ::   %hash = (a => 'A', ab => 'AB', abc => 'ABC',);
> ::   $var = 10;
> ::   $longvar = 10;
> :
> :No syntax errors, but still not very pretty.
>
> That should be:
>
>     %hash       = (a => 'A', ab => 'AB', abc => 'ABC',);
>     $var        = 10;
>     $longvar    = 10;
>
> or probably even:
>
>     %hash       = (
>                     a       => 'A',
>                     ab      => 'AB',
>                     abc     => 'ABC',
>                 );
>     $var        = 10;
>     $longvar    = 10;
>
> or somesuch.

I agree, either of these formats would be preferable.  However, at the present time,as I
said on the Web page, I'm somewhat satisfied just to process the code without
ruining it at this point 8=}!   So refinements of this type will have to wait for later
versions.

For the time being, if the programmer wants to bother formatting lines nicely like you
have above,
he/she can instruct the Beautifier to preserve them by putting a #LIT (literal) comment
at the
end of each line.

>
>
> The day a beautifier can even PARSE all my code will be a miracle.
> I can't possibly expect it to ever do 10% as good a job as I -- or any
> other programmer with aesethetics -- could at make code look right.

I agree.  But I think with Perl, which has arguably the most complex
grammar of any current artificial language, it would still be beneficial
for a utility to be able to get you at least halfway toward the final
result, and let you take it from there!

> Note that the examples I gave above are *not* amongst the things I
> wouldn't expect it to be able do.
>
> --tom
> --
>     "You're flame-proof in the same sense that certain plastics are fluorine-proof."
>         --Larry Wall



--
====================================================
|  Tim Maher         Email: Tim.Maher@halcyon.com  |
====================================================




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

Date: Thu, 16 Jul 1998 20:13:10 +0100
From: Tim Maher <tim.maher@halcyon.com>
To: Austin Schutz <spamsux-tex@habit.com>
Subject: Re: Perl Beautifier Home Page
Message-Id: <35AE50C5.4902278A@halcyon.com>



Austin Schutz wrote:

> Tim Maher wrote:
> >
> > I've got my Perl Beautifier running, with a reasonable set
> > of default options, on
> > http://www.consultix.wa.com/yumpy/cgi-pvt/pbeaut.cgi.
> >
> > It's been tested primarily with the 66 modules of the standard
> > Perl distribution, so I'm interested to see what happens when
> > it's confronted with other programming styles.
> >
>         Well, for the short sub I tested it on it only changed
> a couple of lines that looked like
>         foreach $scalar(@array) {
>
> to      foreach $scalar(@array)
>         {
>
>         Which I guess implies that my code isn't that ugly to start off
> with (yeah, sure ;').  One thing I am a pretty staunch supporter of
> is using spaces rather than tabs to indent code. Even moderately complex
> programs will use up half your line with indents if you use tabs. My
> suggestion (of course, it's what I do) is to indent with two spaces.
> Code blocks are still easily recognizable but it is much more compact.
>         Also, it seems to have trouble recognizing the difference
> between curly braces used for hashes and curly braces used for
> indicating code blocks.
>
>     foreach $handle(@{${*$self}{exp_Listen_Group}}) {
>
>         turns in to
>
>                     foreach $handle(@
>                                             {
>                                             $
>                                             {
>                                             *$self
>                                             }
>                                             {
>                                             exp_Listen_Group
>                                             }
>                                             }
>                 )

As I've said in several other messages by now, this @{} business
is a resurgence of an old bug that I thought I had exorcised;  I'll
look into that soon . . .

>                 {
>
>         BTW, from the results page you can't (using Nav 3.0 for Solaris)
> use the back button to return to your code.  Maybe that's just a browser
> thing though.
>
>         Austin



--
====================================================
|  Tim Maher         Email: Tim.Maher@halcyon.com  |
====================================================




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

Date: Thu, 16 Jul 1998 20:46:53 +0100
From: Tim Maher <tim.maher@halcyon.com>
To: brian d foy <comdog@computerdog.com>
Subject: Re: Perl Beautifier Home Page
Message-Id: <35AE58AD.5A9BC017@halcyon.com>



brian d foy wrote:

> In article <35A87D71.1D8DBD36@halcyon.com>, Tim Maher <tim.maher@halcyon.com> posted:
>
> >I've got my Perl Beautifier running, with a reasonable set
> >of default options, on
> >http://www.consultix.wa.com/yumpy/cgi-pvt/pbeaut.cgi.
> >
> >It's been tested primarily with the 66 modules of the standard
> >Perl distribution, so I'm interested to see what happens when
> >it's confronted with other programming styles.
> >
> >Please help me test it by whipping some of your code at
> >it!  I'll be Emailed any syntax errors that my beautifier
> >introduces, which could help me improve it, prior to making
> >it more generally available.
>
> some oddities i noticed:
>
>    * it uses an 8 column tab (perlstyle leans towards 4)
>
>    * it turns $obj->method into $obj -> method.
>
>    * complains about __END__
>
>    * takes formatted code such as
>
>          $a     = 4;
>          $bee   = 5;
>
>       and makes it
>
>          $a = 4;
>          $bee = 5;
>
>       which is not good.
>
>    * it mangled lines that looked like:
>
>       print "calendar: family free is [$family_free]\n" if $debug > 0;
>
>    to
>
>       print "calendar: family free is [$family_free]\n" if $debug
>          >0;

Actually, you've "annoyed the Beautifier" (8-}) in two ways with this last example:

1) it's got a slight bias against the "backwards" constructs in the first place

2) you left off the () that could optionally appear around the conditional part, which
would have prevented the splitting apart of its contents (I just confirmed that with
your example).   I know Perl doesn't require that, but it helps the Beautifier understand

your code if you put that in!

>
>
>    which lost the space after the > (not good!) and removed it from
>    the construct it belongs to.
>
> --
> brian d foy                                  <comdog@computerdog.com>
> CGI Meta FAQ <URL:http://computerdog.com/CGI_MetaFAQ.html>
> Comprehensive Perl Archive Network (CPAN) <URL:http://www.perl.com>
> Perl Mongers Travel Deals! <URL:http://www.pm.org/travel.html>



--
====================================================
|  Tim Maher         Email: Tim.Maher@halcyon.com  |
====================================================




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

Date: 17 Jul 1998 02:37:35 GMT
From: lvirden@cas.org
Subject: Re: Perl Beautifier Home Page
Message-Id: <6omddf$jhc$1@srv38s4u.cas.org>


According to Craig Berry <cberry@cinenet.net>:
:John Porter (jdporter@min.net) wrote:
:: IMHO, tabs suck hard, especially if you're working in a multi-programmer
:: environment.  Each guy has his own preferences for tab width.  And

Hmm - I seldom run into folk wanting tabs set at other than 8 columns
around here.

:: when one guy loads a file created by another guy who likes a different
:: tab width, it just looks like hell...   The first thing the guy does is
:: go and reformat the entire file so it looks good in his editor.

And for that matter, no matter whether folk are using spaces
or tabs, I don't like to see someone elses's indentations of software...



-- 
<URL:mailto:lvirden@cas.org> Quote: In heaven, there is no panic,
<*> O- <URL:http://www.teraform.com/%7Elvirden/> only planning.
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.


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

Date: Thu, 16 Jul 1998 22:25:02 -0400
From: eweiss@winchendon.com (Eric Weiss)
Subject: Re: perl IDE and compiler
Message-Id: <MPG.1018800dc73487969896e9@news.dgsys.com>

Check www.demobuilder.com for a Win32 Perl compiler that
generates an exe file.

Eric


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

Date: Thu, 16 Jul 1998 23:33:05 -0400
From: "Boris Dank" <bqd0915@is.nyu.edu>
Subject: running C functions in PERL
Message-Id: <6omglf$a59$1@news.nyu.edu>

I need to perform a few API calls on HPUX 10.20 platform to something called
Essbase Server.  If I have all the include files (lib*.h) as well as all the
library files (lib*.sl and lib*.a) documented, can I somehow call them from
PERL?  I have done the same in C but am wondering if it can be done in PERL.

Thanks!

/bdank




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

Date: 17 Jul 1998 02:16:00 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: when i use htaccess to do authentication
Message-Id: <6omc50$cop$1@nswpull.telstra.net>

In article <6om8en$g67@bgtnsc02.worldnet.att.net>,
	"zhe dang" <dangran@worldnet.att.net> writes:
> when i use htaccess to do client authentication, how can a server know who
> (usrid and passwd)
> accesses the protected page?

<OFFTOPIC>
_You_ do not use htaccess. Some servers look at a file .htaccess in
the directory, or parent directory, and use that to figure out whether
authentication is required, and how. Since the _server_ does this,
that's where it gets it information.
</OFFTOPIC>

You should discuss HTTP server issues in an appropriate group,
somewhere in comp.infosystems.www.*

Martien
-- 
Martien Verbruggen                  | 
Webmaster www.tradingpost.com.au    | The world is complex; sendmail.cf
Commercial Dynamics Pty. Ltd.       | reflects this.
NSW, Australia                      | 


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

Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>


Administrivia:

Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.

If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu. 


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

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