This is Info file pm.info, produced by Makeinfo version 1.68 from the input file bigpm.texi.  File: pm.info, Node: Proc/SyncExec, Next: Proc/WaitStat, Prev: Proc/Simple, Up: Module List Spawn processes but report exec() errors **************************************** NAME ==== Proc::SyncExec - Spawn processes but report exec() errors SYNOPSIS ======== # Normal-looking piped opens which properly report exec() errors in $!: sync_open WRITER_FH, "|command -with args" or die $!; sync_open READER_FH, "command -with args|" or die $!; # Synchronized fork/exec which reports exec errors in $!: $pid = sync_exec $command, @arg; $pid = sync_exec $code_ref, @command; # run code after fork in kid # fork() which retries if it fails, then croaks() if it still fails. $pid = fork_retry; $pid = fork_retry 100; # retry 100 times rather than 5 $pid = fork_retry 100, 2; # sleep 2 rather than 5 seconds between # A couple of interfaces similar to sync_open() but which let you # avoid the shell: $pid = sync_fhpopen_noshell READERFH, 'r', @command; $pid = sync_fhpopen_noshell WRITERFH, 'w', @command; $fh = sync_popen_noshell 'r', @command_which_outputs; $fh = sync_popen_noshell 'w', @command_which_inputs; ($fh, $pid) = sync_popen_noshell 'r', @command_which_outputs; ($fh , $pid)= sync_popen_noshell 'w', @command_which_inputs; DESCRIPTION =========== This module contains functions for synchronized process spawning with full error return. If the child's exec() call fails the reason for the failure is reported back to the parent. These functions will croak() if they encounter an unexpected system error, such as a pipe() failure or a repeated fork() failure. Nothing is exported by default. fork_retry [*max-retries* [*sleep-between*]] This function runs fork() until it succeeds or until *max-retries* (default 5) attempts have been made, sleeping *sleep-between* seconds (default 5) between attempts. If the last fork() fails fork_retry croak()s. sync_exec [code] command... This function is similar to a fork()/exec() sequence but with a few twists. sync_exec does not return until after the fork()ed child has already performed its exec(). The synchronization this provides is useful in some unusual circumstances. Normally the pid of the child process is returned. However, if the child fails its exec() sync_exec returns undef and sets $! to the reason for the child's exec() failure. Since the @cmd array is passed directly to Perl's exec() Perl might choose to invoke the command via the shell if @cmd contains only one element and it looks like it needs a shell to interpret it. If this happens the return value of sync_exec only indicates whether the exec() of the shell worked. The optional initial code argument must be a code reference. If it is present it is run in the child just before exec() is called. You can use this to set up redirections or whatever. If code returns false no exec is performed, instead a failure is returned using the current $! value (or EINTR if $! is 0). If the fork() fails or if there is some other unexpected system error sync_exec croak()s rather than returning. sync_fhpopen_noshell fh type cmd [*arg*]... This is a popen() but it never invokes the shell and it uses sync_exec() under the covers. See `' in this node. The type is either `'r'' to read from the process or 'w' to write to it. The return value is the pid of the forked process. sync_popen_noshell type cmd *arg*... This is like sync_fhpopen_noshell, but you don't have to supply the filehandle. If called in an array context the return value is a list consisting of the filehandle and the PID of the child. In a scalar context only the filehandle is returned. sync_open fh [*open-spec*] This is like a Perl open() except that if a pipe is involved and the implied exec() fails sync_open() fails with $! set appropriately. See `' in this node. Like sync_exec, sync_open croak()s if there is an unexpected system error (such as a failed pipe()). Also like sync_exec, if you use a command which Perl needs to use the shell to interpret you'll only know if the exec of the shell worked. Use sync_fhpopen_noshell or sync_exec to be sure that this doesn't happen. AUTHOR ====== Roderick Schertler <`roderick@argon.org'> SEE ALSO ======== perl(1).  File: pm.info, Node: Proc/WaitStat, Next: Project/Tree, Prev: Proc/SyncExec, Up: Module List Interpret and act on wait() status values ***************************************** NAME ==== Proc::WaitStat - Interpret and act on wait() status values SYNOPSIS ======== $description = waitstat $?; exit waitstat_reuse $?; waitstat_die $?, 'program-name'; close_die COMMAND, 'program-name'; DESCRIPTION =========== This module contains functions for interpreting and acting on wait status values. Nothing is exported by default. waitstat *wait-status* Returns a string representation of wait() status value *wait-status*. Values returned are like `"0"' and `"64"' and `"killed (SIGHUP)"'. This function is prototyped to take a single scalar argument. waitstat_reuse *wait-status* Turn *wait-status* into a value which can be passed to exit, converted in the same manner the shell uses. If *wait-status* indicates a normal exit, return the exit value. If *wait-status* instead indicates death by signal, return 128 plus the signal number. This function is prototyped to take a single scalar argument. waitstat_die *wait-status* *program-name* die() if *wait-status* is non-zero (mentioning *program-name* as the source of the error). This function is prototyped to take two scalar arguments. close_die filehandle name Close filehandle, if that fails die() with an appropriate message which refers to name. This handles failed closings of both programs and files properly. This function is prototyped to take a filehandle (actually, a glob ref) and a scalar. EXAMPLES ======== close SENDMAIL; exit if $? == 0; log "sendmail failure: ", waitstat $?; exit EX_TEMPFAIL; $pid == waitpid $pid, 0 or croak "Failed to reap $pid: $!"; exit waitstat_reuse $?; $output = `some-program -with args`; waitstat_die $?, 'some-program'; print "Output from some-process:\n", $output; open PROGRAM, '| post-processor' or die "Can't fork: $!"; while () { print PROGRAM pre_process $_ or die "Error writing to post-processor: $!"; } # This handles both flush failures at close time and a non-zero exit # from the subprocess. close_die PROGRAM, 'post-processor'; AUTHOR ====== Roderick Schertler <`roderick@argon.org'> SEE ALSO ======== perl(1), IPC::Signal(3pm).  File: pm.info, Node: Project/Tree, Next: Psh/Builtins, Prev: Proc/WaitStat, Up: Module List graphical filesystem / project tree for software developers and webmasters ************************************************************************** NAME ==== Project::Tree - graphical filesystem / project tree for software developers and webmasters SYNOPSIS ======== use Project::Tree; gui; or shell# perl -MProject::Tree -e gui or shell# ptree INSTALLATION ============ First you have to install Kenneth Albanowski's Gtk module (Version 0.500 or newer) and Gurusamy Sarathy's Data::Dumper. The rest is business as usual... perl Makefile.PL make make test make install DESCRIPTION =========== This module is for software developers who have to maintain a lot of files in a software project, e.g. a website with many HTML and/or perl embedded dynamic pages and CGI scripts. Project::Tree is Gtk (Gimp/GNU Toolkit) based and creates a tree view of your software projects, scanning recursevely their top level directories using user configurable regex filters to include/exclude files and subdirectories. The actions for the file items (e.g. start an editor by double click) are configurable in the same way. The module additionally mantains a list of files for quick access. Those files are shown in an extra alphabetically ordered list. A single click on the list item triggers the file action. Each project is represented by a simple identifier which will be the top node of the tree view for this project. CONFIGURATION ============= This version of Project::Tree requires a configuration directory in the home directory of the user. This is the structure of the directory: $HOME/.ptree/open_projects list of currently open projects $HOME/.ptree/quickaccess list of files for quick access $HOME/.ptree/projects/$PROJECT configuration for each project Part of this distribution is a directory called 'example-configuration'. You will find all these files there as a starting point for your private configuration. All configuration files are in Data::Dumper format, so they are even machine and human readable (Data::Dumper is a great tool for this purpose). This release of Project::Tree has no GUI for editing its configuration files. So you have to set them up by hand (this will change in future releases). Only the quickaccess file is actually generated by the program, but this version has no GUI function to remove items from the quickaccess list, so you have to do this by hand (or add this functionality and send me the patch ;) open_projects ------------- This file contains the following definition of currently open projects. $PTREE_OPEN_PROJECTS_LREF = [ 'project1', .., 'projectN' ]; This is a simple list of the project identifiers. quickaccess ----------- This file lists the items of the quick access list. $PTREE_QUICK_ACCESS_LREF = [ { 'name' => '/full/filename', # path to file 'exec' => 'nc -noask %s', # file action 'color' => 'black' # item color }, ... ]; projects/$PROJECT ----------------- This is for project specific configuration. The file has the same name as the project and must be present for each open project. $PTREE_PROJECT_DEFINITION_HREF = { desc => 'CGI Perl Preprocessor', # description root_dir => '/home/joern/projects/CIPP', # root path dir_include => [ # list of regexs for dir inclusion undef # undef means "include all" ], dir_exclude => [ # list of regexs for dir exclusion 'CVS$', # undef means "exclude nothing" ... ], file_include => [ { re => '\\.(cipp|pl|pm)$', # regex for file incl. color => 'red', # color of this files exec => 'nc' # action of this files # (defined below) }, { re => undef, # undef = all files color => 'black', # color exec => 'nc' # action (defined below) }, ... ], file_exclude => [ '.bck$', # regex for file exclusion '.pdf$', ... ], exec => { # definition of file actions nc => 'nc -noask %s' # system call for actions 'nc' } }; The include regexes are computed before the exclude regexes. So the set of included objects will be reduced by the exclude filters. BUGS / TODO =========== This version of the module is based on my first Gtk hack. So the design is slightly messed up (e.g. use of global variables at some points). I want to clean up this in future releases. My main concern is to realize a pure object oriented interface which lets you inherit from this class to add extra funtionality easily. I release this software at this time to evaluate if such a thing is of interest for the public. For me this tool is very interesting, because I want to pick up my files in a second instead of crawling by hand through my filesystems for hours. So I'm very happy about every response of everyone who either downloaded or even use this module. Don't hesitate to send me an email! THANKS TO ========= Kenneth Albanowski for his great job: the Gtk module! AUTHOR ====== Joern Reder, joern@dimedis.de COPYRIGHT ========= Copyright 1999 Joern Reder, All Rights Reserved This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. SEE ALSO ======== perl(1), Gtk (3pm).  File: pm.info, Node: Psh/Builtins, Next: Psh/Completion, Prev: Project/Tree, Up: Module List package for Psh builtins, possibly loading them as needed ********************************************************* NAME ==== Psh::Builtins - package for Psh builtins, possibly loading them as needed SYNOPSIS ======== use Psh::Builtins; DESCRIPTION =========== Psh::Builtins currently contains only the hardcoded builtins of Perl Shell, but may later on be extended to load them on the fly from separate modules. Builtins -------- * `setenv NAME [=] VALUE' Sets the environment variable NAME to VALUE. * `delenv NAME [NAME2 NAME3 ...]' Deletes the names environment variables. * `export VAR [=VALUE]' Just like setenv, below, except that it also ties the variable (in the Perl sense) so that subsequent changes to the variable automatically affect the environment. Variables who are lists and appear in `%Psh::array_exports' will also by tied to the array of the same name. Note that the variable must be specified without any Perl specifier like `$' or `@'. * `cd DIR' Change the working directory to DIR or home if DIR is not specified. The special DIR "-" is interpreted as "return to the previous directory". * `alias [NAME [=] REPLACEMENT]' Add `*NAME*' as a built-in so that NAME will execute exactly as if REPLACEMENT had been entered. For example, one can execute `alias ls ls -F' to always supply the -F option to "ls". Note the built-in is defined to avoid recursion here. With no arguments, prints out a list of the current aliases. With only the `*NAME*' argument, prints out a definition of the alias with that name. * `unalias NAME | -a | all]' Removes the alias with name <`*NAME*' or all aliases if either <`*-a*' (for bash compatibility) or <`*all*' is specified. AUTHOR ====== the Psh team SEE ALSO ======== `psh' in this node  File: pm.info, Node: Psh/Completion, Next: Psh/Job, Prev: Psh/Builtins, Up: Module List containing the completion routines of psh. Currently works with Term::ReadLine::Gnu and Term::ReadLine::Perl. ************************************************************************************************************* NAME ==== Psh::Completion - containing the completion routines of psh. Currently works with Term::ReadLine::Gnu and Term::ReadLine::Perl. SYNOPSIS ======== DESCRIPTION =========== AUTHOR ====== Markus Peter, warp@spin.de Hiroo Hayashi, hiroo.hayashi@computer.org SEE ALSO ========  File: pm.info, Node: Psh/Job, Next: Psh/Joblist, Prev: Psh/Completion, Up: Module List Data structure representing a shell job *************************************** NAME ==== Psh::Job - Data structure representing a shell job SYNOPSIS ======== use Psh::Job; $joblist= new Psh::Joblist(); $job= $joblist->create_job($pid, $command); $job->continue; # send SIGCONT to the job $job->{pid}; # to access the PID of the job $job->{call}; # to access the (command) name of the job $job->{running}; # to check wether the job is running DESCRIPTION =========== This class is to be used in conjunction with Psh::Joblist AUTHOR ====== Markus Peter, warp@spin.de SEE ALSO ======== Psh::Joblist(3).  File: pm.info, Node: Psh/Joblist, Next: Psh/Locale/Base, Prev: Psh/Job, Up: Module List A data structure suitable for handling job lists like bash's ************************************************************ NAME ==== Psh::Joblist - A data structure suitable for handling job lists like bash's SYNOPSIS ======== use Psh::Joblist; $joblist= new Psh::Joblist(); $job = $joblist->create_job($pid,$displayed_command); $joblist->delete_job($pid); $job = $joblist->get_job($pid); $flag = $joblist->job_exists($pid); $index = $joblist->get_job_number($pid); $job = $joblist->find_job(); $job = $joblist->find_job($index); $joblist->enumerate(); while( $job=$joblist->each()) { ... } DESCRIPTION =========== Read the source ;-) AUTHOR ====== Markus Peter (warp@spin.de) SEE ALSO ======== Psh::Job(3)  File: pm.info, Node: Psh/Locale/Base, Next: Psh/Locale/Default, Prev: Psh/Joblist, Up: Module List containing base code for I18N ***************************** NAME ==== Psh::Locale::Base - containing base code for I18N SYNOPSIS ======== DESCRIPTION =========== AUTHOR ====== Markus Peter, warp@spin.de SEE ALSO ========  File: pm.info, Node: Psh/Locale/Default, Next: Psh/Locale/French, Prev: Psh/Locale/Base, Up: Module List containing translations for default locale ****************************************** NAME ==== Psh::Locale::Default - containing translations for default locale SYNOPSIS ======== use Psh::Locale::Default; DESCRIPTION =========== This module contains defaults for all of the internationalized strings in the Perl Shell. Translating Signal Names ------------------------ The text below can be used with Babelfish to generate the signal descriptions for translations. tty output tty input killed floating point exception segmentation fault broken pipe bus error aborted illegal instruction stop typed at TTY interrupt character typed =head2 Translating Messages The text below was used with Babelfish to generate the messages for translations. done. terminated. stopped. restart. foreground. Error: "Foo" failed. Simulating option "W" and "strict". Permission denied. No such directory. No such builtin. Interrupted! "Readline" did not start up properly. No "Readline" module available. Please install "Term::ReadLine::Perl". "%1" is not an alias. Using "Readline": "%1", with features "X" and "Y". Your system does not support job control. "psh" supports the following built-in commands. Sorry, help for builtin %1 is not available. Warning: Expansion of "%1" in prompting message yielded text containing "%2" . Removing escape sequence from substitution. Warning: "Foo" contains unknown escape sequence. "libwin32" required (available as "CPAN" bundle or with "ActivePerl" distribution. AUTHOR ====== Markus Peter, warp@spin.de SEE ALSO ======== Psh::Locale::*  File: pm.info, Node: Psh/Locale/French, Next: Psh/Locale/German, Prev: Psh/Locale/Default, Up: Module List containing translations for French locale ***************************************** NAME ==== Psh::Locale::French - containing translations for French locale SYNOPSIS ======== DESCRIPTION =========== AUTHOR ====== Gregor N. Purdy, gregor@focusresearch.com SEE ALSO ========  File: pm.info, Node: Psh/Locale/German, Next: Psh/Locale/Italian, Prev: Psh/Locale/French, Up: Module List containing translations for German locales ****************************************** NAME ==== Psh::Locale::German - containing translations for German locales SYNOPSIS ======== DESCRIPTION =========== AUTHOR ====== Markus Peter, warp@spin.de SEE ALSO ========  File: pm.info, Node: Psh/Locale/Italian, Next: Psh/Locale/Portuguese, Prev: Psh/Locale/German, Up: Module List containing translations for Italian locale ****************************************** NAME ==== Psh::Locale::Italian - containing translations for Italian locale SYNOPSIS ======== DESCRIPTION =========== AUTHOR ====== Gregor N. Purdy, gregor@focusresearch.com SEE ALSO ========  File: pm.info, Node: Psh/Locale/Portuguese, Next: Psh/Locale/Spanish, Prev: Psh/Locale/Italian, Up: Module List containing translations for Portuguese locale ********************************************* NAME ==== Psh::Locale::Portuguese - containing translations for Portuguese locale SYNOPSIS ======== DESCRIPTION =========== AUTHOR ====== Gregor N. Purdy, gregor@focusresearch.om SEE ALSO ========  File: pm.info, Node: Psh/Locale/Spanish, Next: Psh/OS, Prev: Psh/Locale/Portuguese, Up: Module List containing translations for Spanish locale ****************************************** NAME ==== Psh::Locale::Spanish - containing translations for Spanish locale SYNOPSIS ======== DESCRIPTION =========== AUTHOR ====== Gregor N. Purdy, gregor@focusresearch.com SEE ALSO ========  File: pm.info, Node: Psh/OS, Next: Psh/OS/Mac, Prev: Psh/Locale/Spanish, Up: Module List Wrapper class for OS dependant stuff ************************************ NAME ==== Psh::OS - Wrapper class for OS dependant stuff SYNOPSIS ======== use Psh::OS; DESCRIPTION =========== TBD AUTHOR ====== Markus Peter, warp@spin.de SEE ALSO ========  File: pm.info, Node: Psh/OS/Mac, Next: Psh/OS/Unix, Prev: Psh/OS, Up: Module List Contains Mac specific code ************************** NAME ==== Psh::OS::Mac - Contains Mac specific code SYNOPSIS ======== use Psh::OS; DESCRIPTION =========== TBD AUTHOR ====== blaaa SEE ALSO ========  File: pm.info, Node: Psh/OS/Unix, Next: Psh/OS/Win, Prev: Psh/OS/Mac, Up: Module List contains Unix specific code *************************** NAME ==== Psh::OS::Unix - contains Unix specific code SYNOPSIS ======== use Psh::OS::Unix; DESCRIPTION =========== Implements the Unix specific parts of Psh::OS AUTHOR ====== various  File: pm.info, Node: Psh/OS/Win, Next: Psh/PCompletion, Prev: Psh/OS/Unix, Up: Module List Contains Windows specific code ****************************** NAME ==== Psh::OS::Win - Contains Windows specific code SYNOPSIS ======== use Psh::OS::Win32; DESCRIPTION =========== An implementation of Psh::OS for Win32 systems. This module requires libwin32. AUTHOR ====== Markus Peter, warp@spin.de Omer Shenker, oshenker@iname.com SEE ALSO ========  File: pm.info, Node: Psh/PCompletion, Next: Psh/Parser, Prev: Psh/OS/Win, Up: Module List containing the programmable completion routines of psh. ******************************************************* NAME ==== Psh::PCompletion - containing the programmable completion routines of psh. SYNOPSIS ======== DESCRIPTION =========== This module provides the programmable completion function almost compatible with one of bash-2.04 and/or later. The following document is based on the texinfo file of bash-2.04-beta5. Programmable Completion ======================= ----------------------------------------------- When word completion is attempted for an argument to a command for which a completion specification (a COMPSPEC) has been defined using the complete builtin (See `Programmable Completion Builtins' in this node.), the programmable completion facilities are invoked. First, the command name is identified. If a compspec has been defined for that command, the compspec is used to generate the list of possible completions for the word. If the command word is a full pathname, a compspec for the full pathname is searched for first. If no compspec is found for the full pathname, an attempt is made to find a compspec for the portion following the final slash. Once a compspec has been found, it is used to generate the list of matching words. If a compspec is not found, the default Psh completion described above (Where is it described?) is performed. First, the actions specified by the compspec are used. Only matches which are prefixed by the word being completed are returned. When the -f or -d option is used for filename or directory name completion, the shell variable *FIGNORE* is used to filter the matches. See `ENVIRONMENT VARIABLES' in this node for a description of *FIGNORE*. Any completions specified by a filename expansion pattern to the -G option are generated next. The words generated by the pattern need not match the word being completed. The *GLOBIGNORE* shell variable is not used to filter the matches, but the *FIGNORE* shell variable is used. Next, the string specified as the argument to the -W option is considered. The string is first split using the characters in the *IFS* special variable as delimiters. Shell quoting is honored. Each word is then expanded using brace expansion, tilde expansion, parameter and variable expansion, command substitution, arithmetic expansion, and pathname expansion, as described above (Where is it described?). The results are split using the rules described above (Where is it described?). No filtering against the word being completed is performed. After these matches have been generated, any shell function or command specified with the -F and -C options is invoked. When the function or command is invoked, the first argument is the word being completed, the second argument is the current command line, the third argument is the index of the current cursor position relative to the beginning of the current command line, and the fourth argument is the name of the command whose arguments are being completed. If the current cursor position is at the end of the current command, the value of the third argument is equal to the length of the second argument string. No filtering of the generated completions against the word being completed is performed; the function or command has complete freedom in generating the matches. Any function specified with -F is invoked first. The function may use any of the shell facilities, including the compgen builtin described below (See `Programmable Completion Builtins' in this node.), to generate the matches. It returns a array including the possible completions. For example; sub _foo_func { my ($cur, $line, $start, $cmd) = @_; ... return @possible_completions; } complete -F _foo_func bar Next, any command specified with the -C option is invoked in an environment equivalent to command substitution. It should print a list of completions, one per line, to the standard output. Backslash may be used to escape a newline, if necessary. After all of the possible completions are generated, any filter specified with the -X option is applied to the list. The filter is a pattern as used for pathname expansion; a & in the pattern is replaced with the text of the word being completed. A literal & may be escaped with a backslash; the backslash is removed before attempting a match. Any completion that matches the pattern will be removed from the list. A leading ! negates the pattern; in this case any completion not matching the pattern will be removed. Finally, any prefix and suffix specified with the -P and -S options are added to each member of the completion list, and the result is returned to the Readline completion code as the list of possible completions. If a compspec is found, whatever it generates is returned to the completion code as the full set of possible completions. The default Bash completions are not attempted, and the Readline default of filename completion is disabled. Programmable Completion Builtins ================================ ----------------------------------------------------------------- A builtin commands complete and a builtin Perl function compgen are available to manipulate the programmable completion facilities. compgen compgen [OPTION] [WORD] Generate possible completion matches for *WORD* according to the OPTIONs, which may be any option accepted by the complete builtin with the exception of -p and -r, and write the matches to the standard output. When using the -F or -C options, the various shell variables set by the programmable completion facilities, while available, will not have useful values. The matches will be generated in the same way as if the programmable completion code had generated them directly from a completion specification with the same flags. If *WORD* is specified, only those completions matching *WORD* will be displayed. The return value is true unless an invalid option is supplied, or no matches were generated. complete complete [-abcdefjkvu] [-A ACTION] [-G GLOBPAT] [-W WORDLIST] [-P PREFIX] [-S SUFFIX] [-X FILTERPAT] [-x FILTERPAT] [-F FUNCTION] [-C COMMAND] NAME [NAME ...] complete -pr [NAME ...] Specify how arguments to each NAME should be completed. If the -p option is supplied, or if no options are supplied, existing completion specifications are printed in a way that allows them to be reused as input. The -r option removes a completion specification for each NAME, or, if no NAMEs are supplied, all completion specifications. The process of applying these completion specifications when word completion is attempted is described above (See `Programmable Completion' in this node.). Other options, if specified, have the following meanings. The arguments to the -G, -W, and -X options (and, if necessary, the -P and -S options) should be quoted to protect them from expansion before the complete builtin is invoked. -A ACTION The ACTION may be one of the following to generate a list of possible completions: alias Alias names. May also be specified as -a. arrayvar Names of Perl array variable names. binding Readline key binding names. builtin Names of shell builtin commands. May also be specified as -b. command Command names. May also be specified as -c. directory Directory names. May also be specified as -d. disabled Names of disabled shell builtins (not implemented yet.). enabled Names of enabled shell builtins (not implemented yet.). export Names of exported shell variables. May also be specified as -e. file File names. May also be specified as -f. function Names of Perl functions. hashvar Names of Perl hash variable names. helptopic Help topics as accepted by the `help' builtin. hostname Hostnames. job Job names, if job control is active. May also be specified as -j. keyword Shell reserved words. May also be specified as -k. running Names of running jobs, if job control is active. setopt Valid arguments for the -o option to the set builtin (not implemented yet.). shopt Shell option names as accepted by the shopt builtin (not implemented yet.). signal Signal names. stopped Names of stopped jobs, if job control is active. user User names. May also be specified as -u. variable Names of all Perl variables. May also be specified as -v. -G *GLOBPAT* The filename expansion pattern *GLOBPAT* is expanded to generate the possible completions. -W *WORDLIST* The *WORDLIST* is split using the characters in the *IFS* special variable as delimiters, and each resultant word is expanded. The possible completions are the resultant list. -C *COMMAND* *COMMAND* is executed in a subshell environment, and its output is used as the possible completions. -F FUNCTION The shell function FUNCTION is executed in the current Perl shell environment. When it finishes, the possible completions are retrieved from the array which the function returns. -X *FILTERPAT* *FILTERPAT* is a pattern as used for filename expansion. It is applied to the list of possible completions generated by the preceding options and arguments, and each completion matching *FILTERPAT* is removed from the list. A leading ! in *FILTERPAT* negates the pattern; in this case, any completion not matching *FILTERPAT* is removed. -x *FILTERPAT* Similar to the -X option above, except it is applied to only filenames not to directory names etc. -P PREFIX PREFIX is added at the beginning of each possible completion after all other options have been applied. -S *SUFFIX* *SUFFIX* is appended to each possible completion after all other options have been applied. The return value is true unless an invalid option is supplied, an option other than -p or -r is supplied without a NAME argument, an attempt is made to remove a completion specification for a NAME for which no specification exists, or an error occurs adding a completion specification. AUTHOR ====== Hiroo Hayashi, hiroo.hayashi@computer.org SEE ALSO ======== info manual of bash-2.04 and/or later EXAMPLE ======= `complete_example' in the Psh distribution shows you many examples of the usage of programmable completion. source complete-examples  File: pm.info, Node: Psh/Parser, Next: Psh/PerlEval, Prev: Psh/PCompletion, Up: Module List bla *** NAME ==== Psh::Parser - bla SYNOPSIS ======== DESCRIPTION =========== AUTHOR ====== SEE ALSO ========  File: pm.info, Node: Psh/PerlEval, Next: Psh/Util, Prev: Psh/Parser, Up: Module List package containing perl evaluation codes **************************************** NAME ==== Psh::PerlEval - package containing perl evaluation codes SYNOPSIS ======== use Psh::PerlEval; DESCRIPTION =========== TBD AUTHOR ====== Glen Whitney I think.. SEE ALSO ========  File: pm.info, Node: Psh/Util, Next: PubMed, Prev: Psh/PerlEval, Up: Module List Containing certain Psh utility functions **************************************** NAME ==== Psh::Utils - Containing certain Psh utility functions SYNOPSIS ======== use Psh::Utils (:all); DESCRIPTION =========== TBD AUTHOR ====== blaaa SEE ALSO ========  File: pm.info, Node: PubMed, Next: Puppet/Any, Prev: Psh/Util, Up: Module List class for searching National Library of Medicine ************************************************ NAME ==== WWW::Search::PubMed - class for searching National Library of Medicine SYNOPSIS ======== use WWW::Search; $query = "lung cancer treatment"; $search = new WWW::Search('PubMed'); $search->native_query(WWW::Search::escape_query($query)); $search->maximum_to_retrieve(100); while (my $result = $search->next_result()) { $url = $result->url; $title = $result->title; $desc = $result->description; print $title
$desc

\n"; } DESCRIPTION =========== WWW::Search class for searching National Library of Medicine (PubMed). If you never heard of PubMed, Medline or don't know the difference between a Abstract and Citation - you then can live without this backend. This class exports no public interface; all interaction should be done through WWW::Search objects. AUTHOR ====== `WWW::Search::PubMed' is written and maintained by Jim Smyser . COPYRIGHT ========= WWW::Search Copyright (c) 1996-1998 University of Southern California. All rights reserved. PubMed.pm by Jim Smyser. THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  File: pm.info, Node: Puppet/Any, Next: Puppet/Body, Prev: PubMed, Up: Module List Common base class for lab development tools ******************************************* NAME ==== Puppet::Any - Common base class for lab development tools SYNOPSIS ======== use Puppet::Any ; package myClass ; @myClass::ISA=('Puppet::Any') ; package main ; my $file = 'test.db'; my %dbhash; tie %dbhash, 'MLDBM', $file , O_CREAT|O_RDWR, 0640 or die $! ; my $test = new myClass (name => 'test', dbHash => \%dbhash, keyRoot => 'key root' ); $test->display; $test->setDbInfo(toto => 'toto val', 'titi' => 'titi val', dummy => 'null') ; $test->deleteDbInfo('dummy'); MainLoop ; # Tk's untie %dbhash ; DESCRIPTION =========== Puppet::* classes are designed to provide an access to the "puppeted" object using a GUI based on Tk. The basic idea is when you construct a Puppet::* object, you have all the functionnality of the object without the GUI. Then, when the need arises, you may (or the class may decide to) open the GUI of the object and then the user may perform any interactive he wishes. On the other hand, if the need does not arise, you may instanciate a lot of objects without cluttering your display. For instance, if you have an object (say a ProcessGroup) controlling a set of processes (Process objects). The user may start the ProcessGroup through its GUI. Then all processes are run. If one of them fails, it will raise its own GUI to display the cause of the problem and let the user decide what to do. This class named Puppet::Any is the base class inherited by all other Puppet classes. In this example, Process and Process group both will inherit Puppet::Any. The base class features : - A Tk::Multi::Manager to show or hide the different display of the base class (or of the derived class) - A menu bar - An event log display so derived object may log their activity - A Debug log display so derived object may log their "accidental" activities - An Object Scanner to display the attribute of the derived object - A set of functions to managed "has-a" relationship between Puppet objects. The menu bar feature a "content" bar which enabled the user to open the display of all "contained" objects. - a facility to store data on a database file tied to a hash. The class is designed to store its data in a SINGLE entry of the database file. (For this you should use MLDBM if you want to store more than a scalar in the database). The key for this entry is "$keyRoot;$name". keyRoot and name being passed to the constructor of the object. Needless to say, it's a bad idea to create two instances of Puppet::WithDb with the same keyRoot and name. default bindings ================ is bound to pop-up a Tk object scanner widget. This will be handy to debug the child class you're going to develop. DEFAULT WINDOWS =============== debug log window ---------------- This log window (see Puppet::Log(3)) will get all debug information for this instance of the object. More or less reserved for developers of children of Puppet::Any. Users object inheriting from Puppet::Any must use the printDebug() method to log debug info in this window. event log window ---------------- This log window (see Puppet::Log(3)) will get all event information for this instance of the object. Users object inheriting from Puppet::Any must use the printEvent() method to log debug info in this window. =head1 Object attributes name ---- name of the instance. No treatment or special signification to it except that it can be handy for the debug. content ------- Hash containing the reference of all acquired objects ('name' => ref). topTk ----- Reference of the Tk main window. log --- hash array which contains 'event' and 'debug' Puppet::Log objects. Do not squash it. tk -- Hash containing the following keys : - toplevel: toplevel window ref of this object. - menubar: Frame containing the menu buttons. (you may call MenuButton on it) - contentMnb: ref to the menu managing content (private) - menu: hash containing menu widgets. ('File' for instance) ( you may call command on $self->{tk}{menu}{'File'} to define a new command in the menu for instance) - multiMgr Tk::Multi::Manager buddy ref. When the closeDisplay method is called, it will destroy $self->{tk}{toplevel}, thus it will destroy all Tk widgets and then it will delete the $self->{tk} hash, thus it will delete all internal reference to the destroyed widgets. So you can also test whether your widget has a display by testing if $self->{tk} is defined. The sub-class MUST abide to this rule if the closeDisplay is to work properly. dbHash ------ Tied hash to the database. keyRoot ------- First part of the key to access the database myDbKey ------- The key to access the database Methods ======= new( ... ) ---------- Creates new Puppet object. parameters are : - name - topTk (optionnal, will create a MainWindow if ommitted) - keyRoot - dbHash: ref of the tied hash Note that all other arguments are passed to the Puppet::Log constructors. I.e. you can also specify arguments specific to Puppet::Log->new() through Puppet::Any->new() function. acquire(a_name, a_ref) ---------------------- Acquire the object ref as a child. a_ref must be an object derived of Puppet::Any. Each acquired object must have different names. drop('name') ------------ Destroy child 'name'. display() --------- defines a top level display for each object, contains a MultiText ,a manager and a objScanner. will create an object scanner to scan this object. A debug and an events log objects (Puppet::Log) are created for use by the child class Return 1 if a display is actually created. 0 otherwise (i.e is the display already exists). When overloading display, you may write you function like this : sub display { my $self = shift ; return unless $self->SUPER::display(@_ ); ... } So the display instruction you add will be run only when creating the display. closeDisplay ------------ Close the display. Note that the display can be re-invoked later. printDebug(text) ---------------- Will log the passed text into the debug log object. printEvent(text) ---------------- Will log the passed text into the events log object. showEvent(text) --------------- Will display the 'event' log window. storeDbInfo( key => value, ...) ------------------------------- Store the passed hash in the database. You may also pass a hash ref as single argument. deleteDbInfo( key, ...) ----------------------- delete the "key" entries from the database. AUTHOR ====== Dominique Dumont, Dominique_Dumont@grenoble.hp.com Copyright (c) 1998 Dominique Dumont. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. SEE ALSO ======== perl(1), Tk(3), Puppet::Log(3)  File: pm.info, Node: Puppet/Body, Next: Puppet/Log, Prev: Puppet/Any, Up: Module List Utility class to handle has-a relations and logs ************************************************ NAME ==== Puppet::Body - Utility class to handle has-a relations and logs SYNOPSIS ======== use Puppet::Body ; package myClass ; sub new { my $type = shift ; my $self = {}; $self->{body} = new Puppet::Body(cloth => $self, @_) ; bless $self,$type ; } sub body { return shift->{body} ;} package main ; # create a class with no persistent data my $foo = new myClass (Name => 'foo') ; # foo now has baz and buz $foo->body->acquire(body => $baz); $foo->body->acquire(body => $buz); # foo no longer has $baz $foo->body->drop($baz); DESCRIPTION =========== Puppet::Body is a utility class that is used (and not inherited like the deprecated Puppet::Any) to manage dynamic has-a relations between objects. This class provides the following features : * An event log display so user object may log their activity (with *Note Puppet/LogBody: Puppet/LogBody,) * A Debug log display so user object may log their "accidental" activities(with *Note Puppet/LogBody: Puppet/LogBody,) * A set of functions to managed "has-a" relationship between Puppet objects. Constructor =========== new(...) -------- Creates new Puppet object. New() parameters are: name The name of your object (defaults to "anonymous1" or "anonymous2" ...) cloth The ref of your object how Specify how logs are to be handled. See `"Constructor"', *Note Puppet/LogBody: Puppet/LogBody, Generic methods =============== getName() --------- Returns the name of this object. HAS-A relations management methods ================================== acquire(...) ------------ Acquire the object ref as a child. Parameters are: body Reference of the Puppet::Body object that is to be acquired. name Name to refer to the acquired Puppet::Body. Defaults to the name of the acquired Puppet::Body object. For instance if object foo acquires object bar, bar becomes part of foo's content and foo is one of the container of bar. drop('name') ------------ Does the opposite of acquire(), i.e. drop the object named 'name'. getContent('name',...) ---------------------- In scalar context, it returns the Puppet::Body ref of the object 'name'. Returns undef if 'name' is not part of the content (i.e if it has not been 'acquired' before) In array context, it returns an array of all Puppet::Body references of all passed names. Returns () if the object has no content. getContainer('name',...) ------------------------ Same as getContent for the container. contentNames() -------------- Returns all names of the content, i.e. of all 'acquired' objects. containerNames() ---------------- Returns all names of the containers, i.e. of all objects that 'acquired' this object Log management. =============== printDebug(text) ---------------- Will log the passed text into the debug and events log object. printEvent(text) ---------------- Will log the passed text into the events log object. About Puppet framework ====================== Puppet framework is made of a set of utility classes. I currently use this framework for a major application Tk application. If you use directly the Puppet::Body class, you get the plain functionnality. And if you use the Puppet::Show class, you can get the same functionnality and a Tk Gui to manage it. AUTHOR ====== Dominique Dumont, Dominique_Dumont@grenoble.hp.com Copyright (c) 1998-1999 Dominique Dumont. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. SEE ALSO ======== *Note Perl: (perl.info)perl,, *Note Puppet/Log: Puppet/Log,, *Note Puppet/Storage: Puppet/Storage,, *Note Puppet/Show: Puppet/Show,  File: pm.info, Node: Puppet/Log, Next: Puppet/LogBody, Prev: Puppet/Body, Up: Module List Log facility with an optional Tk display **************************************** NAME ==== Puppet::Log - Log facility with an optional Tk display SYNOPSIS ======== use Puppet::Log ; my $log = new Puppet::Log('title' =>'log test') ; $log -> log("Some text") ; # $wmgr can be a toplevel Tk main window or a Tk::Multi::Manager $log ->display($wmgr, 1) ; DESCRIPTION =========== This class implements a log facility with an optional Tk display. I.e once the class is created, you can log messages in it, but the Tk display does no need to be created at the same time. You may invoke later only when you need it. When the Tk display is not invoked, the log can be either printed on STDOUT or warned on STDERR (or stay hidden). But in any case, the log message will be stored in the class so that all log messages can be retrieved later by the user or by the Tk display when invoked. Once the Tk display is invoked, it will be updated by new logs. Constructor =========== new([title => 'name'], ['how' => 'print' | 'warn' ]) ---------------------------------------------------- Creates the log object. The constructor parameters are : * title: Title of the Tk log display (optional) * name: Name of the log used when printing on STDOUT or STDERR (optional) * how: Specifies what to do when a log is sent to the object (either print on STDOUT, warn on STDERR). By default the logs will not be printed or warned. (optional) * help The argument may be a string or a sub reference. When the help menu is invoked, either the help string will be displayed in a Tk::Dialog box or the sub will be run. In this case it is the user's responsability to provide a readable help from the sub. (See `"help"', *Note Tk/Multi/Manager: Tk/Multi/Manager, for further details) Methods ======= log(text,...) ------------- Will log the passed text Optional parameters are: * how: will supersede the 'how' parameter passed to the constructor. If 'how' is set to undef, the log will not be printed or warned. clear() ------- Clear all stored logs. getAll() -------- Return an array made of all stored logs. display(toplevel_ref | multi_manager_reference, [hidden] ) ---------------------------------------------------------- Will create the log display. The log display is in fact a Tk::Multi::Text window which can managed by a Tk::Multi::Manager object. toplevel_ref The parent window object. multi_manager_reference The Tk::Multi::Manager reference hidden When hidden is 1, the log will not displayed on start-up. (default is to show the log window) If you don't provide a multi_manager reference, Puppet::Log will consider that you want the Log to appear in its own TopLevel window. In this case Puppet::Log will create a new Toplevel window and create a Tk::Multi::Manager in it. In this case, it will feature a File->close menu entry to destroy the Log window. Once the Log window is destroyed, the display method can then be called later to recreate it. In any case display() returns the manager reference. You may reuse this reference to add another Log display in the Toplevel window that Log just created. So that both log windows are displayed in the same Tk window. (See the `t/top_log.t' example to see what I mean) show() ------ Will raise the log window. Note that this function is ignored if its called before display(). About Puppet::* classes ======================= Puppet classes are a set of utility classes which can be used by any object. If you use directly the Puppet::*Body class, you get the plain functionnality. And if you use the Puppet::* class, you can get the same functionnality and a Tk Gui to manage it. The basic idea is when you construct a Puppet::* object, you have all the functionnality of the object without the GUI. Then, when the need arises, you may (or the class may decide to) open the GUI of the object. On the other hand, if the need does not arise, you may create a lot of objects without cluttering your display. AUTHOR ====== Dominique Dumont, Dominique_Dumont@grenoble.hp.com Copyright (c) 1998-1999 Dominique Dumont. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. SEE ALSO ======== perl(1), Puppet::LogBody(3), Tk(3), Tk::Multi::Text(3), Tk::Multi::Manager(3)