=item getsockopt SOCKET,LEVEL,OPTNAME
-Returns the socket option requested, or undef if there is an error.
+Queries the option named OPTNAME associated with SOCKET at a given LEVEL.
+Options may exist at multiple protocol levels depending on the socket
+type, but at least the uppermost socket level SOL_SOCKET (defined in the
+C<Socket> module) will exist. To query options at another level the
+protocol number of the appropriate protocol controlling the option
+should be supplied. For example, to indicate that an option is to be
+interpreted by the TCP protocol, LEVEL should be set to the protocol
+number of TCP, which you can get using getprotobyname.
+
+The call returns a packed string representing the requested socket option,
+or C<undef> if there is an error (the error reason will be in $!). What
+exactly is in the packed string depends in the LEVEL and OPTNAME, consult
+your system documentation for details. A very common case however is that
+the option is an integer, in which case the result will be an packed
+integer which you can decode using unpack with the C<i> (or C<I>) format.
+
+An example testing if Nagle's algorithm is turned on on a socket:
+
+ use Socket;
+
+ defined(my $tcp = getprotobyname("tcp"))
+ or die "Could not determine the protocol number for tcp";
+ # my $tcp = Socket::IPPROTO_TCP; # Alternative
+ my $packed = getsockopt($socket, $tcp, Socket::TCP_NODELAY)
+ or die "Could not query TCP_NODELAY SOCKEt option: $!";
+ my $nodelay = unpack("I", $packed);
+ print "Nagle's algorithm is turned ", $nodelay ? "off\n" : "on\n";
+
=item glob EXPR
to the temporary file first. You will need to seek() to do the
reading.
-File handles can be opened to "in memory" files held in Perl scalars via:
+Since v5.8.0, perl has built using PerlIO by default. Unless you've
+changed this (ie Configure -Uuseperlio), you can open file handles to
+"in memory" files held in Perl scalars via:
open($fh, '>', \$variable) || ..
}
}
+See L<perliol/> for detailed info on PerlIO.
+
You may also, in the Bourne shell tradition, specify an EXPR beginning
with C<< '>&' >>, in which case the rest of the string is interpreted
as the name of a filehandle (or file descriptor, if numeric) to be
< sSiIlLqQ Force little-endian byte-order on the type.
jJfFdDpP (The "little end" touches the construct.)
+The C<E<gt>> and C<E<lt>> modifiers can also be used on C<()>-groups,
+in which case they force a certain byte-order on all components of
+that group, including subgroups.
+
The following rules apply:
=over 8
=item *
-All integer and floating point formats as well as C<p> and C<P> may
-be followed by the C<E<gt>> or C<E<lt>> modifiers to force big- or
-little- endian byte-order, respectively. This is especially useful,
-since C<n>, C<N>, C<v> and C<V> don't cover signed integers, 64-bit
-integers and floating point values. However, there are some things
-to keep in mind.
+All integer and floating point formats as well as C<p> and C<P> and
+C<()>-groups may be followed by the C<E<gt>> or C<E<lt>> modifiers
+to force big- or little- endian byte-order, respectively.
+This is especially useful, since C<n>, C<N>, C<v> and C<V> don't cover
+signed integers, 64-bit integers and floating point values. However,
+there are some things to keep in mind.
Exchanging signed integers between different platforms only works
if all platforms store them in the same format. Most platforms store
It is definetely not a general way to portably store floating point
values.
+When using C<E<gt>> or C<E<lt>> on an C<()>-group, this will affect
+all types inside the group that accept the byte-order modifiers,
+including all subgroups. It will silently be ignored for all other
+types. You are not allowed to override the byte-order within a group
+that already has a byte-order modifier suffix.
+
=item *
Real numbers (floats and doubles) are in the native machine format only;
# exactly the same
$foo = pack('s<l<', -42, 4711);
# pack little-endian 16- and 32-bit signed integers
+ $foo = pack('(sl)<', -42, 4711);
+ # exactly the same
The same template may generally also be used in unpack().
select(undef, undef, undef, 0.25);
Note that whether C<select> gets restarted after signals (say, SIGALRM)
-is implementation-dependent.
+is implementation-dependent. See also L<perlport> for notes on the
+portability of C<select>.
B<WARNING>: One should not attempt to mix buffered I/O (like C<read>
or <FH>) with C<select>, except as permitted by POSIX, and even
Some of the most common values are C<O_RDONLY> for opening the file in
read-only mode, C<O_WRONLY> for opening the file in write-only mode,
-and C<O_RDWR> for opening the file in read-write mode, and.
+and C<O_RDWR> for opening the file in read-write mode.
For historical reasons, some values work on almost every system
supported by perl: zero means read-only, one means write-only, and two
In many systems the C<O_EXCL> flag is available for opening files in
exclusive mode. This is B<not> locking: exclusiveness means here that
-if the file already exists, sysopen() fails. The C<O_EXCL> wins
-C<O_TRUNC>.
-
-Sometimes you may want to truncate an already-existing file: C<O_TRUNC>.
+if the file already exists, sysopen() fails. C<O_EXCL> may not work
+on network filesystems, and has no effect unless the C<O_CREAT> flag
+is set as well. Setting C<O_CREAT|O_EXCL> prevents the file from
+being opened if it is a symbolic link. It does not protect against
+symbolic links in the file's path.
+
+Sometimes you may want to truncate an already-existing file. This
+can be done using the C<O_TRUNC> flag. The behavior of
+C<O_TRUNC> with C<O_RDONLY> is undefined.
You should seldom if ever use C<0644> as argument to C<sysopen>, because
that takes away the user's option to have a more permissive umask.