professional perl programming wrox 2001 phần 5 pot

Input and Output with Filehandles 453 Opening Filehandles at the System Level Opening files at the system level is handled by sysopen. This, like open, takes a filehandle name and a filename as an argument. Unlike open, sysopen does not take a mode string like > or +<, but a numeric mode made up of several mode flags whose values specify the desired attributes of the filehandle. The Fcntl module defines labels for these numeric flags, such as O_WRONLY for write-only access or O_CREAT to create the file if it does not exist. The mode cannot be combined with the filename as it is with open, instead it comes after the filename as an additional third parameter: use Fcntl; # import standard symbols sysopen SYSHANDLE, $filename, O_WRONLY | O_CREAT; The standard open modes can all be expressed in terms of a sysopen mode value; < is equivalent to O_RDONLY, and > is equivalent to O_WRONLY| O_CREAT| O_TRUNC. The following two statements are actually identical, but phrased differently: # open a file write-only with 'open' open HANDLE, "> $filename"; # open a file write-only with 'sysopen' sysopen HANDLE, $filename, O_WRONLY|O_CREAT|O_TRUNC; Note that sysopen does not create a different sort of filehandle from open. In particular, it does not create an unbuffered handle. Whether or not the filehandle is buffered or unbuffered depends on how we read and write with it. Functions like read, getc, and the readline operator work via the standard IO buffers, while functions like sysread and syswrite bypass them. sysopen itself has no opinion on the use of buffers or not – it merely provides a lower-level way to create filehandles. For the curious coming from a C background: while it is true that sysopen uses the open system call to generate an unbuffered file descriptor, it then uses fdopen to create a filehandle from that file descriptor and returns this to Perl. So sysopen does create a filehandle, even though it does not use the fopen system call. For many applications we only need to supply three parameters to sysopen. (In fact, in many cases we can get away with two, because an open mode flag of 0 is usually equivalent to O_RDONLY. However it is dangerous to assume this, always use the Fcntl symbols.) We can also supply a fourth optional parameter describing the permissions of the file in cases where the file is created. We will come to that in a moment. Open Mode Flags sysopen allows us to specify all manner of flags in the open mode, some generically useful, others very specific, and a few more than a little obscure. The main point of using sysopen rather than open is to gain access to these flags directly, allowing us to create open modes other than the six standard combinations supported by open. Some are relevant only to particular kinds of file, such as terminal devices. The following tables show the flags that are combined to make up the various modes used by open. TEAMFLY Team-Fly ® Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 12 454 Always specify one (and only one) of the primary modes: O_RDONLY Open file for reading only. O_RDWR Open file for reading and writing. O_WRONLY Open file for writing only (not supported on Windows). These are additional modes: O_APPEND Open file for appending. O_CREAT Create file if it does not exist. O_TRUNC Truncate file on opening it (writing). See the table in the 'Creating Filehandles with IO::File' section earlier in the chapter for a comparison of open and sysopen modes to see how these mode flags are combined to create the six modes of open. Some other useful flags we can only access with sysopen include the following: O_BINARY Use binary mode (no newline translation). Text and Binary files O_TEXT Use text mode (do newline translation). O_NONBLOCK Enable non-blocking mode.Non-blocking IO O_NDELAY Alias (usually) for O_NONBLOCK. Semantics may vary on platforms for filehandles that are associated with networking. Additional Modes O_EXCL Create file only if it does not already exist (meaningful only with O_CREAT). If it does exist, fail rather than open it. Non-blocking IO One of the main reasons for using sysopen over open is for non-blocking IO. Normally when a read or write (including a system read or write performed by sysread or syswrite) is performed, the system will wait for the operation to complete. In the case of reading, Perl will wait for input to arrive and only return control to our application when it has something for us. Frequently, however, we do not want to wait because we want to do other things in the meantime, so we use sysopen and the O_NONBLOCK flag, (although it should be noted that the O_NONBLOCK flag is not recognized by Windows at present): use Fcntl; # open serial port read only, non-blocking sysopen SERIAL, '/dev/ttyS0', O_RDONLY|O_NONBLOCK; # attempt to read characters my $key; while (sysread SERIAL, $key, 1) { if (defined $key) { print "Got '$key' \n"; } else { warn "No input available \n"; Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Input and Output with Filehandles 455 # wait before trying again sleep(1); } } # close the port close SERIAL; When non-blocking mode is enabled, it attempts to read from a filehandle. When no data is available it will raise the EAGAIN error in $!. We can get the symbol for EAGAIN from the POSIX module, so a better way to write the above example would have been: use POSIX qw(EAGAIN); use Fcntl; # open serial port read only, non-blocking sysopen SERIAL, '/dev/ttyS0', O_RDONLY|O_NONBLOCK; # attempt to read characters my $key; while (sysread SERIAL, $key, 1) { if (defined ($key)) { print "Got '$key' \n" } else { if ($!==EAGAIN) { warn "No input available \n"; # wait before trying again sleep(1); } else { warn "Error attempting to read: $! \n"; last; } } } # close the port close SERIAL; In this case we have used sysread to read an individual character directly from the serial port. We could also have used read or even getc to do the same thing via the filehandle's buffers. This probably would have been better as the filehandle will read in several kilobytes of characters if it can, and then return them to us one by one. From our perspective there is no difference, but from the point of view of the serial port it makes a lot of difference. The Permissions Mask Since it works at a lower level than open, sysopen also allows us to specify a numeric permissions mask as a fourth argument to sysopen, either in the conventional octal format, or as a combination of flags defined by the :mode import label: # permissions mode, as octal integer open HANDLE, $filename, O_WRONLY|O_CREAT, 0644; Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 12 456 # permissions mode, as set of Fcntl flags: open HANDLE, $filename, O_WRONLY|O_CREAT, S_IRUSR |S_IWUSR |S_IRGRP |S_IROTH; If the open creates the file (generally because O_CREAT is present in the open mode), its permissions are set according to the permissions mask, as modified by the umask value as discussed earlier in the chapter. Otherwise the permissions mask has no effect. Using 'sysopen' via 'IO::File' It is not actually necessary to use sysopen to make use of its features; the new method of IO::File automatically uses sysopen if we give it a numeric mode instead of a string: # 'IO::File' open for read/write using 'open' $fh = new IO::File ($filename, '+<'); # 'IO::File' open for read/write using 'sysopen' $fh = new IO::File ($filename, O_RDWR); Since new can automatically detect a numeric mode flag and pass it to sysopen instead of open, we can also pass in the permissions mask too: # 'IO::File' open for read/write using 'sysopen' with permissions mask $fh = new IO::File ($filename, O_RDWR, 0644); The advantage of IO::File is, of course, that it makes filehandles much easier to manipulate and to pass in and out of subroutines. This makes it a good choice for programming regardless of whether we choose to use open or sysopen underneath. Unbuffered Reading Reading at the standard IO level is handled by Perl functions such as read and print. The unbuffered system-level equivalents are sysread and syswrite. sysread looks suspiciously similar to read at first glance. Like read, it takes a filehandle to read from, a scalar variable to store the result in, a length giving the amount of data to read (or attempt to read), and an optional offset: #!/usr/bin/perl # sysread.pl use warnings; use strict; use POSIX; my $result; die "Usage: $0 file \n" unless @ARGV; sysopen HANDLE, $ARGV[0], O_RDONLY|O_NONBLOCK; Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Input and Output with Filehandles 457 # read 20 chrs into $result my $chrs = sysread HANDLE, $result, 20; if ($chrs == 20) { # got all 20, try to read another 30 chrs into $result after the first 20 $chrs += sysread HANDLE, $result, 30, 20; print "Got '$result' \n"; if ($chrs < 50) { print "Data source exhausted after $chrs characters \n"; } else { print "Read $chrs characters \n"; } } elsif ($chrs > 0) { print "Got '$result' \n"; print "Data source exhausted after $chrs characters \n"; } else { print "No data! \n"; } The return value from sysread is the number of characters successfully read. This may be less than the number requested if the data source runs out, and 0 if there is no data to read. However, note that if O_NONBLOCK is not set, then sysread will wait for more data to arrive rather than returning 0. If there is some data but not enough to satisfy the request then sysread will return when it exhausts the data source. As stated before, Windows does not recognize O_NONBLOCK, so this example will not work properly on that platform. In fact, the above example is more of an example of how to use sysopen (to get a non-blocking filehandle) than it is of how to use sysread, as we could just as easily have used read in this example, and with the same effect. The difference between the two is that read would read as much data as possible in the first call, and the second call would only cause a read of the file if the first failed to retrieve 50 characters. The fact that it only returns 20 to us is irrelevant; buffering stores up the rest until we need them. Of course we might not want to buffer the data; we may want to share the filehandle between different processes instead. In cases like that, we would use sysread. There is no system-level definition of the end-of-file condition, but we can do the equivalent by checking for a zero return from sysread instead. Unbuffered Writing The counterpart to sysread is syswrite, which writes data directly to the filehandle rather than into the filehandle's buffer. This is very useful in all kinds of applications, especially those that involve sending short bursts of information between different processes. syswrite takes a filehandle, some data, a length, and an optional offset as parameters. It then writes data from the string to the filehandle up to the end of the text contained in the scalar, or the value supplied as the length, whichever is shorter. If an offset is supplied, syswrite starts writing data from that character position. For example, this code snippet writes out the contents of the scalar $data to HANDLE (presumably a serial or network connection) at a rate of five hundred characters per second: $pos = 0; $span = 500; $length = length($data); while ($pos <= $length) { syswrite HANDLE, $data, $span, $pos; $pos += $span; sleep 1; } Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 12 458 Unlike sysread, the length is also an optional parameter. If omitted, the length of the supplied data is used instead, making syswrite a close analogue for an unbuffered print, only without the ability to accept a list of arguments. We can invent a sysprint that will work like print using syswrite though: # an unbuffered print-a-like sub sysprint { # check for a leading filehandle and remove it if present $fh = (defined fileno($_[0]))?shift:*STDOUT; # use $, to join arguments, just like print $joiner = $, ?$, :''; syswrite $fh, join($joiner, @_); } sysprint(*STDOUT, "This ", "works ", "like ", "print ", "(sort of) ", "\n"); See the section on pipes in Chapter 22 for another example where sysread and syswrite are useful to avoid deadlocks between communicating processes. System-Level File Positioning The system-level equivalent of the seek and tell functions is sysseek, which carries out both roles. Like seek, it takes a filehandle, a position, and a whence flag that is set to either 0, 1, or 2, or the Fcntl equivalent symbols SEEK_SET, SEEK_CUR, and SEEK_END: # seek using whence numbers sysseek HANDLE, 0, 0; # rewind to start sysseek HANDLE, 0, 2; # seek to end of file sysseek HANDLE, 20, 1; # seek forward 20 characters # seek using Fcntl symbols use Fcntl qw(:seek); sysseek HANDLE, 0, SEEK_SET; # rewind to start sysseek HANDLE, 0, SEEK_END; # seek to end of file sysseek HANDLE, 20, SEEK_CUR; # seek forward 20 characters The old file position is returned by sysseek. To find the current position using sysseek we can simply seek to it using a whence flag of SEEK_CUR and a position of zero: use Fcntl qw(:seek); $pos = sysseek HANDLE, 0, SEEK_CUR; Apart from the difference caused by buffering, sysseek is identical in operation to seek. However, tell and sysseek can (and often do) return radically different values for the file position. This is because the position returned by tell is determined by the amount of data read by our application, whereas the position returned by sysseek is determined by the amount of data read by Perl, which includes the data buffered by the filehandle. We can calculate the amount of data currently buffered by taking the difference between the two values: print "There are ", tell(HANDLE) - sysseek(HANDLE, 0, 1), " bytes in the buffer \n"; Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Input and Output with Filehandles 459 Needless to say, mixing up system-level file positioning with standard IO file positioning is rarely a good idea, for precisely this reason. If we are using print and readline, we should be using seek and tell. If we are using sysread and syswrite, we should be using sysseek instead. 'fcntl' and 'ioctl' No discussion of system-level IO would be entirely complete without a brief look at the fcntl and ioctl functions. These provide very low-level access to filehandles, retrieving and setting parameters that are often otherwise inaccessible to us. fcntl is more generic, and works across most kinds of filehandle. ioctl is targeted at special files, such as character and block devices, and is much more UNIX-specific. Returned values, if any, are placed into a passed scalar variable; the return value is used to indicate success or failure only. Both functions return undef on failure and set the error in $!. Otherwise they either return a positive value (if the underlying system call returns one), or the special return value '0 but true', which returns 0 in a numeric context but tests true otherwise. To get the original underlying return value (which is -1 for failure, 0 or a positive value for success), we can write: # calculate original numeric return value from system 'fcntl' $result = int (fcntl(HANDLE, $action, $value) || -1); Both functions will return a fatal error if used on a platform that does not support the underlying system calls. On Windows, they return 0, but do not actually do anything, although they are not fatal. Setting Filehandle Attributes with 'fcntl' The fcntl function (not to be confused with the Fcntl module) performs miscellaneous actions on a filehandle. It takes three parameters, a filehandle, an action to perform, and a value. For actions that retrieve information this value must be a scalar variable, into which fcntl places the results of the call. The names of the actions are defined, appropriately enough, in the Fcntl module. For example, we can use fcntl to set a filehandle into non-blocking mode after we have opened it: use POSIX; use Fcntl qw(:mode); # get the current open mode flags my $mode; fcntl HANDLE, F_GETFL, $mode; # add O_NONBLOCK and set fcntl HANDLE, F_SETFL, $mode | O_NONBLOCK; A reasonably complete list of actions (some platform-specific) supported by fcntl follows. Consult the system documentation for details of which actions fcntl supports on a particular platform; it may vary from the list below. This action duplicates the underlying file descriptor: F_DUPFD Duplicate the file descriptor, returning the new descriptor. A low-level version of open's & mode. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 12 460 The following actions get or set the close-on-exec flag. This flag determines whether the filehandle survives across an exec call. Normally STDIN, STDOUT, and STDERR survive and other filehandles are closed. The threshold for new filehandles can be set with the special variable $^F. The F_SETFD action allows the flag of an individual, and already extant, filehandle to be modified. F_GETFD Read the close-on-exec flag. File descriptors with this flag set are closed across a call to exec. F_SETFD Set the close-on-exec flag. For example, to preserve a filehandle across exec we would use: fcntl HANDLE, F_SETFD, 0; The following actions get and set the mode flags of the filehandle, as specified by open modes like > or sysopen mode flags like O_RDONLY: F_GETFL Get the open mode flags, as set by open or sysopen. A combination of flags such as O_RDONLY, O_CREAT, O_APPEND, and so on. F_SETFL Set the open mode flags. Usually only the flags O_APPEND, O_ASYNC (Linux/BSD), and O_NONBLOCK can be set, others are unaffected. See above for an example. The following actions, which handle discretionary file locking, are similar to but not the same as the flock system call (unless flock is implemented in terms of fcntl, which is sometimes the case). For most purposes, flock is a lot simpler and more portable, but may not work on network-mounted filesystems (for example, Via NFS). See the flock discussion earlier in the chapter for a more detailed comparison of the two approaches (and how Perl's own flock relates to them). F_GETLK Determine if a file is locked or not. The parameter needs to be a scalar variable, into which details of the lock are written. The l_type field is set to F_UNLCK if no lock is present. F_SETLK Set a lock, returning immediately with undef on failure. The parameter needs to be a packed flock structure containing the lock details. $! is set to the reason for the failure if the lock attempt fails. F_SETLKW Set a lock, waiting for the file to become available if necessary. Returns undef if interrupted. The lock type can be one of F_RDLCK, F_WRLCK, or F_UNLCK, which have the obvious meanings. There is no nonblock flag as there is for flock because that function is handled by F_SETLK and F_SETLKW. However, the values passed and returned to these actions are packed lock structures (not simple values), so we need to use pack and unpack to create arguments that are suitable for fcntl when using these actions. Here is a short script that implements a generic locking subroutine, three specific lock subroutines that use it, and a quick demonstration of using them: #!/usr/bin/perl # fcntl.pl use warnings; use strict; use Fcntl; Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Input and Output with Filehandles 461 # generic lock subroutine sub _do_lock { my ($locktype, $fh, $block) = @_; $block |= 0; # don't block unless asked to # is this a blocking or non-blocking attempt my $op = $block?F_SETLKW:F_SETLK; # pack a structure suitable for this operation my $lock = pack('sslls',$locktype, 0, 0, 0, 0); # establish the chosen lock in the chosen way my $res = fcntl($fh, $op, $lock); seek($fh, 0, 0); return $res; } # specific lock types sub read_lock {return _do_lock(F_RDLCK, @_);} sub write_lock {return _do_lock(F_WRLCK, @_);} sub undo_lock {return _do_lock(F_UNLCK, @_);} # called like this: open MYHANDLE, "+> myfile" or die "Failed to open: $! \n"; # block write lock write_lock(*MYHANDLE, 1) or die "Failed to lock: $! \n"; print MYHANDLE "Only I can write here \n"; # undo (can't block anyway) undo_lock(*MYHANDLE) or die "Failed to unlick: $! \n"; close MYHANDLE; If (assuming the platform supports it) the O_ASYNC mode flag is specified in sysopen (or enabled using fcntl and F_SETLF), then signals are generated by open file descriptors whenever reading or writing becomes possible, which allows us to write synchronous IO routines that respond to events. These actions allow the target and type of signal generated to be configured: F_GETOWN Get the process id (or process group) that is receiving signals (SIGIO or SIGURG) on this file descriptor, if the O_ASYNC mode flag is enabled. By default the process id is that of the process that opened the filehandle, that is, us. F_SETOWN Set the process id (or process group) that will receive signals on this file descriptor, if O_ASYNC is enabled. F_GETSIG (Linux only) Get the signal type generated by filehandles with O_ASYNC enabled. The default of zero generates a SIGIO signal, as does a setting of SIGIO. F_SETSIG (Linux only) Set the signal type generated by filehandles with O_ASYNC enabled. The POSIX module also defines symbols for the various signal names. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 12 462 Controlling Devices with 'ioctl' The ioctl function closely resembles fcntl, both in syntax and in operation. Like fcntl, it takes a filehandle, an action, and a value (which in the case of retrieval actions, must be a scalar variable). It also returns '0 but true' on success and undef on failure, setting $! to the reason if so. Also like fcntl, attempting to use ioctl on a platform that does not support it will cause a fatal error. ioctl is an interface for controlling filehandles that are associated with devices, such as serial ports, terminals, CR-ROM drives, and so on. ioctl is a very low-level tool for analyzing and programming the device underlying a filehandle, and it is relatively rarely that we need to use it. Most of the useful ioctl actions are already encapsulated into more convenient modules or are, at the least, handled more elegantly by the POSIX module. However in a few cases it can be useful, so long as we realize that it is not very portable (many platforms do not support it) and that higher-level and more portable solutions are generally preferable. The different actions supported by ioctl can be considerable (as well as highly platform-dependent) since different device categories may support their own particular family of ioctl actions – serial ports have one set, terminals have another, and so on. When Perl is built, it analyzes the underlying system and attempts to compile a list of constant-defining functions, each one corresponding to the equivalent C header file. The most common symbols are placed in sys/ioctl.ph. Other ioctl symbols may be defined in different header files – on a Linux system, CR-ROM ioctls are defined in the header file linux/cdrom.ph. Here's how we can eject a CD on a Linux box: #!/usr/bin/perl # ioctl.pl use warnings; use strict; # require 'linux/cdrom.ph'; open CDROM, '/dev/cdrom'; ioctl CDROM, 0x5309, 1; # the ioctl number for CDROMEJECT # ioctl CDROM, &CDROMEJECT, 1; close CDROM; For a complete list of ioctl actions consult the system documentation for the device type in question – Linux defines ioctls in the manual page ioctl_list. Serial port definitions can also be found in the header files compiled by Perl, /usr/lib/perl5/5.6.0/<platform-type>/bits/ioctls.ph for the actions, ioctl_types.ph for flags such as TCIOM_RTS, and TCIOM_CD in a standard UNIX Perl 5.6 installation. Terminal definitions are covered by the POSIX routines POSIX::Termios and documented in the POSIX module manual page. Note that many of the more common actions performed by ioctl are better handled elsewhere (by several of the standard Perl library modules covered in this chapter). In Chapter 15, the POSIX getattr and setattr routines and the POSIX::Termios module are covered. POSIX IO The POSIX module provides a direct interface to the standard C library upon which Perl is built, including all of the file-handling routines. Most of the time we never need to bother with these since Perl already supports most of them in its own file functions. However, on occasion, the POSIX calls can come in useful, so we will quickly detail what is available. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... filehandles, and the majority of these are identical in every respect to the standard Perl file functions The second works on file descriptors, and is the basis of the system-level IO functions The third is specifically aimed at talking to terminals, and we discuss it further in Chapter 15 Intuitively we might expect Perl' s sys file functions to return and operate on file descriptors (not filehandles),... descriptors; the first is readonly, the second is write-only Identical to Perl' s pipe except that it returns file descriptors, not filehandles read fd, $buf, length Read from a file descriptor Identical to Perl' s sysread except that it uses a file descriptor and not a filehandle write fd, $buf, length Write to a file descriptor Identical to Perl' s syswrite except that it uses a file descriptor and not a filehandle... defining a signal handler: $SIG{ WARN } = { }; # do nothing $SIG{ WARN } = {print LOGFILE @_}; # redirect to install log In fact this may be necessary in any case, since validate (as of Perl 5. 6, at least) fails to properly initialize some of its internal variables leading to Use of uninitialized value warnings We can eliminate these with selective use of no warnings or with a signal handler like the... either map directly onto Perl' s built-in functions (POSIX::getc simply calls CORE::getc for example), or methods in the IO::File (open goes to IO::File::open), IO::Handle (ungetc goes to IO::Handle::getc), or IO::Seekable modules (ftell goes to IO::Seekable::tell) modules In short, there is really no reason to use these functions, and we are almost certainly better off using Perl' s built-in functions... if (fileno(HANDLE1) == fileno(HANDLE2)) { print "Handles are duplicated \n"; } Summary In this chapter we looked at using filehandles as a means of communication between our Perl programs and external data sources We saw that Perl provides us with a rich suite of functions for manipulating filehandles We examined various ways of creating, referring to, reading, and writing to filehandles As well as... Having covered files, we then move to manipulating directories Let's start first by examining how Perl allows us to extract user and group information, which is useful for managing files Chapter 13 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Getting User and Group Information Perl provides built-in support for handling user and group information on UNIX platforms through... man 5 passwd) for exact details of what fields are provided on a given platform 468 Manipulating Files and Directories Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Field Name Number Meaning name 0 The login name of the user passwd 1 The encrypted password Depending on the platform, the password may be encrypted using the standard UNIX crypt function, or the more secure MD5... a scalar context, it returns just the group name: #!/usr/bin /perl # listgroups.pl use warnings; use strict; my @groups; while (my $name = getgrent) { push @groups, $name; } print "Groups: @groups \n"; 473 Team-Fly® Chapter 13 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com As with getpwent, using getgrent causes Perl (or more accurately, the underlying C library) to open a... The returned list of values is identical to that returned by Perl' s stat dup fd Duplicate an existing file descriptor, returning the number of the new file descriptor Equivalent to the open mode &, except it returns a file descriptor dup2 oldfd, newfd Make newfd a duplicate of oldfd, closing newfd first if it is currently open No direct Perl equivalent open file, mode, perm Open a file descriptor... Perl supports the UNIX model natively, partly because it grew up on UNIX, but mostly because UNIX file permissions are closely related to the file system This is academic for many platforms; Windows 9x and MacOS prior to version X do not comprehend permissions at all, and Windows NT has its own security model, which we access with the Win32::FileSecurity and Win32::FilePermissions modules instead Perl . files compiled by Perl, /usr/lib /perl5 /5. 6.0/<platform-type>/bits/ioctls.ph for the actions, ioctl_types.ph for flags such as TCIOM_RTS, and TCIOM_CD in a standard UNIX Perl 5. 6 installation makes it a good choice for programming regardless of whether we choose to use open or sysopen underneath. Unbuffered Reading Reading at the standard IO level is handled by Perl functions such as. CD on a Linux box: #!/usr/bin /perl # ioctl.pl use warnings; use strict; # require 'linux/cdrom.ph'; open CDROM, '/dev/cdrom'; ioctl CDROM, 0x5309, 1; # the ioctl number for