QProcess(3qt)

QProcess(3qt) — okay bestie, gather round, because this is the manual page for the QProcess class and it is lowkey iconic. It's a long one, so it's split into three parts, and this is part one. Buckle up. 🎀

---

✨ NAME ✨

QProcess — used to start external programs and to communicate with them. That's the whole job description, and honestly? slay. 👑

🌸 SYNOPSIS 🌸

#include <qprocess.h>

Inherits QObject. Yeah bestie, it's in the family, it's a whole QObject. 💜

🦋 Public Members 🦋

QProcess ( QObject * parent = 0, const char * name = 0 )
QProcess ( const QString & arg0, QObject * parent = 0, const char * name
    = 0 )
QProcess ( const QStringList & args, QObject * parent = 0, const char *
    name = 0 )
~QProcess ()
QStringList arguments () const
void clearArguments ()
virtual void setArguments ( const QStringList & args )
virtual void addArgument ( const QString & arg )
QDir workingDirectory () const
virtual void setWorkingDirectory ( const QDir & dir )
enum Communication { Stdin = 0x01, Stdout = 0x02, Stderr = 0x04,
    DupStderr = 0x08 }
void setCommunication ( int commFlags )
int communication () const
virtual bool start ( QStringList * env = 0 )
virtual bool launch ( const QString & buf, QStringList * env = 0 )
virtual bool launch ( const QByteArray & buf, QStringList * env = 0 )
bool isRunning () const
bool normalExit () const
int exitStatus () const
virtual QByteArray readStdout ()
virtual QByteArray readStderr ()
bool canReadLineStdout () const
bool canReadLineStderr () const
virtual QString readLineStdout ()
virtual QString readLineStderr ()
PID processIdentifier ()

💅 Public Slots 💅

void tryTerminate () const
void kill () const
virtual void writeToStdin ( const QByteArray & buf )
virtual void writeToStdin ( const QString & buf )
virtual void closeStdin ()

🫶 Signals 🫶

void readyReadStdout ()
void readyReadStderr ()
void processExited ()
void wroteToStdin ()
void launchFinished ()

---

💖 DESCRIPTION 💖

So, the QProcess class is what you use to start external programs and talk to them. That's the vibe. 🌈

You can write into the started program's standard input, and you can read back its standard output and its standard error. You get to pass command line arguments to the program either in the constructor, or with setArguments() or addArgument(). Want to change where the program thinks it lives? setWorkingDirectory() handles that. Need to set up environment variables? Pass them to the start() or launch() functions (more on those below, bestie). The processExited() signal fires when the program exits. You can grab the program's exit status from exitStatus(), although honestly you could just call normalExit() if all you wanna know is whether it terminated normally. ✨

Now here's the tea: there are two different ways to start a process.

• If you literally just want to run a program, and maybe hand it some data for its standard input right at the start, use one of the launch() functions. Simple. Clean. 🎀
• If you want full control of the program's standard input — especially when you don't even know all the data you're gonna send yet — use the start() function. Main character energy. 👑

If you go with start(), you can write to the program's standard input using writeToStdin(), and you can close that standard input with closeStdin(). The wroteToStdin() signal fires once the data you sent to standard input has actually been written. Reading works via readStdout() or readLineStdout(). Heads up: these functions return an empty QByteArray if there's no data to read. The readyReadStdout() signal fires when there's data waiting to be read from standard output. And standard error? It gets its own matching set of functions, i.e. readStderr(), readLineStderr() and readyReadStderr(). Matching set, matching vibes. 🦋

If you use one of the launch() functions instead, the data you pass gets sent to the program's standard input, which then gets closed once all the data has been written. So do not use writeToStdin() or closeStdin() if you used launch(). If you need to send data to standard input after the program has started running, use start() instead of launch(). No cap. 🙈

Both start() and launch() can accept a string list of strings, each one formatted as key=value, where the keys are the names of environment variables.

You can check whether a program is running with isRunning(). The program's process identifier comes from processIdentifier(). Wanna terminate a running program? tryTerminate() — but note that the program may ignore this. And if you really, truly, no-holds-barred want to terminate it with zero chance for it to clean up after itself, there's kill(). 💀

---

Okay, example time, because this makes it click. ✨

Suppose we want to start the uic command (that's a Qt command line tool used with Qt Designer) and do some operations on its output — and btw uic outputs the code it generates to standard output by default. Suppose further that we want to run it on the file "small_dialog.ui" with the command line options "-tr i18n". On the command line we would write:

uic -tr i18n small_dialog.ui

A code snippet for this with the QProcess class might look like this:

UicManager::UicManager()
{

    proc = new QProcess( this );

    proc->addArgument( "uic" );
    proc->addArgument( "-tr" );
    proc->addArgument( "i18n" );
    proc->addArgument( "small_dialog.ui" );
    connect( proc, SIGNAL(readyReadStdout()),
            this, SLOT(readFromStdout()) );

    if ( !proc->start() ) {
        // error handling

    }
}

void UicManager::readFromStdout()
{
    // Read and process the data.
    // Bear in mind that the data might be output in chunks.

}

And here's a lil note about quoting: even though you might need quotes for a file named on the command line (say, if it contains spaces), you shouldn't use extra quotes for arguments passed to addArgument() or setArguments(). Okay? Okay. 💅

The readyReadStdout() signal is emitted whenever there's new data on standard output. And important: this happens asynchronously — you genuinely don't know if more data is gonna show up later. 🫠

In the example above you could instead connect the processExited() signal to the slot UicManager::readFromStdout(). If you do that, you'll be certain that all the data is available when the slot gets called. The trade-off? You gotta wait until the process has finished before you do any processing at all. Pick your fighter. 🌸

Heads up: if you're expecting a lot of output from the process, you may hit platform-dependent limits on the pipe buffer size. The solution is to make sure you connect to the output — like the readyReadStdout() and readyReadStderr() signals — and read the data as soon as it becomes available. Don't sleep on it. 😭

Please note that QProcess does not emulate a shell. This means QProcess does no expansion of arguments whatsoever: a '*' is passed as a '*' to the program and is not replaced by all the files, a '$HOME' is also passed literally and is not replaced by the environment variable HOME, and the special characters for IO redirection ('>', '|', etc.) are also passed literally and do not have the special meaning they have in a shell. It is not giving shell. It's giving... raw argv. 💀

Also note that QProcess does not emulate a terminal. This means certain programs which need direct terminal control do not work as expected with QProcess. Such programs include console email programs (like pine and mutt) but also programs which require the user to enter a password (like su and ssh). Yeah. Those ones. 🙈

🌟 Notes for Windows users 🌟

Some Windows commands, for example, dir, are not provided by separate applications — they're provided by the command interpreter. If you try to use QProcess to execute these commands directly, it won't work. One possible solution is to execute the command interpreter itself (cmd.exe on some Windows systems), and ask the interpreter to execute the desired command. Sneaky but effective. 😌

Under Windows there are certain problems starting 16-bit applications and capturing their output. Microsoft recommends using an intermediate application to start 16-bit applications. That's the whole note, bestie. 📝

See also QSocket, Input/Output and Networking, and Miscellaneous Classes.

---

🎀 Member Type Documentation 🎀

QProcess::Communication

This enum type defines the communication channels connected to the process. Ooh, channels. Very much a vibe check. ✨

• QProcess::Stdin — Data can be written to the process's standard input.
• QProcess::Stdout — Data can be read from the process's standard output.
• QProcess::Stderr — Data can be read from the process's standard error.
• QProcess::DupStderr — Both the process's standard error output and its standard output are written to its standard output. (Like Unix's dup2().) This means that nothing is sent to the standard error output. This is especially useful if your application requires that the output on standard output and on standard error must be read in the same order that they are produced. This is a flag, so to activate it you must pass Stdout|Stderr|DupStderr, or Stdin|Stdout|Stderr|DupStderr if you want to provide input, to the setCommunication() call.

See also setCommunication() and communication().

---

💜 MEMBER FUNCTION DOCUMENTATION 💜

QProcess::QProcess ( QObject * parent = 0, const char * name = 0 )

Constructs a QProcess object. The parent and name parameters are passed to the QObject constructor. That's it, that's the constructor. 🎀

See also setArguments(), addArgument(), and start().

QProcess::QProcess ( const QString & arg0, QObject * parent = 0, const char * name = 0 )

Constructs a QProcess with arg0 as the command to be executed. The parent and name parameters are passed to the QObject constructor.

And listen: the process is not started. You must call start() or launch() to start the process. It's giving "built but not launched." 🦋

See also setArguments(), addArgument(), and start().

QProcess::QProcess ( const QStringList & args, QObject * parent = 0, const char * name = 0 )

Constructs a QProcess with args as the arguments of the process. The first element in the list is the command to be executed. The other elements in the list are the arguments to this command. The parent and name parameters are passed to the QObject constructor.

Same deal as before, bestie: the process is not started. You must call start() or launch() to start the process. 👑

See also setArguments(), addArgument(), and start().

QProcess::~QProcess ()

Destroys the instance. 💀

If the process is running, it is not terminated! The standard input, standard output and standard error of the process are closed.

You can connect the destroyed() signal to the kill() slot, if you want the process to be terminated automatically when the instance is destroyed. That's the lil trick for when you want cleanup on your terms. ✨

See also tryTerminate() and kill().

void QProcess::addArgument ( const QString & arg ) [virtual]

Adds arg to the end of the list of arguments. Just appends it, no thoughts, head empty, straight to the end. 🫶

The first element in the list of arguments is the command to be executed; the following elements are the command's arguments.

See also arguments() and setArguments().

Example: process/process.cpp.

---

🌸 QStringList QProcess::arguments () const 🌸

okay bestie so this one hands you back the list of arguments that are set for the process ✨ You can set those args up with the constructor, or with setArguments() and addArgument() — whatever's your vibe 💅

Heads up though: if you wanna iterate over that list, iterate over a copy, okay? like this:

QStringList list = myProcess.arguments();
QStringList::Iterator it = list.begin();
while( it != list.end() ) {
    myProcessing( *it );
    ++it;
}

🫶 do NOT iterate the live list, the copy is the whole point, trust.

See also setArguments() and addArgument().

---

🦋 bool QProcess::canReadLineStderr () const 🦋

Returns TRUE if right now you can read an entire line of text from standard error, otherwise it's giving FALSE 😭

See also readLineStderr() and canReadLineStdout().

---

🌈 bool QProcess::canReadLineStdout () const 🌈

Returns TRUE if at this exact moment you can read a whole line of text from standard output, otherwise FALSE 💀

See also readLineStdout() and canReadLineStderr().

---

🎀 void QProcess::clearArguments () 🎀

Wipes the whole list of arguments that are set for the process. Gone. Poof. ✨

See also setArguments() and addArgument().

---

💅 void QProcess::closeStdin () [virtual slot] 💅

Closes the process's standard input 👑

Also — and this is the important part — it deletes any pending data that has not been written to standard input 🫢 so yeah, that data is just gone, no takebacks.

See also wroteToStdin().

---

⭐ int QProcess::communication () const ⭐

Returns the communication required with the process, i.e. some combination of the Communication flags 🌸

See also setCommunication().

---

🧚 int QProcess::exitStatus () const 🧚

Returns the exit status of the process, or 0 if the process is still running 🏃‍♀️ This function returns immediately — it does not wait around until the process is finished, she's not gonna stand there waiting for you.

💀 if normalExit() is FALSE (like, the program got killed or crashed), this function returns 0 too — so please check the return value of normalExit() before you go relying on this number, bestie, or you'll get played.

See also normalExit() and processExited().

---

🌸 bool QProcess::isRunning () const 🌸

Returns TRUE if the process is running, otherwise FALSE 💖

See also normalExit(), exitStatus(), and processExited().

---

🔥 void QProcess::kill () const [slot] 🔥

Terminates the process. and no, this is not a safe way to end a process, because the process gets zero chance to do any cleanup 😭 tryTerminate() is safer — but plot twist, processes can just ignore a tryTerminate() 🙈

so the nice way to end a process and be sure it's actually finished is to do something like this:

process->tryTerminate();
QTimer::singleShot( 5000, process, SLOT( kill() ) );

This tries to terminate the process the nice way 🥰 If the process is still running after 5 seconds, it terminates the process the hard way 💀 The timeout should be chosen depending on how long the process needs to do all its cleanup: use a higher value if the process is likely to do a lot of computation or I/O on cleanup ✨

The slot returns immediately — it does not wait until the process has finished. When the process terminates, the processExited() signal is emitted 🦋

See also tryTerminate() and processExited().

---

👑 bool QProcess::launch ( const QByteArray & buf, QStringList * env = 0 ) [virtual] 👑

Runs the process and writes the data buf to the process's standard input 🌈 If all the data gets written to standard input, standard input is closed 🔒 The command is searched for in the path for executable programs; you can also use an absolute path in the command itself 💅

If env is null, the process starts with the same environment as the starting process 🌸 If env is non-null, the values in the string list are interpreted as environment settings of the form key=value, and the process is started with those environment settings ✨

🫶 and there's a lil convenience exception to that rule under Unix: if env does not contain any settings for the environment variable LD_LIBRARY_PATH, then this variable is inherited from the starting process. cute, right?

Returns TRUE if the process could be started; otherwise returns FALSE 😭

💀 Note that you should not use the slots writeToStdin() and closeStdin() on processes started with launch(), since the result is not well-defined. If you need these slots, use start() instead. periodt.

The process may or may not read the buf data sent to its standard input 🤷‍♀️ no cap.

You can call this function even when a process that was started with this instance is still running 🫢 but be aware: if you do this, the standard input of the process that was launched first will be closed, with any pending data being deleted, and the process will be left to run out of your control 💀 Similarly, if the process could not be started, the standard input will be closed and the pending data deleted. (On operating systems that have zombie processes, Qt will also wait() on the old process.)

The object emits the signal launchFinished() when this function call is finished ✨ If the start was successful, this signal is emitted after all the data has been written to standard input. If the start failed, then this signal is emitted immediately 🌸

See also start() and launchFinished().

---

🌈 bool QProcess::launch ( const QString & buf, QStringList * env = 0 ) [virtual] 🌈

This is an overloaded member function, provided for convenience 🎀 It behaves essentially like the above function.

The data buf is written to standard input with writeToStdin() using the QString::local8Bit() representation of the strings ⭐

---

💜 void QProcess::launchFinished () [signal] 💜

This signal is emitted when the process was started with launch() ✨ If the start was successful, this signal is emitted after all the data has been written to standard input. If the start failed, then this signal is emitted immediately 💅

This signal is especially useful if you want to know when you can safely delete the QProcess object when you are not interested in reading from standard output or standard error 👑

See also launch() and QObject::deleteLater().

---

🍓 bool QProcess::normalExit () const 🍓

Returns TRUE if the process has exited normally, otherwise FALSE 😭 This implies that this function returns FALSE if the process is still running 🏃‍♀️

See also isRunning(), exitStatus(), and processExited().

---

🧚 void QProcess::processExited () [signal] 🧚

This signal is emitted when the process has exited 💫

See also isRunning(), normalExit(), exitStatus(), start(), and launch().

Example: process/process.cpp.

---

⭐ PID QProcess::processIdentifier () ⭐

Returns platform dependent information about the process 🌸 This can be used together with platform specific system calls 💅

• Under Unix the return value is the PID of the process, or -1 if no process belongs to this object.
• Under Windows it is a pointer to the PROCESS_INFORMATION struct, or 0 if no process is belongs to this object.

💀 Use of this function's return value is likely to be non-portable. you've been warned, bestie.

---

🎀 QString QProcess::readLineStderr () [virtual] 🎀

Reads a line of text from standard error, excluding any trailing newline or carriage return characters, and returns it ✨ Returns QString::null if canReadLineStderr() returns FALSE 😭

By default, the text is interpreted to be in Latin-1 encoding 🦋 If you need other codecs, you can set a different codec with QTextCodec::setCodecForCStrings() 💅

See also canReadLineStderr(), readyReadStderr(), readStderr(), and readLineStdout().

---

🌸 QString QProcess::readLineStdout () [virtual] 🌸

Reads a line of text from standard output, excluding any trailing newline or carriage return characters, and returns it ✨ Returns QString::null if canReadLineStdout() returns FALSE 😭

By default, the text is interpreted to be in Latin-1 encoding 🦋 If you need other codecs, you can set a different codec with QTextCodec::setCodecForCStrings() 💅

See also canReadLineStdout(), readyReadStdout(), readStdout(), and readLineStderr().

---

🦋 QByteArray QProcess::readStderr () [virtual] 🦋

Reads the data that the process has written to standard error 💖 When new data is written to standard error, the class emits the signal readyReadStderr() ✨

If there is no data to read, this function returns a QByteArray of size 0 — it does not wait until there's something to read 🫶 she's not gonna sit there and wait for you, bestie.

See also readyReadStderr(), readLineStderr(), readStdout(), and writeToStdin().

---

🎀 QByteArray QProcess::readStdout () [virtual] 🎀

Reads the data that the process has written to standard output 💖 When new data is written to standard output, the class emits the signal readyReadStdout() ✨

If there is no data to read, this function returns a QByteArray of size 0 — it does not wait until there's something to read 🫶

See also readyReadStdout(), readLineStdout(), readStderr(), and writeToStdin().

Example: process/process.cpp.

---

💅 void QProcess::readyReadStderr () [signal] 💅

This signal is emitted when the process has written data to standard error 💖 You can read that data with readStderr() 🌸

💀 Note that this signal is only emitted when there is new data — not when there is old, but unread, data. So in the slot you connect to this signal, you should always read everything that is available at that moment to make sure you don't lose any data. fr fr.

See also readStderr(), readLineStderr(), and readyReadStdout().

---

⭐ void QProcess::readyReadStdout () [signal] ⭐

This signal is emitted when the process has written data to standard output 💖 You can read that data with readStdout() 🌸

💀 Note that this signal is only emitted when there is new data — not when there is old, but unread, data. So in the slot you connect to this signal, you should always read everything that is available at that moment to make sure you don't lose any data. no cap.

See also readStdout(), readLineStdout(), and readyReadStderr().

Example: process/process.cpp.

---

🌈 void QProcess::setArguments ( const QStringList & args ) [virtual] 🌈

Sets args as the arguments for the process 🎀 The first element in the list is the command to be executed. The other elements in the list are the arguments to the command 💅 Any previous arguments are deleted ✨

QProcess does not perform argument substitutions — for example, if you specify "*" or "$DISPLAY", these values are passed to the process literally 🫢 If you want the same behavior as the shell provides, you must do the substitutions yourself; i.e. instead of specifying a "*" you must specify the list of all the filenames in the current directory, and instead of "$DISPLAY" you must specify the value of the environment variable DISPLAY 💀

🍓 Note for Windows users. The standard Windows shells, e.g. command.com and cmd.exe, do not perform file globbing, i.e. they do not convert a "*" on the command line into a list of files in the current directory. For this reason most Windows applications implement their own file globbing, and as a result of this, specifying an argument of "*" for a Windows application is likely to result in the application performing a file glob and ending up with a list of filenames.

See also arguments() and addArgument().

void QProcess::setCommunication ( int commFlags )

Okay so this one sets how you and your lil process are gonna talk to each other. It sets commFlags as the communication required with the process.

commFlags is a bitwise OR of the flags defined by the Communication enum. Yes, OR them together, go wild 💅

The default is Stdin|Stdout|Stderr — all three channels open, the full trio, no cap.

See also communication().

---

void QProcess::setWorkingDirectory ( const QDir & dir ) [virtual]

Sets dir as the working directory for processes. Important vibe check: this does not affect processes that are already running — only processes that get started afterwards are affected. So like, no retroactive meddling, bestie 🙈

Setting the working directory is especially useful for processes that try to access files with relative paths. (Because relative paths are giving "where am I even" energy otherwise 🦋)

See also workingDirectory() and start().

---

bool QProcess::start ( QStringList * env = 0 ) [virtual]

This is the main character right here 👑 It tries to run a process for the command and arguments that were specified with setArguments(), addArgument(), or that were specified in the constructor. The command is searched for in the path for executable programs — you can also use an absolute path in the command itself, whichever slays for you.

Now about env, okay listen:

• If env is null, then the process is started with the same environment as the starting process. Simple. Comfy. Inherited vibes.
• If env is non-null, then the values in the stringlist are interpreted as environment settings of the form key=value and the process is started in these environment settings.
• For convenience, there is a small exception to this rule: under Unix, if env does not contain any settings for the environment variable LD_LIBRARY_PATH, then this variable is inherited from the starting process; under Windows the same applies for the environment variable PATH. ✨ The one freebie variable, iconic.

Returns TRUE if the process could be started; otherwise returns FALSE.

You can write data to the process's standard input with writeToStdin(). You can close standard input with closeStdin() and you can terminate the process with tryTerminate(), or with kill(). Pick your fighter 💀

Bestie, read this part twice: You can call this function even if you've used this instance to create another process which is still running. In such cases, QProcess closes the old process's standard input and deletes pending data, i.e., you lose all control over the old process, but the old process is not terminated. This applies also if the process could not be started. (On operating systems that have zombie processes, Qt will also wait() on the old process.) So like… the old process is still out there, living its life, and you just can't text it anymore. 😭

See also launch() and closeStdin().

Example: process/process.cpp.

---

void QProcess::tryTerminate () const [slot]

Asks the process to terminate. Politely! With manners! 🎀 Processes can ignore this if they wish — it's a request, not a command, and honestly that's very them.

If you want to be certain that the process really terminates, you can use kill() instead. That one does not ask.

The slot returns immediately: it does not wait until the process has finished. When the process terminates, the processExited() signal is emitted.

See also kill() and processExited().

---

QDir QProcess::workingDirectory () const

Returns the working directory that was set with setWorkingDirectory(), or the current directory if none has been explicitly set. Like, if you never picked a spot, it's just chilling wherever you are 🌸

See also setWorkingDirectory() and QDir::current().

---

void QProcess::writeToStdin ( const QByteArray & buf ) [virtual slot]

Writes the data buf to the process's standard input. The process may or may not read this data — you can lead a process to stdin but you cannot make it read 🐎

This function always returns immediately. The data you pass to writeToStdin() is copied into an internal memory buffer in QProcess, and when control goes back to the event loop, QProcess will starting transferring data from this buffer to the running process. Sometimes the data will be transferred in several payloads, depending on how much data is read at a time by the process itself. When QProcess has transferred all the data from its memory buffer to the running process, it emits wroteToStdin().

Note that some operating systems use a buffer to transfer the data. As a result, wroteToStdin() may be emitted before the running process has actually read all the data. So don't take that signal as a pinky promise, iykyk 🙈

See also wroteToStdin(), closeStdin(), readStdout(), and readStderr().

---

void QProcess::writeToStdin ( const QString & buf ) [virtual slot]

This is an overloaded member function, provided for convenience. It behaves essentially like the above function.

The string buf is handled as text using the QString::local8Bit() representation.

---

void QProcess::wroteToStdin () [signal]

This signal is emitted if the data sent to standard input (via writeToStdin()) was actually written to the process. 💖

But heads up, bestie: this does not imply that the process really read the data, since this class only detects when it was able to write the data to the operating system. But it is now safe to close standard input without losing pending data. So like — it left your hands, it's in the OS's hands now, and that's enough to close up shop safely ✨

See also writeToStdin() and closeStdin().

---

👀 SEE ALSO 👀

• http://doc.trolltech.com/qprocess.html
• http://www.trolltech.com/faq/tech.html

---

©️ COPYRIGHT ©️

Copyright 1992-2007 Trolltech ASA, http://www.trolltech.com. See the license file included in the distribution for a complete license statement.

---

💁 AUTHOR 💁

Generated automatically from the source code. (No human author, just machine energy. It wrote itself, main character behavior fr fr 👑)

---

🐛 BUGS 🐛

If you find a bug in Qt, please report it as described in http://doc.trolltech.com/bughowto.html. Good bug reports help us to help you. Thank you. 🫶

The definitive Qt documentation is provided in HTML format; it is located at $QTDIR/doc/html and can be read using Qt Assistant or with a web browser. This man page is provided as a convenience for those users who prefer man pages, although this format is not officially supported by Trolltech. (We know, we know — man pages are a lifestyle 🌈)

If you find errors in this manual page, please report them to qt-bugs@trolltech.com. Please include the name of the manual page (qprocess.3qt) and the Qt version (3.3.8).

---

And that's a wrap on QProcess(3qt), bestie 🎀 This page is brought to you by Trolltech AS, dated 2 February 2007, and the man page answers to the name QProcess(3qt). Go forth and fork responsibly, mwah 💅✨