Cmd.exe /c Start

Hi,


Why is it that the START switch doesn't work when its used on a machine unattended i.e. the following command works fine when you are actually signed onto the box but if it's issued from a routine that's running in the background but when no one is actually signed on it doesn't work.

'C:\WINNT\system32\CMD.EXE /c start "My Title" rexx.exe c:\mydir\myscript.rex'

The same happens with the scheduler. The above command never actually works unattended but if you are signed onto the box at the time the job is scheduled it runs absolutely fine.

Any ideas ?

Thanks
Paul

 

Thanks but the posted code is actually running cut from another rexx script so u can ignore the apotrophes. The basic code being run is simply -

C:\WINNT\system32\CMD.EXE /c start "My Title" rexx.exe c:\mydir\myscript.rex

 

Hmmm - I'm gonna take a stab at this one.

Given that it works when someone is signed on but otherwise, it fails, then are you looking at a privilege issue?

Have you tried doing it as a RunAs and invoking an account that has rights to do whatever the script is trying to do?

Another thought - I'm not at all sure what environment variables are loaded when no one is signed on but is it possible that the path statement that allows the system to locate rexx.exe isn't active and that putting in the full path to rexx.exe would cure your problems?

If neither of those ideas helps then I'm gonna have to ask you to unconfuse me some.

C:\WINNT\system32\CMD.EXE /c start "My Title "
Appears to be firing off a cmd session, telling it (via /c) to quit when done, firing off another cmd session (via start) and feeding that 2nd session a non-command called "My Title" followed by a command and a pointer to a script.

I have no idea how that could do anything useful. Obviously it does and it may just be a matter of my total ignorance of rexx.exe but if you could explain, I'd appreciate it.
- why start the 2nd cmd session at all
- why feed it something it shouldn't be able to process