QProcess and the command line

[auba]

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 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

[wysota]

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.

[auba]

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?

[spirit]

works fine under Windows

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

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

To copy to clipboard, switch view to plain text mode 

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

[auba]

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)

[auba]

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

[caduel]

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

[nightghost]

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)

// 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 << "'";
	}
}

// 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 << "'";
	}
}

To copy to clipboard, switch view to plain text mode 

[auba]

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.

Set the environment before.

And why not set it with QProcess?

[caduel]

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.

[auba]

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.

[auba]

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]

[auba]

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

[wysota]

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.

[faldzip]

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):

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

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

To copy to clipboard, switch view to plain text mode 

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.

[auba]

It's working on Windows Vista, XP and linux

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

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):

!/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

!/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

To copy to clipboard, switch view to plain text mode 

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

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

[wysota]

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.

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/.

[auba]

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
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)