Thx for reminding
But this is really what I want, just run my program in right working directory.
And in fact, in my opinion, setWorkingDirectory should not affect the start, it only affects the new process' env
Thx for reminding
But this is really what I want, just run my program in right working directory.
And in fact, in my opinion, setWorkingDirectory should not affect the start, it only affects the new process' env
Last edited by bood; 5th January 2006 at 11:52.
1. Users don't have the manual, and if they did, they wouldn't read it.
2. In fact, users can't read anything, and if they could, they wouldn't want to.
It affects the place QProcess looks for the file. Look, that you have given a relative path (dir/file) to that file, so QProcess looks for it there and only there.Originally Posted by bood
I don't think so...Originally Posted by wysota
QProcess always looks for the file from the working directory of the process in which QProcess runs. And what QProcess::setWorkingDirectory sets is the working directory of the created process, they are different.
And if you're right, there's no reason that it works well when dealing with exefile. You can try replacing the test.bat with an ordinary exefile, and change the macro EXE defined in main.cpp correspondly. You'll find everything works fine.
1. Users don't have the manual, and if they did, they wouldn't read it.
2. In fact, users can't read anything, and if they could, they wouldn't want to.
Oh, you're calling a QProcess::setWorkingDirectory() method... You're right then, it doesn't influence where QProcess looks for the program.
How does your script work?
Last edited by wysota; 5th January 2006 at 13:35.
Did you download my example in my first post?Originally Posted by wysota
The example has two QProcess, one without setWorkingDirectory called before calling start(QProcess1), while the other does(QProcess2). And both QProcess start a batch file called test.bat under `bin` directory(the batch file just has an echo command to output a string), then readAll is called to collect the output which is later presented in a QMessageBox. You'll find the output collected from QProcess1 is empty while the other works as I expected.
1. Users don't have the manual, and if they did, they wouldn't read it.
2. In fact, users can't read anything, and if they could, they wouldn't want to.
The process here isn't started at all, so it looks like setWorkingDirectory influences the way QProcess starts the process. The problem is with the script itself, so it seems.
I agree with you. AFAIR is worked this way in Qt3, but apparently in Qt4 QProcess changes the current directory just before it executes the program.Originally Posted by bood
It does not neither in QT4, see my explanation above.Originally Posted by jacek
You mean my example given above? But where's the problemOriginally Posted by wysota
1. Users don't have the manual, and if they did, they wouldn't read it.
2. In fact, users can't read anything, and if they could, they wouldn't want to.
OK ,Ok, I give up...
I manage to find that it's not the problem of QT4, but rather the trick of M$.
When calling the CreateProcess to run a batch file, the working directory passing in does affect, and in an inexplicable way (maybe cmd.exe related). I've decided to use the absolute path instead.
So if anyone wants the answer, ask M$ for the source code of windows...:P, Seriously, if anyone knows what's going on, please tell me.
1. Users don't have the manual, and if they did, they wouldn't read it.
2. In fact, users can't read anything, and if they could, they wouldn't want to.
It's not a problem with MS Windows. I experience the same behaviour under Linux (using #!/bin/sh echo hello as a script). But this is definitely connected with scripts. I guess this might be a standard behaviour and has nothing to do with Qt.
Bookmarks