Diffstat (limited to 'libopie2/opiecore/oprocess.h') (more/less context) (ignore whitespace changes)
| -rw-r--r-- | libopie2/opiecore/oprocess.h | 8 |
1 files changed, 5 insertions, 3 deletions
diff --git a/libopie2/opiecore/oprocess.h b/libopie2/opiecore/oprocess.h index be1436c..ac6be98 100644 --- a/libopie2/opiecore/oprocess.h +++ b/libopie2/opiecore/oprocess.h @@ -33,49 +33,49 @@ _;:, .> :=|. This program is free software; you can /* QT */ #include <qcstring.h> #include <qobject.h> #include <qvaluelist.h> /* STD */ #include <sys/types.h> // for pid_t #include <sys/wait.h> #include <signal.h> #include <unistd.h> class QSocketNotifier; namespace Opie { namespace Core { namespace Internal { class OProcessController; class OProcessPrivate; } /** * Child process invocation, monitoring and control. * - * @sect General usage and features + * @par General usage and features * *This class allows a KDE and OPIE application to start child processes without having *to worry about UN*X signal handling issues and zombie process reaping. * *@see KProcIO * *Basically, this class distinguishes three different ways of running *child processes: * *@li OProcess::DontCare -- The child process is invoked and both the child *process and the parent process continue concurrently. * *Starting a DontCare child process means that the application is *not interested in any notification to determine whether the *child process has already exited or not. * *@li OProcess::NotifyOnExit -- The child process is invoked and both the *child and the parent process run concurrently. * *When the child process exits, the OProcess instance *corresponding to it emits the Qt signal @ref processExited(). * *Since this signal is @em not emitted from within a UN*X *signal handler, arbitrary function calls can be made. @@ -89,77 +89,77 @@ class OProcessPrivate; *is suspended until the child process exits. (@em Really not recommended *for programs with a GUI.) * *OProcess also provides several functions for determining the exit status *and the pid of the child process it represents. * *Furthermore it is possible to supply command-line arguments to the process *in a clean fashion (no null -- terminated stringlists and such...) * *A small usage example: *<pre> *OProcess *proc = new OProcess; * **proc << "my_executable"; **proc << "These" << "are" << "the" << "command" << "line" << "args"; *QApplication::connect(proc, SIGNAL(processExited(Opie::Core::OProcess *)), * pointer_to_my_object, SLOT(my_objects_slot(Opie::Core::OProcess *))); *proc->start(); *</pre> * *This will start "my_executable" with the commandline arguments "These"... * *When the child process exits, the respective Qt signal will be emitted. * - *@sect Communication with the child process + *@par Communication with the child process * *OProcess supports communication with the child process through *stdin/stdout/stderr. * *The following functions are provided for getting data from the child *process or sending data to the child's stdin (For more information, *have a look at the documentation of each function): * *@li bool @ref writeStdin(char *buffer, int buflen); *@li -- Transmit data to the child process's stdin. * *@li bool @ref closeStdin(); *@li -- Closes the child process's stdin (which causes it to see an feof(stdin)). *Returns false if you try to close stdin for a process that has been started *without a communication channel to stdin. * *@li bool @ref closeStdout(); *@li -- Closes the child process's stdout. *Returns false if you try to close stdout for a process that has been started *without a communication channel to stdout. * *@li bool @ref closeStderr(); *@li -- Closes the child process's stderr. *Returns false if you try to close stderr for a process that has been started *without a communication channel to stderr. * * - *@sect QT signals: + *@par QT signals: * *@li void @ref receivedStdout(OProcess *proc, char *buffer, int buflen); *@li void @ref receivedStderr(OProcess *proc, char *buffer, int buflen); *@li -- Indicates that new data has arrived from either the *child process's stdout or stderr. * *@li void @ref wroteStdin(OProcess *proc); *@li -- Indicates that all data that has been sent to the child process *by a prior call to @ref writeStdin() has actually been transmitted to the *client . * *@author Christian Czezakte e9025461@student.tuwien.ac.at *@author Holger Freyther (Opie Port) * **/ class OProcess : public QObject { Q_OBJECT public: /** * Modes in which the communication channel can be opened. * @@ -470,81 +470,83 @@ public: /** * @return the PID of @a process, or -1 if the process is not running */ static int processPID( const QString& process ); signals: /** * Emitted after the process has terminated when * the process was run in the @p NotifyOnExit (==default option to * @ref start()) or the @ref Block mode. **/ void processExited( Opie::Core::OProcess *proc ); /** * Emitted, when output from the child process has * been received on stdout. * * To actually get * these signals, the respective communication link (stdout/stderr) * has to be turned on in @ref start(). * + * @param proc The process * @param buffer The data received. * @param buflen The number of bytes that are available. * * You should copy the information contained in @p buffer to your private * data structures before returning from this slot. **/ void receivedStdout( Opie::Core::OProcess *proc, char *buffer, int buflen ); /** * Emitted when output from the child process has * been received on stdout. * * To actually get these signals, the respective communications link * (stdout/stderr) has to be turned on in @ref start() and the * @p NoRead flag should have been passed. * * You will need to explicitly call resume() after your call to start() * to begin processing data from the child process's stdout. This is * to ensure that this signal is not emitted when no one is connected * to it, otherwise this signal will not be emitted. * * The data still has to be read from file descriptor @p fd. **/ void receivedStdout( int fd, int &len ); /** * Emitted, when output from the child process has * been received on stderr. * To actually get * these signals, the respective communication link (stdout/stderr) * has to be turned on in @ref start(). * + * @param proc The process * @param buffer The data received. * @param buflen The number of bytes that are available. * * You should copy the information contained in @p buffer to your private * data structures before returning from this slot. */ void receivedStderr( Opie::Core::OProcess *proc, char *buffer, int buflen ); /** * Emitted after all the data that has been * specified by a prior call to @ref writeStdin() has actually been * written to the child process. **/ void wroteStdin( Opie::Core::OProcess *proc ); protected slots: /** * This slot gets activated when data from the child's stdout arrives. * It usually calls "childOutput" */ void slotChildOutput( int fdno ); /** |