Do modes 1 and 2 of the shell class behave the same on windows as on unix?
I was shelling out to start and stop a server… that has stopped working since migrating to windows…
I am not getting data available or command completed events in windows…
Are you setting the timeout property? On Windows, the shell may be timing out if it takes too long. If so, it dies silently.
Interesting… I can see that happening in mode 0, but in modes 1 and 2?
set timeout to -1
no difference.
What command are you using? There are windows commands that aren’t shell-friendly.
I am shelling out to some custom commands like
cd \Program Files\CTP & java -jar launcher.jar start
Which on mac is slightly different, cd \Applicatons\CTP ; sudo java -jar launcher.jar start
Either way the output when run from the command line is identical on windows and mac…
If you replaced your command with something like this:
cd \Windows & dir
Does that work as expected? Also does this only happen in a specific project/circumstance (i.e. Web only, Shell in a thread, etc.)? Can you reproduce this in a simple project?
I have a sample project that demonstrates the issue.
However you may need to change the command that I use on your system.
link text
In my real application all shell commands on windows behave the same as this demo. That is there is no command completion or data available from the shells who use mode 1 or 2.
If it were one executable in particular that behaved this way I would say that the issue is with the application.
I’m really getting late on this project due to this issue.
I changed the commands to your example and the issue persists.
dim cmd as string
#If TargetWin32
cmd = "cd \\Windows & dir"
#ElseIf TargetMacOS
cmd = "cd /Applications ; ls start"
#Endif
I see, you are creating the Shell in a thread, this is definitely a bug on our end. We switched threading models on Windows in 2013r3, so I bet you’d have better luck in 2013r2. The other workaround is to execute your Shell on the main thread. In the meantime we’ll get this fixed for some future release, sorry for the inconvenience.
If your app isn’t running from the system volume then then using relative paths will fail unless there’s a directory named “Windows” at the root of the current volume. A Windows shell has both a current directory and a current volume; you need to switch to the correct volume before you set the current directory. You can change volumes by entering its drive letter and a colon:
D:\\>C:
C:\\>
For the most reliable code, use the environment variables provided by the Windows shell (like %SYSTEMDRIVE%) or use shell paths from the SpecialFolder class.
e.g.
dim cmd as string
cmd = "%SYSTEMDRIVE% & dir windows"
'OR
cmd = "dir %SYSTEMDRIVE%\\Windows"
'Or cmd = "dir " + SpecialFolder.Windows.ShellPathHow does one do that?
As for moving back to r2 … I wonder if the project files are backwards compatible??
Andrew thanks for the advice on paths, but in this case the command isn’t the problem, the fact that the shell never informed me that it has completed the task is the issue we are trying to resolve. But your right I will make sure to pay attention to both the current drive and current working directory. I thought those could be set as environment variables prior to executing the shell’s execute function.
Case # in Feedback?
Ditto - what’s the feedback case #?
There’s nothing in there that I can think of that will NOT work in R2
At most you’ll get a warning that the file was created in a newer version
Yes I’m backing up all my project files as we speak as rolling back to r2 may solve the problem but it makes all kinds of warnings about loosing data in the project files… no feedback as to how my project may be effected.
Ok switched back to r2 loaded the bug demo project, changed my commands and this is still not getting events.
Got a sample project from Xojo with a work around…
Doesn’t work. r3.1 or r2
Not sure why the instance of CTPRunner wasn’t put into the globals instead the shells were taken out of the instance of CTPRunner from app and put into the globals of the program. (This made no difference on my machines running r2 or r3.1)
I’m really muffed up.
I wouldnt say its fixed i’d say there is a work around that hasn’t worked for me, but I’m still trying.