The missing startDetached overloaded function

jsulm

@Aman-Jiang No, arguments list can be empty, QProcess doesn't care whether the executable you want to start expects any parameters or not. You should check why it didn't work.

Aman Jiang

@jsulm Are you sure ?

On Windows 10, Visual Studio 2013, Qt5.5.1, this code will open notepad:

QProcess::startDetached("notepad.exe", QStringList(), R"(C:\Users\Aman\Desktop)");

And this, nothing happened:

QProcess::startDetached("notepad.exe a.txt", QStringList(), R"(C:\Users\Aman\Desktop)");

There is exactly a txt file called 'a.txt' exists in 'C:\Users\Aman\Desktop' directory but this is not the point, the point is that notepad is not started, you know notepad can starts with error arguments.

SGaist

Because your calling it wrong. a.text is an argument so put it in the argument list.

jsulm

@Aman-Jiang Yes, I'm sure. What I mean is: if you don't have any parameters then the list can be empty. Your second example is wrong: if you have any parameters then put them in the list:

QProcess::startDetached("notepad.exe", QStringList() << "a.txt", R"(C:\Users\Aman\Desktop)");

Aman Jiang

@SGaist I know that.

This code will works fine:

QProcess::startDetached("notepad.exe a.txt");

But there is no 'workdir' argument. This is what I am talking about. I need this version but it's missing:

bool startDetached(const QString & program, const QString & workingDirectory, qint64 * pid = 0);

Aman Jiang

@jsulm I know it's wrong, and I know how to call this function. But I don't need this version, I need this one:

bool startDetached(const QString & program, const QString & workingDirectory, qint64 * pid = 0);

The program and arguments in one string, and a working dir argument.

I am talking about overloaded functions.

jsulm

@Aman-Jiang
Why not use this one with empty parameter list?

bool startDetached(const QString & program, const QStringList & arguments, const QString & workingDirectory, qint64 * pid = 0);

like

startDetached("notepad.exe", QStringList(), "c:\\temp", 123);

I don't see any need for one more method.

"The program and arguments in one string" - don't do that! Arguments should be passed as arguments list.

Aman Jiang

I am working on some kind of launcher. There is many command lines from the user, these command lines is used to launch the specified programs, there're stored in db. I don't want to split these command lines into QStringList on launching, because the target programs could be very different, it's risk, I want to use them directly.

Aman Jiang

@jsulm This version accepts program and arguments in one string:

bool startDetached(const QString & program);

You couldn't always pass arguments as arguments list, because the split rule can be different, a program may like semicolon more than space.

On windows, GetCommandLine returns just one string.

mrjj

@Aman-Jiang said:

startDetached

While it can work with params with the exe string
, it will break very easy

QProcess::startDetached("notepad.exe E:/space in path/test.txt");

wont work.

There is nothing stopping you from doing
startDetached("notepad.exe TEST.txt", QStringList(), "c:\temp");
to specify work dir.
and "misuse" the exe string with params.

jsulm

@Aman-Jiang Are you aware that startDetach(const QString& program) splits the parameter you pass?
Read the documentation:

After the command string has been split and unquoted, this function behaves like the overload which takes the arguments as a string list.

http://doc.qt.io/qt-5/qprocess.html#startDetached-1

kshegunov

@Aman-Jiang

You couldn't always pass arguments as arguments list, because the split rule can be different, a program may like semicolon more than space.

You can and you should, and the split rule can't be different, so listen to the fellows that commented above and pass the arguments as a string list. You may need to do some parsing yourself to handle quoted/escaped strings, for which you can use something like boost's Spirit module. But as @mrjj noted, passing the arguments along with the executable in one string is just abuse of the API and may or may not work depending on OS/Qt version and other factors beyond your control.

Kind regards.

Aman Jiang

@mrjj I don't get you. There is spaces in the string, without quotation marks, it's invalid command line, what do you want to prove ?

SGaist

That it's the kind of use case you are likely going to have to fight against since you want to pass everything in a single string.

Aman Jiang

@jsulm No... I haven't notice this line in the document...

Aman Jiang

@kshegunov Okay, I get you, I know the reason now. But, If Qt's goal is make everything easier, why not add one more overloaded startDetached ? If this one:

bool startDetached(const QString & program);

Could do the right thing cross Qt versions and OS versions, add another one:

bool startDetached(const QString & program, const QString& workDir);

Is more complete. At least I think so.

Aman Jiang

@SGaist I used to write lots of string parsing codes, it's not very hard, but I like a more easier way to do the same work if I could.

raven-worx

@Aman-Jiang
there is already QProcess::setWorkingDirectory() available

Aman Jiang

@raven-worx A QProcess object will wait for the process, a "detach" member function is missing.

kshegunov

@Aman-Jiang

But, If Qt's goal is make everything easier, why not add one more overloaded startDetached ?

Well, you have to ask Qt devs that, but if I were to hazard a guess - probably simplicity of implementation and compliance with QProcess::start, but I haven't checked the source so I'm just speculating. While the split rules are the same across OSes some (notably Windows) have somewhat stringent requirements for characters in paths (or rather the command line interpreter cmd does), Linux is much more relaxed on this matter.
My advice is to just wrap a very simple LL(1) parser (it's so simple you can even write it by hand in an hour) and use it to split your command line.

"detach" member function is missing.

I'm not sure you can detach from a process freely on all platforms, so I'm assuming it's not missing, it's just impossible to provide in a cross-platform consistent manner.

Kind regards.