call, but an C<eval>. In such a case additional elements $evaltext and
C<$is_require> are set: C<$is_require> is true if the frame is created by a
C<require> or C<use> statement, $evaltext contains the text of the
-C<eval EXPR> statement. In particular, for a C<eval BLOCK> statement,
+C<eval EXPR> statement. In particular, for an C<eval BLOCK> statement,
$filename is C<(eval)>, but $evaltext is undefined. (Note also that
each C<use> statement creates a C<require> frame inside an C<eval EXPR>)
+frame. C<$hasargs> is true if a new instance of C<@_> was set up for the
frame. C<$hints> and C<$bitmask> contain pragmatic hints that the caller
was compiled with. The C<$hints> and C<$bitmask> values are subject to
change between versions of Perl, and are not meant for external use.
the real name of the user (as opposed to the login name) and other
information pertaining to the user. Beware, however, that in many
system users are able to change this information and therefore it
-cannot be trusted and therefore the $gcos is is tainted (see
+cannot be trusted and therefore the $gcos is tainted (see
L<perlsec>). The $passwd and $shell, user's encrypted password and
login shell, are also tainted, because of the same reason.
C<d_pwchange>, C<d_pwcomment>, and C<d_pwexpire>. Shadow password
files are only supported if your vendor has implemented them in the
intuitive fashion that calling the regular C library routines gets the
-shadow versions if you're running under privilege. Those that
-incorrectly implement a separate library call are not supported.
+shadow versions if you're running under privilege or if there exists
+the shadow(3) functions as found in System V ( this includes Solaris
+and Linux.) Those systems which implement a proprietary shadow password
+facility are unlikely to be supported.
The $members value returned by I<getgr*()> is a space separated list of
the login names of the members of the group.
print $key, '=', $ENV{$key}, "\n";
}
+The returned values are copies of the original keys in the hash, so
+modifying them will not affect the original hash. Compare L</values>.
+
To sort a hash by value, you'll need to use a C<sort> function.
Here's a descending numeric sort of a hash by its values:
open(FOO, "< $file\0");
(this may not work on some bizzare filesystems). One should
-conscientiously choose between the the I<magic> and 3-arguments form
+conscientiously choose between the I<magic> and 3-arguments form
of open():
open IN, $ARGV[0];
semid_ds structure or semaphore value array. Returns like C<ioctl>:
the undefined value for error, "C<0 but true>" for zero, or the actual
return value otherwise. The ARG must consist of a vector of native
-short integers, which may may be created with C<pack("s!",(0)x$nsem)>.
+short integers, which may be created with C<pack("s!",(0)x$nsem)>.
See also C<IPC::SysV> and C<IPC::Semaphore> documentation.
=item semget KEY,NSEMS,FLAGS
be the same order as either the C<keys> or C<each> function would
produce on the same (unmodified) hash.
-Note that you cannot modify the values of a hash this way, because the
-returned list is just a copy. You need to use a hash slice for that,
-since it's lvaluable in a way that values() is not.
+Note that the values are not copied, which means modifying them will
+modify the contents of the hash:
- for (values %hash) { s/foo/bar/g } # FAILS!
- for (@hash{keys %hash}) { s/foo/bar/g } # ok
+ for (values %hash) { s/foo/bar/g } # modifies %hash values
+ for (@hash{keys %hash}) { s/foo/bar/g } # same
As a side effect, calling values() resets the HASH's internal iterator.
See also C<keys>, C<each>, and C<sort>.