Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 125 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
125
Dung lượng
0,98 MB
Nội dung
460 Perl: The Complete Reference } close(COMPRESSED) or die "Error in gzcat: $!"; Alternatively, to write information and have it immediately compressed, you can pass input directly to the gzip command: open(COMPRESS, "|gzip - >file.gz") or die "Can't fork: $!"; print COMPRESS "Compressed Data"; close(COMPRESS) or die "Gzip didn't work: $!"; When using pipes, you must check the return status of both open and close. This is because each function returns an error from a different element of the piped command. The open function forks a new process and executes the specified command. The return value of this operation trapped by open is the return value of the fork function. The new process is executed within a completely separate process, and there is no way for open to obtain that error. This effectively means that the open will return true if the new process could be forked, irrespective of the status of the command you are executing. The close function, on the other hand, picks up any errors generated by the executed process because it monitors the return value received from the child process via wait (see the “Creating Child Processes” section, later in this chapter). Therefore, in the first example, you could actually read nothing from the command, and without checking the return status of close, you might assume that the command failed to return any valid data. In the second example, where you are writing to a piped command, you need to be more careful. There is no way of determining the status of the opened command without immediately calling close, which rather defeats the purpose. Instead, you can use a signal handler on the PIPE signal. The process will receive a PIPE signal from the operating system if the piped command fails. Two-Way Communication As convenient as it may seem, you can’t do the following: open(MORE, "|more file|"); This is because a pipe is unidirectional—it either reads from or writes to a piped command. Although in theory this should work, it can result in a deadlocked process where neither the parent nor piped command know whether they should be reading from or writing to the MORE filehandle. TEAMFLY Team-Fly ® Chapter 14: Interprocess Communication 461 PROGRAMMING WITH PERL The solution is to use the open2 function that comes as part of the IPC::Open2 module, which is part of the standard distribution: use FileHandle; use IPC::Open2; $pid = open2(\*READ, \*WRITE, "more file"); WRITE->autoflush(); You can now communicate in both directions with the more command, reading from it with the READ filehandle and writing to it with the WRITE filehandle. This will receive data from the standard output of the piped command and write to the standard input of the piped command. There is a danger with this system, however, in that it assumes the information is always available from the piped command and that it is always ready to accept information. But accesses either way will block until the piped command is ready to accept or to reply with information. This is due to the buffering supported by the standard STDIO functions. There isn’t a complete solution to this if you are using off-the-shelf commands; if you are using your own programs, you’ll have control over the buffering, and it shouldn’t be a problem. The underlying functionality of the open2 function is made possible using the pipe function, which creates a pair of connected pipes, one for reading and one for writing: pipe READHANDLE, WRITEHANDLE We’ll look at an example of this when we look at creating new child processes with fork. Named Pipes A named pipe is a special type of file available under Unix. It resides, like any file, in the file system but provides two-way communication between two otherwise unrelated processes. This system has been in use for some time within Unix as a way of accepting print jobs. A specific printer interface creates and monitors the file while users send data to the named pipe. The printer interface accepts the data, spools the accepted file to disk, and then spawns a new process to send it out to the printer. The named pipe is treated as a FIFO (First In, First Out) and is sometimes simply called a FIFO. You create a named pipe using the mknod or mkfifo command, which in turn creates a suitably configured file on the file system. The following example, system('mknod', 'myfifo', 'p'); is identical to this one: system('mkfifo', 'myfifo'); Once created, you can read from or write to the file just like any normal file, except that both instances will block until there is a suitable process on the other end. For example, here is a simple script (the “server”) that accepts input from a FIFO and writes it into a permanent log file: my $fifo = 'logfifo'; my $logfile = 'logfile.txt'; unless (-p $fifo) { unlink $fifo; if (system('mkfifo','logfifo')) { die "Can't create FIFO: $!"; } } open(FIFO, "<$fifo") or die "Can't open fifo for reading: $!"; open(LOG, ">>$logfile") or die "Can't append to $logfile: $!"; while(<FIFO>) { my $date = localtime(time); print LOG "$date: $_"\n; } close(FIFO) or die "Can't close fifo: $!"; close(LOG) or die "Can't close log: $!"; Here’s the corresponding log reporter (the “client”), which takes input from the command line and writes it to the FIFO: my $fifo = 'logfifo'; die "No data to log" unless @ARGV; open(FIFO,">$fifo") or die "Can't open fifo for writing: $!"; 462 Perl: The Complete Reference PROGRAMMING WITH PERL print FIFO @ARGV; close(FIFO) or die "Can't close fifo: $!"; If you run the “server” (the first script above) and then call the “client,” you should be able to add an entry to the log file. Note, though, that the server will quit once it has accepted one piece of information, because the client closes the pipe (and therefore sends eof to the server) when it exits. If you want a more persistent server, call the main loop within a forked subprocess. For more information, see the discussion of fork later in the “Creating Child Processes” section. Named Pipes Under Windows The Windows named pipe system works slightly differently to that under Unix. For a start, we don’t have access to the mkfifo command, so there’s no immediately apparent way to create a named pipe in the first place. Instead, Windows supports named pipes through the Win32::Pipe module. The Win32::Pipe module provides the same pipe communication functionality using Windows pipes as the built-in functions and the mknod or mkfifo commands do to normal Unix named pipes. One of the biggest differences between Unix and Windows named pipes is that Windows pipes are network compliant. You can use named pipes on Win32 systems to communicate across a network by only knowing the UNC of the pipe—we don’t need to use TCP/IP sockets or know the server’sIP address or name to communicate. Better still, we don’t need to implement any type of communications protocol to enable safe communication across the network—the named pipe API handles that for us. The Windows implementation also works slightly differently from the point of view of handling the named pipe. The server creates the named pipe using the API, which is supported by Perl using the Win32::Pipe module. Once created, the server uses the new pipe object to send and receive information. Clients can connect to the named pipe using either the normal open function or the Win32::Pipe module. Creating Named Pipes When you create a named pipe, you need to use the new method to create a suitable Win32::Pipe object: $pipe = new Win32::Pipe(NAME); The NAME should be the name of the pipe that you want to create. The name you give here can be a short name; it does not have to be fully qualified (see the “Pipe-Naming Conventions” sidebar for more information). Chapter 14: Interprocess Communication 463 464 Perl: The Complete Reference There are some limitations to creating and using pipes: ■ There is a limit of 256 client/server connections to each named pipe. This means you can have one server and 255 client machines talking to it through a single pipe at any one time. ■ There is no limit (aside from the disk and memory) resources of the machine to the number of named pipes that you can create. ■ The default buffer size is 512 bytes, and you can change this with the ResizeBuffer method. ■ All named pipes created using this module are streams, rather than being message based (see note). Dave Roth, the original author of this module, has updated the module, but the updated version is not included as standard in the ActivePerl 615 distribution, though it should have been rolled into the 616 distribution. The new version does allow for message-based communication, where client and server communicate using fixed-size messages, with the buffer size determining the message size. Opening Named Pipes The easiest way to open an existing pipe is to use the open function: open(DATA,NAME); Pipe-Naming Conventions When you are creating a new pipe, you give it a simple name. For example, you can create a pipe called “Status”. Any clients wishing to access the pipe must, however, use the full UNC name of the pipe. Pipes exist within a simple structure that includes the server name and the special “pipe” shared resource. For example, on a machine called “Insentient”, our pipe would be available for use from a client via the name “\\INSENTIENT\pipe\Status”. If you do not know the name of the server, then you should be able to use “\\.\pipe\Status”, where the single dot refers to the current machine. You can also nest pipes in their own structure. For example, you could have two pipes: one in “\\INSENTIENT\pipe\Status\Memory” and the other in “\\INSENTIENT\pipe\Status\Disk”. The structure is not an actual directory, nor is it stored on the file system— it’s just another shared resource made available by the Windows operating system that is accessible using the UNC system. Chapter 14: Interprocess Communication 465 PROGRAMMING WITH PERL NAME is the UNC of the pipe to open. For example: open(DATA,"\\\\INSENTIENT\\pipe\\MCStatus"); Alternatively, and in my experience more reliably, you can use the Win32::Pipe module to open an existing pipe by supplying the UNC name: $pipe = new Win32::Pipe("\\\\INSENTIENT\\pipe\\MCStatus"); Note, in both cases, the use of double backslashes—these are required to ensure that the first backslash is not parsed by the Perl interpreter. Accepting Connections Once the pipe has been created, you need to tell the server to wait for a connection from a client. The Connect method blocks the current process and returns only when a new connection from a client has been received. $pipe->Connect(); Once connected, you can start to send or receive information through the pipe using the Read and Write methods. Note that you do not need to call this method from a client—the new method implies a connection when accessing an existing pipe. Reading and Writing Pipes If you have opened the pipe using open, then you can continue to use the standard print and <FILEHANDLE> formats to write and read information to and from the filehandle pointing to the pipe. If you have used the module to open a pipe, or to create one when developing a server, you need to use the Read and Write methods. The Read method returns the information read from the pipe, or undef if no information could be read: $pipe->Read(); Note that you will need to call Read multiple times until all the information within the pipe’s buffer has been read. When the method returns undef, it indicates the end of the data stream from the pipe. To write to a pipe, you need to use the Write method. This writes the supplied string to the pipe. $pipe->Write(EXPR); 466 Perl: The Complete Reference The method returns true if the operation succeeded, or undef if the operation failed—usually because the other end of the pipe (client or server) disconnected before the information could be written. Note that you write information to a buffer when using the Write method and it’s up to the server to wait long enough to read all the information back. The Pipe Buffer The information written to and read from the pipe is held in a buffer. The default buffer size is 512 bytes. You can verify the current buffer size using the BufferSize method. $pipe->BufferSize() This returns the current size, or undef if the pipe is invalid. To change the buffer size, use the ResizeBuffer method. For most situations, you shouldn’t need to change the buffer size. $pipe->ResizeBuffer(SIZE) This sets the buffer size to SIZE, specified in bytes. Disconnecting and Closing Pipes Once the server end of a pipe has finished using the open pipe connection to the client, it should call the Disconnect method. This is the logical opposite of the Connect method. You should only use this method on the server of a connection—although it’s valid to call it from a client script, it has no effect because clients do not require the Connect method. $pipe->Disconnect(); To actually close a pipe because you have finished using it, you should use the Close method. From a client, this destroys the local pipe object and closes the connection. From a server, the Close method destroys the pipe object and also destroys the pipe itself. Further client connections to the pipe will raise an error. $pipe->Close(); Getting Pipe Errors You can get the last error message raised by the pipe system for a specific pipe by using the Error method. $pipe->Error(); PROGRAMMING WITH PERL When used on a pipe object, it returns the error code of the last operation. An error code of 0 indicates a success. When used directly from the module, that is Win32::Pipe::Error(), the function returns a list containing the error code and associated error string for the last operation, irrespective of the pipe on which it occurred. In general, you should probably use the $^E variable or the Win32::GetLastError functions to obtain an error from a function. For example, $pipe = new Win32::Pipe('MCStatus') or die "Creating pipe: $^E ($!)"; Safe Pipes You might remember that Chapter 8 briefly discusses the different methods you can use to open pipes with the open command. Two of these options are –| and |–, which imply a fork and pipe, providing an alternative method for calling external programs. For example: open(GZDATA,"-|") or exec 'gzcat', 'file.gz'; This example forks a new process and immediately executes gzcat, with its standard output redirected to the GZDATA filehandle. The method is simple to remember. If you open a pipe to minus, you can write to the filehandle, and the child process will receive the information in its STDIN. Opening a pipe from minus enables you to read information that the child sends to its STDOUT from the opened filehandle. This can be useful in situations where you want to execute a piped command when running as a setuid script. More useful in general, though, is the fact that you can use this in combination with exec to ensure that the current shell does not parse the command you are trying to run. Here’s a more obvious version of the previous example that also takes care of the setuid permission status: $child = open(GZCAT, "-|"); if ($pid) { while(<GZCAT>) { print $_; } close(<GZCAT>); } else { ($EUID, $EGID) = ($UID, $GID); exec 'gzcat', 'file.gz'; } Chapter 14: Interprocess Communication 467 Here, the exec’d program will be sending its output (a decompressed version of file.gz) to the standard output, which has in turn been piped through the GZCAT filehandle in the parent. In essence, this is no different from a standard piped open, except that you guarantee that the shell doesn’t mess with the arguments you supply to the function. Executing Additional Processes There are times when you want to run an external program but are not interested in the specifics of the output information, or if you are interested, you do not expect vast amounts of data that needs to be processed. In these situations, a number of avenues are open to you. It’s also possible that you want to create your own subprocess, purely for your own use. You’ve already seen some examples of this throughout this book. We’ll look at both techniques in this section. Running Other Programs To run an external command, you can use the system function: system LIST This forks a new process and then executes the command defined in the first argument of LIST (using exec), passing the command any additional arguments specified in LIST. Execution of the script blocks until the specified program completes. The actual effect of system depends on the number of arguments. If there is more than one argument in LIST, the underlying function called is execvp(). This bypasses the current shell and executes the program directly. This can be used when you do not want the shell to make any modifications to the arguments you are passing. If there is only one argument, it is checked for shell metacharacters. If none are found, the argument is split into individual words and passed to execvp() as usual. If any metacharacters are found, the argument is passed directly to /bin/sh -c (or the current operating system equivalent) for parsing and execution. Note that any output produced by the command you are executing will be displayed as usual to the standard output and error, unless you redirect it accordingly (although this implies metacharacters). If you want to capture the output, use the qx// operator or a piped open. For example: system("rm","-f","myfile.txt"); The return value is composed of the return status of the wait function used on the forked process and the exit value of the command itself. To get the exit value of the command you called, divide the value returned by system by 256. 468 Perl: The Complete Reference Chapter 14: Interprocess Communication 469 PROGRAMMING WITH PERL You can also use this function to run a command in the background, providing you are not dependent on the command’s completion before continuing: system("emacs &"); The preceding example works on Unix, but other operating systems may use different methods. The system function has one other trick. It can be used to let a command masquerade as a login shell or to otherwise hide the process’s name. You do this by using a slightly modified version of the command: system PROGRAM LIST The first argument is an indirect object and should refer to the actual program you want to run. The entries in LIST then become the values of the called program’s @ARGV array. Thus, the first argument becomes the masquerading name, with remaining arguments being passed to the command as usual. This has the added benefit that LIST is now always treated as a list, even if it contains only one argument. For example, to execute a login shell: system {'/bin/sh'} '-sh’; A more convenient method for executing a process, especially if you want to capture the output, is to use the qx// quoting operator: my $hostname = qx/hostname/; This is probably better known as the backticks operator, since you can also rewrite this as my $hostname = `hostname`; The two are completely synonymous. It’s a question of personal taste which one you choose to use. Backticks will be more familiar to shell users, since the same characters are used. The string you place into the `` or qx// is first interpolated, just like an ordinary double-quoted string. Note, however, that you must use the backslash operator to escape characters, such as $and @, that would otherwise be interpreted by Perl. The command is always executed via a shell, and the value returned by the operator is the output of the command you called. Also note that like other quoted operators, you can choose alternative delimiter characters. For example, to call sed from Perl: qx(sed -e s/foo/bar/g <$file); [...]... (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_ IMPLICIT_CONTEXT Built under solaris Compiled at Nov 17 2000 18:12: 25 @INC: /usr/local/lib /perl5 /5. 6.0/i86pc-solaris-thread-multi /usr/local/lib /perl5 /5. 6.0 /usr/local/lib /perl5 /site _perl/ 5. 6.0/i86pc-solaris-thread-multi /usr/local/lib /perl5 /site _perl/ 5. 6.0 /usr/local/lib /perl5 /site _perl PROGRAMMING WITH PERL $ perl -V... have used the -DLEAKTEST directive when compiling Perl) 8192 H Hash dump 16384 X Scratchpad allocation 32768 D Cleaning up 655 36 S Thread synchronization Table 15- 1 Debugging Flags -e commandline The commandline will be interpreted as a single-line Perl script For example, $ perl -e 'print 4 +5, "\n";' will print 9 PROGRAMMING WITH PERL Letter 483 484 Perl: The Complete Reference -Fregex Specifies the pattern... Chapter 15: Other Execution Enhancements 487 -v Prints the version and patch level of the Perl interpreter, but does not execute the interpreter -V[:var] Prints the version and configuration information for the Perl interpreter If the optional var is supplied, it prints out only the configuration information for the specified element as discovered via the Config module Here is the default output from the. .. the command line (via the -e option) Team-Fly® Chapter 15: Other Execution Enhancements 481 2 Contained in the file specified by the first non-option argument to the Perl interpreter 3 Piped in to the interpreter via the standard input This works either if there are no arguments or if there is a command line argument $ perl -p -i.bak -e "s/foo/bar/g" or they can be combined: $ perl -pi.bak -e "s/foo/bar/g"... installarchlib='/usr/local/lib /perl5 /5. 6.0/i86pc-solaris-thread-multi' installprivlib='/usr/local/lib /perl5 /5. 6.0' installsitelib='/usr/local/lib /perl5 /site _perl/ 5. 6.0' installvendorlib='' -w Prints out warnings about possible typographical and interpretation errors in the script Note that this command line option can be overridden by using the no warnings pragma or adjusting the value of the $^W variable in the source... exec, backticks, or other external application callers This is also the directory list searched with the -S command line option PERLLIB PERL5 LIB AM FL Y The colon-separated list of directories used to look for the modules and libraries required for the Perl script Note that this list overrides the values defined within the interpreter This variable is ignored if PERL5 LIB has been set The colon-separated... information on using the Perl debugger PERL5 SHELL This is specific to the Win32 port of Perl (see Chapter 22) It specifies the alternative shell that Perl should use internally for executing external commands via system or Team-Fly® Chapter 15: Other Execution Enhancements 491 backticks The default under Windows NT is to use the standard cmd.exe with the /x/c switches Under Windows 95 the command.com /c... When the script contains a call to the eval function, a new instance of a Perl interpreter is created, and the new interpreter then parses the code within the supplied block or expression at the time of execution Because the code is handled at execution time, rather than compile time, the source code that is executed can be dynamic—perhaps even generated within another part of the Perl script Another... } } The special filehandle ARGV is attached to the current file within the list of files supplied on the command line The effect of the eof function is now changed slightly The statement eof(); only returns the end of file of the last file in the list of files supplied on the command line You have to use eof(ARGV) or eof (without parentheses) to detect the end of file for each file supplied on the. .. process This then returns the program’s exit code to the pseudo-process, which then returns the code to the parent This has two effects First, the process ID returned by fork will not match that of the exec’d process Secondly, the –| and |– formats to the open command do not work Since the operation of fork is likely to change before this book goes to print, you should check the details on the fork implementation . the supplied string to the pipe. $pipe->Write(EXPR); 466 Perl: The Complete Reference The method returns true if the operation succeeded, or undef if the operation failed—usually because the. $!"; 462 Perl: The Complete Reference PROGRAMMING WITH PERL print FIFO @ARGV; close(FIFO) or die "Can't close fifo: $!"; If you run the “server” (the first script above) and then call the. parent when they exit, but unless the signal is caught, or the processes are otherwise acknowledged, they remain within the process table. They are called zombies because they have completed execution