[32874] in Perl-Users-Digest
Perl-Users Digest, Issue: 4152 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Feb 25 14:09:31 2014
Date: Tue, 25 Feb 2014 11:09:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 25 Feb 2014 Volume: 11 Number: 4152
Today's topics:
additional group <gravitalsun@hotmail.foo>
Re: additional group <rweikusat@mobileactivedefense.com>
Re: additional group <gravitalsun@hotmail.foo>
Re: additional group <rweikusat@mobileactivedefense.com>
Re: additional group <gravitalsun@hotmail.foo>
Re: cookie <gravitalsun@hotmail.foo>
Re: cookie <rweikusat@mobileactivedefense.com>
Re: cookie <news@todbe.com>
Re: cookie <hjp-usenet3@hjp.at>
Re: Dancer <gravitalsun@hotmail.foo>
Re: Improving bad practice <justin.1401@purestblue.com>
Re: non-working perl script under Windows 2008 <news@todbe.com>
Re: non-working perl script under Windows 2008 <hjp-usenet3@hjp.at>
Re: obj 8-2 <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 25 Feb 2014 15:54:36 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: additional group
Message-Id: <lei79l$1md6$1@news.ntua.gr>
To find if a user belongs to an additional group I am checking the output of
id -nG SomeUser
The function getpwnam returns only the primary GID of the user.
Is there any way without a shell command ;
------------------------------
Date: Tue, 25 Feb 2014 14:24:02 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: additional group
Message-Id: <877g8js22l.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> To find if a user belongs to an additional group I am checking the output of
>
> id -nG SomeUser
>
> The function getpwnam returns only the primary GID of the user.
> Is there any way without a shell command ;
POSIX::getgroups
------------------------------
Date: Tue, 25 Feb 2014 16:33:24 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: additional group
Message-Id: <lei9id$1s5g$1@news.ntua.gr>
Στις 25/2/2014 16:24, ο/η Rainer Weikusat έγραψε:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>> To find if a user belongs to an additional group I am checking the output of
>>
>> id -nG SomeUser
>>
>> The function getpwnam returns only the primary GID of the user.
>> Is there any way without a shell command ;
>
> POSIX::getgroups
>
this fine for the effective user, I do not think it is working for the
SomeUser
------------------------------
Date: Tue, 25 Feb 2014 15:11:00 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: additional group
Message-Id: <8738j7rzwb.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> Στις 25/2/2014 16:24, ο/η Rainer Weikusat έγραψε:
>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>> To find if a user belongs to an additional group I am checking the output of
>>>
>>> id -nG SomeUser
>>>
>>> The function getpwnam returns only the primary GID of the user.
>>> Is there any way without a shell command ;
>>
>> POSIX::getgroups
>>
>
> this fine for the effective user, I do not think it is working for the
> SomeUser
http://search.cpan.org/~bastian/User-getgrouplist-1.1.0/
According to the Linux getgrouplist manpage, this will crash for glibc
versions prior to 2.3.3. A pure-Perl implementation could look like
this (side effect: group database will be closed afterwards):
sub groups_of
{
my $user = $_[0];
my (%groups, @grp, @pwd);
@pwd = getpwnam($user) or return ();
@grp = getgrgid($pwd[3]);
$groups{$grp[0] // $pwd[3]} = 1;
# close group database if open to make getgrent start from the start
endgrent();
while (@grp = getgrent()) {
for (split(/ /, $grp[3])) {
$groups{$grp[0]} = 1, last
if $_ eq $user;
}
}
endgrent();
return keys(%groups);
}
------------------------------
Date: Tue, 25 Feb 2014 18:00:04 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: additional group
Message-Id: <leiekt$28pp$1@news.ntua.gr>
Στις 25/2/2014 17:11, ο/η Rainer Weikusat έγραψε:
> sub groups_of
> {
> my $user = $_[0];
> my (%groups, @grp, @pwd);
>
> @pwd = getpwnam($user) or return ();
>
> @grp = getgrgid($pwd[3]);
> $groups{$grp[0] // $pwd[3]} = 1;
>
> # close group database if open to make getgrent start from the start
> endgrent();
>
> while (@grp = getgrent()) {
> for (split(/ /, $grp[3])) {
> $groups{$grp[0]} = 1, last
> if $_ eq $user;
> }
> }
>
> endgrent();
> return keys(%groups);
> }
very nice , I didn't think of getgrent
------------------------------
Date: Tue, 25 Feb 2014 11:37:53 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: cookie
Message-Id: <leho8a$g47$1@news.ntua.gr>
Στις 25/2/2014 05:29, ο/η Xho Jingleheimerschmidt έγραψε:
> On 02/24/14 15:02, George Mpouras wrote:
>>
>>
>> well here is the flow.
>>
>> 1) at the very start (before the header) I check if the user have the
>> cookie and if contain a valid data. In this case the user is redirected
>> immediately to the "final" page
>>
>> 2) In case there is no cookie, or if the cookie data are not valid, The
>> user must fill a form.
>> If the form data validated successfully, then a cookie must be sent at
>> user's browser , and redirected to the final page (here is the
>> difficulty is to send the cookie after the submission and validation)
>
> Item 2 is really items 2 and 3, as telling the user to fill out a form,
> and processing the form when/if they do so, are two different things.
>
> Here is a direct translation of your requirements. You did not specify
> what should happen if the user submitted the form but it was invalid, I
> just threw an fatal error, but you could just redisplay the form.
>
> It is not so nice to have the redirect in two different places, but as I
> said it is direct translation of your requirements.
>
> In particular, if you don't print the header too early, you will not
> have a problem with the header having been printed too early. Simply
> delay printing the header until until you know you don't need to redirect.
>
> #!/usr/bin/perl
> use CGI;
> use CGI::Carp qw(fatalsToBrowser);
> use strict;
>
> my $cgi=new CGI;
>
> if ($cgi->cookie('valid') eq 'valid') {
> print $cgi->redirect("/final");
> exit;
> };
>
> if (not $cgi->param()) {
> print $cgi->header(), $cgi->start_html(), $cgi->start_form();
> print $cgi->textfield('foo');
> print $cgi->submit();
> exit;
> };
>
> if ($cgi->param('foo') eq 'valid') {
> print $cgi->redirect(
> -uri => "/final",
> -cookie=>$cgi->cookie('valid','valid')
> );
> exit;
> };
>
> die "Form was submitted, but was not valid";
Xho,
I hope you understand that you can not redirect if you print the header
I hope you understand that you can not send a cookie after the header is
printed.
your code do not come even close to work.
It is very tricky and can not be done without very carefully design and
testing.
------------------------------
Date: Tue, 25 Feb 2014 11:33:12 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: cookie
Message-Id: <87bnxvo29z.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> Στις 25/2/2014 05:29, ο/η Xho Jingleheimerschmidt έγραψε:
>> On 02/24/14 15:02, George Mpouras wrote:
>>> 1) at the very start (before the header) I check if the user have the
>>> cookie and if contain a valid data. In this case the user is redirected
>>> immediately to the "final" page
>>>
>>> 2) In case there is no cookie, or if the cookie data are not valid, The
>>> user must fill a form.
>>> If the form data validated successfully, then a cookie must be sent at
>>> user's browser , and redirected to the final page (here is the
>>> difficulty is to send the cookie after the submission and validation)
[...]
>> #!/usr/bin/perl
>> use CGI;
>> use CGI::Carp qw(fatalsToBrowser);
>> use strict;
>>
>> my $cgi=new CGI;
>>
>> if ($cgi->cookie('valid') eq 'valid') {
>> print $cgi->redirect("/final");
>> exit;
>> };
>>
>> if (not $cgi->param()) {
>> print $cgi->header(), $cgi->start_html(), $cgi->start_form();
>> print $cgi->textfield('foo');
>> print $cgi->submit();
>> exit;
>> };
>>
>> if ($cgi->param('foo') eq 'valid') {
>> print $cgi->redirect(
>> -uri => "/final",
>> -cookie=>$cgi->cookie('valid','valid')
>> );
>> exit;
>> };
>>
>> die "Form was submitted, but was not valid";
>
>
> Xho,
>
> I hope you understand that you can not redirect if you print the header
> I hope you understand that you can not send a cookie after the header
> is printed.
I haven't tested this myself but the code above will neither try to set
a cookie after printing the header nor try to redirect. That's possibly
somewhat non-obvious because all processing logic 'hides' itself in
if-blocks.
------------------------------
Date: Tue, 25 Feb 2014 04:18:55 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: cookie
Message-Id: <lei1nf$jfs$2@dont-email.me>
On 2/24/2014 10:06, George Mpouras wrote:
> I want to send a cookie to users’ browser (using the CGI) after evaluating a form. The problem is that you can send a cookie only at the header and the forms can be only after start_html . any idea ?
This is all pretty simple. Don't generate any HTML until
you have finished all your processing. Then send your
header and any cookies followed by your HTML code.
And you don't really need CGI to send back the HTML/form/header/cookie,
you can do all that just by printing it - just need a blank line after
the header lines.
------------------------------
Date: Tue, 25 Feb 2014 19:37:21 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: cookie
Message-Id: <slrnlgpon1.ul9.hjp-usenet3@hrunkner.hjp.at>
On 2014-02-25 09:37, George Mpouras <gravitalsun@hotmail.foo> wrote:
> Στις 25/2/2014 05:29, ο/η Xho Jingleheimerschmidt έγραψε:
>> In particular, if you don't print the header too early, you will not
>> have a problem with the header having been printed too early. Simply
>> delay printing the header until until you know you don't need to redirect.
>>
>> #!/usr/bin/perl
>> use CGI;
>> use CGI::Carp qw(fatalsToBrowser);
>> use strict;
>>
>> my $cgi=new CGI;
>>
>> if ($cgi->cookie('valid') eq 'valid') {
>> print $cgi->redirect("/final");
>> exit;
>> };
>>
>> if (not $cgi->param()) {
>> print $cgi->header(), $cgi->start_html(), $cgi->start_form();
>> print $cgi->textfield('foo');
>> print $cgi->submit();
>> exit;
>> };
>>
>> if ($cgi->param('foo') eq 'valid') {
>> print $cgi->redirect(
>> -uri => "/final",
>> -cookie=>$cgi->cookie('valid','valid')
>> );
>> exit;
>> };
>>
>> die "Form was submitted, but was not valid";
>
>
> Xho,
>
> I hope you understand that you can not redirect if you print the header
> I hope you understand that you can not send a cookie after the header is
> printed.
Tho cookie is sent *in* the header. That's what Xho's script does. Your
objections are pointless.
(I agree that CGI.pm makes it a bit hard to see what happens. For
learning it would probably be better to print the headers and the html.)
> your code do not come even close to work.
You obviously didn't try it. It works.
> It is very tricky and can not be done without very carefully design and
> testing.
Actually it's rather simple if you understand the request-response
nature of HTTP and that the CGI script is invoked for each request.
Try to understand what the script does for these requests:
------------------------------------------------------------------------
GET /xho.cgi HTTP/1.0
------------------------------------------------------------------------
POST /xho.cgi HTTP/1.0
Content-Type: application/x-www-form-urlencoded
valid=invalid
------------------------------------------------------------------------
POST /xho.cgi HTTP/1.0
Content-Type: application/x-www-form-urlencoded
valid=valid
------------------------------------------------------------------------
GET /xho.cgi HTTP/1.0
Cookie: valid=valid
------------------------------------------------------------------------
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Tue, 25 Feb 2014 21:03:09 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Dancer
Message-Id: <leipdh$2b1$1@news.ntua.gr>
Στις 25/2/2014 02:20, ο/η alex.karelas@gmail.com έγραψε:
> I believe you should use a templating system. Place the lists & textboxes in your template. That's a lot easier than with CGI.
>
> - Alex
>
>
> On Friday, February 21, 2014 10:49:09 PM UTC+2, George Mpouras wrote:
>> I try to evolve a little and start using the Dancer instead of CGI !
>>
>>
>>
>> I read some documentation but I still can not find where the drop down
>>
>> lists , textboxes , ... are !
>>
>>
>>
>> I am I missing something important or what ?
>
do you think it will be easier ; these templates are scary !
------------------------------
Date: Tue, 25 Feb 2014 12:35:56 +0000
From: Justin C <justin.1401@purestblue.com>
Subject: Re: Improving bad practice
Message-Id: <cafuta-4c4.ln1@zem.masonsmusic.co.uk>
On 2014-02-23, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth Justin C <justin.1402@purestblue.com>:
>> On 2014-02-20, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> >
>> > NB: This piece of ill thought out advice is rather symptomatic for the
>> > web page in question.
>>
>> If it's ill thought out then I'll just ignore it!
>
> Sorry, I've been meaning to make a proper reply...
No problem, there are no deadlines for replies. :)
> The advice given (extremely poorly expressed) was to get rid of long
> lists of parameters, many of which are simply passed down to subordinate
> functions, by turning the functions into methods on some object and the
> parameters into attributes. This is often good advice, but should not be
> applied indiscriminately; there are often less radical changes to the
> code which have as much benefit.
I understood it differently. I didn't think it suggested number of
parameters, but how many subs they/it are/is handed down through.
And possibly about calling subs from subs within subs within subs...
I'm still struggling with terminology in OO. I use OO perl all the
time (at least, I *think* that's what I'm doing! - mostly with CPAN
modules), but I'm finding it difficult to understand "turning the
functions into methods on some objects and parameters into
attributes".
Working in a more OO way will probably be beneficial to my under-
standing, I just don't see OO solutions to my everyday problems or
tasks. So while I might use OO with the modules I'm using, I tend
to write in a procedural way.
> This is an example from something I'm working on at the moment.
[snip]
> Most of the subordinate methods now just take a single parameter, and
> pull out the information they need: I no longer need to keep track of
> which methods take which arguments, and when I realise a method two or
> three calls down needs a new parameter I don't have to change all the
> intervening methods. Also, I have in fact already added a new parameter:
> the _draw_accidental method needs 'current key signature' information
> that wasn't passed before, but ->draw doesn't need to change to
> accomodate that.
>
> The next step is to turn the hashref into an object. As ever, this
> should not be done 'just to be cool', but there are often concrete
> advantages.
I'm sure there are instances in my code where I should do this, but
I don't always see when it would be useful. Right now I'm thinking
of some of my programs that create/write MS Excel. Module
SpreadSheet::WriteExcel uses OO methods, but I just iterate over
my data and pass it along all serialised. I should probably create
row objects, and cell objects which have content and formatting....
but there are many other situations, now I think about it, where
I should create objects out of my data.
> If I turn my new $params parameter into a DrawCtx object, I can move
> these methods into that class, like this:
[snip]
> and again I've simplified the calling conventions because the object
> already knows information that previously had to be passed in.
>
> The final step in this sort of reorganisation would be to move the
> drawing methods themselves into a Draw::Note class. That is, instead of
> having a Note which knows how to draw itself and a DrawCtx which
> represents the drawing parameters, I would have a Note object which just
> holds the information about the note, a Draw::Note object which knows
> how to draw one note, and a DrawCtx that knows how to build a Draw::Note
> for a given Note.
Yup, I definitely need to think this way. Maybe if I finish the
Alpaca and/or Modern Perl I'll be better placed to work this way.
[snip]
> The web page you quoted is telling you to jump straight to this step. I
> wouldn't necessarily go straight there: it's quite a bit of extra
> complexity just to avoid passing a single parameter around. I haven't
> made this change yet in my code, though I am considering it, because it
> separates 'model' (that is, the data we are representing) from 'view'
> (the mechanism we are using to present that data to the user).
I've been reading about MVC in reference to Dancer, Mojolicious, and
Catalyst. It's one of the concepts I'm trying to get my head around.
> This is a
> useful thing to when there are several different ways to display the
> same data: in my case, I can draw it on a window, I can write it to a
> file, I can convert it into MIDI, and so on, and stuffing all the
> methods for generating all these different representations into the
> basic Note class results in a big unwieldy mess.
I think I should stop jumping in and writing code, and consider what
the problem is I'm trying to solve. Then write tools for a generic
situation rather than just the specific. I think this will get me code
that is more OO.
I've got some hideous DB stuff here. The first stuff I wrote, a cron
job on the DB server extracted data using SQL and emailed it to a
dummy user where procmail called perl to process the data. The next
gen of DB code used SSH, and now I've got an RPC server sitting on
the DB server and handling whatever my main working machine asks for
> Hmm, that was rather long... I hope you got to the end, and it made some
> sort of sense.
Yes, I got to the end. And I've been mulling it over all yesterday,
and a lot of today! Thank you for the comprehensive reply. It's
given me plenty to think about, and I need to think about such
things before I actually start writing code. I think I'm going to
be thinking about this for most of the rest of today too.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Tue, 25 Feb 2014 03:55:23 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: non-working perl script under Windows 2008
Message-Id: <lei0bb$drl$1@dont-email.me>
On 2/24/2014 21:49, Scott Bryce wrote:
> On 2/24/2014 5:47 PM, Jens Thoms Toerring wrote:
>> dr.mtarver@gmail.com wrote:
>>> print "HTTP/1.0 200 OK\n"; print
>>> "Content-type: text/html\n\n";
>>
>> Beside what others have told you: these two lines aren't anything
>> your script is supposed to write out, they are send by the web server
>> all on it's own before it passes what your script did output on to
>> the client.
>
> Actually, no. Your script does need to send them. The web server isn't
> going to assume it knows what type of content/response you want to send
> back to the browser.
The second line and blank after are needed, the first line is only needed
for IIS and non-parsed header (NPH) scripts.
------------------------------
Date: Tue, 25 Feb 2014 18:53:19 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: non-working perl script under Windows 2008
Message-Id: <slrnlgpm4f.ul9.hjp-usenet3@hrunkner.hjp.at>
On 2014-02-25 11:55, $Bill <news@todbe.com> wrote:
> On 2/24/2014 21:49, Scott Bryce wrote:
>> On 2/24/2014 5:47 PM, Jens Thoms Toerring wrote:
>>> dr.mtarver@gmail.com wrote:
>>>> print "HTTP/1.0 200 OK\n"; print
>>>> "Content-type: text/html\n\n";
>>>
>>> Beside what others have told you: these two lines aren't anything
>>> your script is supposed to write out, they are send by the web server
>>> all on it's own before it passes what your script did output on to
>>> the client.
>>
>> Actually, no. Your script does need to send them. The web server isn't
>> going to assume it knows what type of content/response you want to send
>> back to the browser.
>
> The second line and blank after are needed, the first line is only needed
> for IIS and non-parsed header (NPH) scripts.
For normal CGI scripts you should replace the first line with a Status
header:
print "Status: 200\n";
However, since 200 is the default, you can omit it (and most people do).
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpat. -- Ralph Babel
------------------------------
Date: Tue, 25 Feb 2014 12:14:25 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: obj 8-2
Message-Id: <8738j7o0da.fsf@sable.mobileactivedefense.com>
Keith Thompson <kst-u@mib.org> writes:
[...]
> my $answer = undef;
> if (scalar @array > 0) {
> $answer = $array[0];
> foreach my $elem (@array) {
> if ($elem > $answer) {
> $answer = $elem;
> }
> }
> }
Something which also has to be mentioned in this context: It is
generally prudent to write code such that it performs the actions it has
to perform in order to achieve a particular end, not such that it
performs all kinds of additional ones just because "that's less work and
it surely won't hurt". At times, the latter approach has resulted in
interesting fireworks,
http://homepages.inf.ed.ac.uk/perdita/Book/ariane5rep.html
For the given case, this would mean 'loop over the remainder of the array
since the first element has already been dealt with'.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 4152
***************************************
