How to use select (select(2)) in Perl?

[Kenny McCormack]

I'm not following the details of this thread, but is there anything
that prevents you from looking into the documentation of vec() for
more info on vec() rather than into that of select()?

The issue - the issue that I have - is that the nowhere in the
documentation that I have (that is, the man pages and the PP book), does it
*say* what the select() call does to the args passed to it and that you
should check those bits after the call, in a manner analagous to how you
are used to doing so in C, using "vec()" instead of FD_ISSET.

One can infer this - and the discussion on this thread, despite the noise,
has been helpful in leading to infer it. Thanks.

The issue is not finding what documentation there is - I know how to read
man pages; I know how to run the perldoc program. The issue is as stated
above.

 

[Sam Holden]

The issue - the issue that I have - is that the nowhere in the
documentation that I have (that is, the man pages and the PP book), does it
*say* what the select() call does to the args passed to it and that you
should check those bits after the call, in a manner analagous to how you
are used to doing so in C, using "vec()" instead of FD_ISSET.

From perldoc -f select:
This calls the select(2) system call with the bit masks specified

From man select:
On exit, the sets are modified in place to indicate which
descriptors actually changed status.

Bit vectors are accessed via vec in perl, a simple look through the
perlfunc documentation makes that obvious, the fact that they are mentioned
in the perlfunc description of select makes it more obvious.

They aren't mentioned for checking the results of select because in
perl setting and reading them are done the same way, hence there's no
need to mention that way twice. And more importantly in perl select(2)
isn't done via the select function anymore, it is done via IO::Select.
People who know enough to not use the standard method will know enough to
know how to use vec.

The perl documentation isn't written with people who have a "I want to
do it in perl but without using standard modules" attitude, just like
all those C books aren't written with people who have a "I want to do it
in C but without using functions".

The issue is not finding what documentation there is - I know how to read
man pages; I know how to run the perldoc program. The issue is as stated
above.

The perl docs reference system specific documentation for system specific
functions. select is one of those functions. This is pretty damn obvious
by the "This calls the select(2) system call" bit at the start of
the documentation.

 

[Anno Siegel]

[...]

(And, please, no snotty comments about using modules and other silliness)

Talk about snotty... So long.

Anno

 

[Anno Siegel]

[...]

Do you mean "won't" or "can't?"

[...]

The former. The short answer is: I have my reasons and I should not have
to answer this question.

Of course you have to, who do you think you are? You're asking for Perl
help, and you're one in a long line.

You reject the standard solution, you got to give us a damn good reason why.
Nobody is going to adapt it to your highness' requirements just because
you "have your reasons".

Next.

Anno

 

[Matt Garrish]

If you refuse to use them, you should not
expect a huge amount of help from the Perl community, who recognize
their essentiality (it's a word now, dammit!).

Always has been a word. Am I missing something?

Matt

 

[Tad McClellan]

Talk about snotty... So long.

I so-longed him nearly 3 years ago when he did the same thing.

Message-ID: <[email protected]>

 

[Chris Mattern]

I so-longed him nearly 3 years ago when he did the same thing.

Message-ID: <[email protected]>

I've been amusing myself with Google. Yep, he was just the same in his
last go-round in this group. Still insisting other posters *must* solve
his problems *his* way, still insisting that he be able to code his
solution with *no* modules, astounded that this made his job ten times
harder, and still flaming anybody with the termerity to point out that
it was that insistance that was making his job ten times harder.

Chris Mattern

 

[David H. Adler]

Always has been a word. Am I missing something?

Possibly the difference between an 'i' and an 'l'...

dha

 

[Michele Dondi]

As I said, the documentation for select() shows how to use vec() as an
lvalue to build up the bits objects for the call, but they don't show how
to parse what comes back. It seems to assume you already know how to do it
from C.

I'm not following the details of this thread, but is there anything
that prevents you from looking into the documentation of vec() for
more info on vec() rather than into that of select()?

perldoc -f vec


HTH,
Michele

 

[Kenny McCormack]

I've been amusing myself with Google. Yep, he was just the same in his
last go-round in this group. Still insisting other posters *must* solve
his problems *his* way, still insisting that he be able to code his
solution with *no* modules, astounded that this made his job ten times
harder, and still flaming anybody with the termerity to point out that
it was that insistance that was making his job ten times harder.[/QUOTE]

I'm not insisting anything. You can do as you please. I'm just amused by
all the theatrics involved in you folks posting techniques that
I can't/won't (and yes, for the purposes of this discussion, these are
synonyms) use. You might as well be posting to /dev/null.

It has been fun; I'll probably do it again in another 3 years (that's about
how often I have a Perl problem).

 

[Keith Keller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not insisting anything. You can do as you please. I'm just amused by
all the theatrics involved in you folks posting techniques that
I can't/won't (and yes, for the purposes of this discussion, these are
synonyms) use. You might as well be posting to /dev/null.

You can certainly believe that can't/won't are synonyms in this
context. I'm not sure many others agree with you; and while you
don't care about libraries, others searching using groups.google.com
might.

It has been fun; I'll probably do it again in another 3 years (that's about
how often I have a Perl problem).

The post Tad quoted was from two years ago. At that rate I guess
we'll have the same argument sooner than you think.

- --keith

- --
(e-mail address removed)-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFACvjahVcNCxZ5ID8RAv0SAJ9Ok4GyejaM2QwOrffjSg4YKGjEugCfTF8A
756oyVU12vx2ahp6zRaW71M=
=hinK
-----END PGP SIGNATURE-----

 

[Jürgen Exner]

Kenny McCormack wrote:
[...]

these are synonyms) use. You might as well be posting to /dev/null.

It has been fun; I'll probably do it again in another 3 years (that's
about how often I have a Perl problem).

I think people like you are commonly knows as trolls.
So long then

jue

 

[Christopher Hamel]

It has been fun; I'll probably do it again in another 3 years (that's about
how often I have a Perl problem).

http://groups.google.com/groups?hl=...btnG=Google+Search&meta=group%3Dcomp.lang.awk

Recognized the name as one of the most outspoken Perl haters on
comp.lang.awk... Note the first line in his reponse from the thread
referenced above, referring to the "disease known as Perl."

Oh yeah, this guy's objective.

 

[Uri Guttman]

CH> http://groups.google.com/groups?hl=...btnG=Google+Search&meta=group%3Dcomp.lang.awk

CH> Recognized the name as one of the most outspoken Perl haters on
CH> comp.lang.awk... Note the first line in his reponse from the thread
CH> referenced above, referring to the "disease known as Perl."

what is awk, some ancient babylonian language?

how anyone can love awk and hate perl is beyond me. and obviously beyond
the OP. i won't be waiting 3 more years just to ignore him again.

BTW, no wonder he hates modules - awk doesn't have any!

and i did tons of awk/shell before i graduated to perl4. i can barely
remember the last awk thing i did (a one liner?) and i do shell only
when absolutely necessary (rc.*, existing shell scripts, etc.)

uri

 

[Joe Smith]

I think the documentation of select() is cryptic even by Perl standards.

I agree. Back in the days of perl4, the docs for many functions
basically said "works like the function with the same name in the
C library". There was no need to duplicate what was in the man
pages since everyone who had perl had access to the `man` command.

Nowadays there are many users that have `perldoc` but not `man`.
Not all the PODs have been rewritten to be complete enough to
stand alone.
-Joe

 

[Joe Smith]

(e-mail address removed) (Kenny McCormack) wrote:
} >You want to use the IO::Select module. Read 'perldoc IO::Select'.
}
} Thanks, but no thanks. I don't use modules.

That whole can of worms aside, you could always just read the source code
of IO::Select *itself* and see how it does it.

But that would mean having to read and understand perl-5 syntax.
(No emoticon here; I'm trying to keep a straight face.)
-Joe

 

[Ben Morrow]

I agree. Back in the days of perl4, the docs for many functions
basically said "works like the function with the same name in the
C library". There was no need to duplicate what was in the man
pages since everyone who had perl had access to the `man` command.

Nowadays there are many users that have `perldoc` but not `man`.
Not all the PODs have been rewritten to be complete enough to
stand alone.

The only needed addition is 'do not use this, use IO::Select instead'.

Ben

 

[Kenny McCormack]

I agree. Back in the days of perl4, the docs for many functions
basically said "works like the function with the same name in the
C library". There was no need to duplicate what was in the man
pages since everyone who had perl had access to the `man` command.

Keep in mind that the original post makes it clear that I *am* familiar
with the C function (The original content was: I know how to do this in C;
how do I do it in Perl?)

The one piece of information that was missing was that you would check the
bits with vec() after the select() call returns. I.e., that vec() is
FD_ISSET (among other things). This information is, of course, intuitable,
but it would have been better for it to have been made explicit.

That's all.

 

[Ben Morrow]

}
} The only needed addition is 'do not use this, use IO::Select instead'.

I disagree -- perhaps *AFTER* you clearly document how it actually works
and how it is supposed to be used you could refer users to
IO::Select,

The point is that it *isn't* supposed to be used. Since IO::Select was
made core, the select function it is based on should really be
considered internal to that module.

but having a ref like that in *place* of documenting the machinery
just ain't right, IMO

So do you want documentation on how 'use strict' works, or
Filter::Util::Call? The point of these modules is that you don't need
to know how the internals work.

I'll note that it was basically impossible [probably still is] to
figure out quite how "use vars" works -- the necessary tricks [which
I can't even remember] just aren't documented, and reading the code
for 'use vars' doesn't reveal the magic

Ummm.... as far as I can see it's perfectly clear. 'use vars
qw/$foo/;' (called from package 'My:ack') chops the '$' off '$foo',
makes sure it's fully qualified, does some error checking and then
executes

*My:ack::foo = \$My:ack::foo;

.. The reason why this stops the error is not explained anywhere in the
perl docs, I grant you, but it isn't hard to figure out. strict 'vars'
gives an error for a given package variable iff it doesn't already
exist in the symbol table (at compile time). The expression above
causes the entry for $My:ack::foo to be created; as it's happening
in a 'use' statement, code that is after it in the file will be
compiled with that variable existing.

At the risk of sounding arrogant, I would say that if you can't work
that out for yourself you are better off not knowing it. Hell, I
worked that out for myself and *I'd* probably be better off not
knowing it: certainly, I avoid using that knowledge whenever I can
(basically, always).

I'd prefer that there were _fewer_ "this is magic, use the module"
parts of Perl rather than more...

The point is that core modules like 'strict', 'vars', 'IO::Select' and
'IO::Socket' should be considered part of the Perl language, in the
same way as stdio is considered part of C. You do not need to know how
they work, just as you do not need to know how perly.c works.

If you want to find out, feel free to read the source and do so, and I
for one will be more than happy to tell you what I know (which isn't
much); but be careful to distinguish between 'finding out how the
internals work for curiosity's sake' and 'finding out how the
documented interface works for the sake of using it'.

Ben

 

[Kenny McCormack]

} > Kenny McCormack wrote:
} >
} > > I think the documentation of select() is cryptic even by Perl standards.
} >
} > I agree. Back in the days of perl4, the docs for many functions
} > basically said "works like the function with the same name in the
} > C library". There was no need to duplicate what was in the man
} > pages since everyone who had perl had access to the `man` command.
} >
} > Nowadays there are many users that have `perldoc` but not `man`.
} > Not all the PODs have been rewritten to be complete enough to
} > stand alone.
}
} The only needed addition is 'do not use this, use IO::Select instead'.

I disagree -- perhaps *AFTER* you clearly document how it actually works
and how it is supposed to be used you could refer users to IO::Select, but
having a ref like that in *place* of documenting the machinery just ain't
right.

Gee, a voice of reason. You obviously don't belong in this newsgroup.
The very idea that the paragraph you wrote above could be considered
controversial is proof that this newsgroup really is populated by lunatics.