QProcess and the command line

First to say - on linux, I dont have any problems. I use QProcess to start everything and it works.

First trap - Windows. I can start anything, but for tools using the shell. QProcess::start does neither start cmd.exe (with complete path) nor any tool from cygwin (mc.exe, vi.exe, bash.bat). The only way to get a command line is to use QProgress::startDetached. But then I don't have any chance to set the environment of the shell...

Second Trap - Mac. When my app is already started within the bash, and it starts another bash command, the new shell is opend within the window of the starting shell :confused: When the app is started from the dock, starting a command line does nothing at all. Neither QProcess::start nor QProcess::startDetached opens any window at all.

Any suggesgion is welcome :)

Could you try restating what your questions are? I can see descriptions of the problems but I don't know what you are really asking about.

Ok, after mentioning the symptoms, here's the short question: how can I start on the Mac a new bash shell with

QProcess proc;
QStringList args;
proc->start("bash", args);

?

(Same question for vi)

And how can I do the same on Win32?

works fine under Windows

Code:

---

QProcess::startDetached("cmd.exe");

---

did not test under other platforms, but I think it should work.

Yes, it is on win32 the only way to start cmd. But how can I change the environment then?

(On Mac, is does not work at all)

Please, can someone tell me how I can start a new bash shell with QProcess?

really just a shell, or terminal like rxvt or konsole running a bash?

Set the environment before. The Environment of the process is inherited to its children (here: the command you want to start with QProcess)

We're using this code to archive it (Works under Windows, Linux and OSX)

Code:

---

// header
enum EnvironmentSetOperationResult {
  CouldSetEvironmentVariable = 0,
  FailedToSetEnvironmentVariable = -1
};
 
// cpp
 
#include <cstdlib>
 
#ifdef Q_WS_WIN
// this is needed for the environment functions. Else the function will use unicode
// and will not work with char*
#undef UNICODE
#include <windows.h>
#endif
 
// [...]
 
void Environment::set(const QString& key, const QString& value) {
    // attention!
    //linux   0 == success, -1 == error
    //windows 0 == error,   !0 == success
 
	int num_error = FailedToSetEnvironmentVariable;
 
	QByteArray key_ba = key.toLatin1();
	QByteArray value_ba = value.toLatin1();
 
#ifdef Q_WS_WIN
	if(value.isNull()) {
	  num_error = SetEnvironmentVariableA((LPCSTR) key.toAscii().constData(), NULL);
	} else {
	  num_error = SetEnvironmentVariableA((LPCSTR) key.toAscii().constData(), (LPCSTR) value.toAscii().constData());
	}
	num_error = (num_error == 0 ? FailedToSetEnvironmentVariable : CouldSetEvironmentVariable);
#else
	const int overwrite_variable = 1;
	num_error = setenv(key_ba.constData(), value_ba.constData(), overwrite_variable);
#endif
	if (num_error == FailedToSetEnvironmentVariable)		{
		qDebug() << "Environment::set(): Could not set'" << key << "' to '" << value << "'";
	}
}

---

Quote:

---

Originally Posted by caduel

really just a shell, or terminal like rxvt or konsole running a bash?

---

I want to start the bash itself and a few instances of vi.

Quote:

---

Originally Posted by nightghost

Set the environment before.

---

And why not set it with QProcess? :confused:

In order to start vi you need a window (assuming you don't intend to simulate a user by writing to stdin).

So you will need to open some terminal application and run vi from there.

And to start a graphical program like assistant? Is it possible to start it by commandline where the ".app/Contents/MacOS" part is some kind of autogenerated? I "only" have a new MacBook Pro, so I have no idea of the behaviour of the non-intel macs.

----

This means starting a shell, I have the same difficulties as on windows, but there startDetached is working. Well.

I found a swiss site with a small helper script.

Maybe I check the existence of ~/.term, generate it and make it executable... or I check it into the repository, because it belongs to the maker suite anyway...

thanks for that hint.

Great. With the script I can start any bash command in a shell. Only when I close it, the window is left with "Prozess beendet". But I can live with it. Assistant and Designer are started with a symbolic QTDIR somewhere under "sources"... so everything runs now :)
[Solved]

Mmmh... it still does not really work. When I start makemk - the tool which wants to start a shell - from the command line, it works. I open a shell, I start vi, great.
When I start makemk from the dock, it does not work. I neither get a shell nor a vi. Do I have to put any voodoo stuff around the call?

Plus: when I say "exit" to close the shell again, the window stays open, and its title becomes "process stopped". Maybe thats just a setting from Terminal, but until now I did not find it :confused:

If you want a terminal then start a terminal application. If you want a shell, then call bash (or whatever other shell you want directly) - you won't see it but it will be there. If something doesn't work then most likely it is a problem with relative paths.

hmm when I was making some application witch was calling latex to process the tex source files then I had QProcess object, and I just set some working dir (it was dir where my text files were) and used (pdflatex is a QProcess object, and pdflatex is a command line tool):

Code:

---

pdflatex.setWorkingDirectory(currentProjectPath);
pdflatex.start("pdflatex", QStringList() << project.rootFile());

---

It's working on Windows Vista, XP and linux (kubuntu with KDE 3.5 & 4.x).
I did not have to call any bash, cmd or something and it is just working.

Quote:

---

Originally Posted by faldżip

It's working on Windows Vista, XP and linux

---

Yes, for me too. This is a Mac-only problem :)

Quote:

---

Originally Posted by wysota

If something doesn't work then most likely it is a problem with relative paths.

---

Well, you could have been right. I called the script below simply with "term", and the path $QTHSRC/util is set in .profile. So if .profile would not have been read by the dock, it could not have find the term script. Now I call $QTHSRC/util/term, just to be sure. But the behaviour did not change, I can call assistant and designer, but not bash nor vi, except my program was started at the command line.

Here is the script I call (from the mentioned page, thanks to Marc):

Code:

---

!/bin/sh                                                                                                               
if [ "x-x" = x"$1" ]; then
    EXIT="; exit"; shift;
fi
 
if [[ -d "$1" ]]; then
    WD=`cd "$1"; pwd`; shift;
else
    WD="'`pwd`'";
fi
 
COMMAND="cd $WD; $@"
echo "$COMMAND $EXIT"
 
osascript 2>/dev/null <<EOF
    tell application "Terminal"
        activate
        do script with command "$COMMAND $EXIT"
    end tell
EOF

---

it is called with "$QTHSRC/util/term -x <path> bash" and "$QTHSRC/util/term -x <path> vi". So - what's the difference? :crying:

Quote:

---

Originally Posted by wysota

You won't see it but it will be there.

---

I pushed the "Open Shell" button and called ps. It neither appeared a Terminal nor a bash command. And that is really strange...
Edith says: doublecliking the term-scipt in the finder opens a terminal.

Btw (little bit OT), does anybody know, where I can find the command line arguments of "Terminal"? I'd like to change the initial size and background color

Quote:

---

Originally Posted by auba

Well, you could have been right. I called the script below simply with "term", and the path $QTHSRC/util is set in .profile. So if .profile would not have been read by the dock, it could not have find the term script. Now I call $QTHSRC/util/term, just to be sure. But the behaviour did not change, I can call assistant and designer, but not bash nor vi, except my program was started at the command line.

---

You're still using a relative path, especially if $QTHSRC is undefined.

Quote:

---

I pushed the "Open Shell" button and called ps. It neither appeared a Terminal nor a bash command. And that is really strange...

---

I'm not sure what you mean here... ps is a command placed in /bin/.

Quote:

---

Originally Posted by wysota

You're still using a relative path, especially if $QTHSRC is undefined.

---

Thanks, that was the missing point: when $PATH is not set to $QTHSRC/util, why $QTHSRC itself should have been set :eek:
cd /bin && sudo ln -s /Users/auba/sources/qhelpers/util/term and it works :)

(... with ps I wanted to see if there was a bash opened in the background)