Batch file run by trigger behaves differently than run locally?

JoshuaJSlone

OK, I am extremely new to TRIGGERcmd, and having difficulty with my first trigger. I've set up a simple .bat file in Windows, to kill a program and then restart it. I added a bit of display and short timers so it wouldn't be so instantaneous I'd miss it running, at least for testing purposes. It looks like

ECHO Here we go.
TIMEOUT /T 3
taskkill /IM "theprogram.exe" /F
TIMEOUT /T 3
theprogram.exe

When I run it directly from Windows, it behaves as I'd expect.

I set up a trigger with a command like "C:\Program Files\yadayada\restarttheprogram.bat", to be run in the foreground. When I trigger it either from the Windows GUI or from a short link, no window with the messages and timers appears. It does kill the program so it is doing part of what is expected, but then it never restarts the program. I wondered if TRIGGERcmd was lacking permissions, but running it as administrator didn't seem to make a difference.

Russ

@JoshuaJSlone, that's a known issue with the windows timeout command. It doesn't work in contexts that don't have an interactive terminal, like when running it via TRIGGERcmd. Here's one method that does work:

start /wait timeout 3

I've also added delays with the ping command like this:

ping 127.0.0.1 -n 2

Carol Clark

This is one of those old-fashioned Windows batch bugs that only manifests after interactive operations are discontinued.

Your.bat is launched in a non-interactive session by TRIGGERcmd. Even if you say "foreground," there isn't a true console connected, so anything that thinks it's a tty may silently misbehave. The reason your script gets beyond taskkill but never reaches the restart is because TIMEOUT is infamous for its ability to either quit instantly or block strangely when there is no interactive terminal.

it also explains why there isn't a window: Unless you specifically force a visible cmd.exe session, TRIGGERcmd is not generating one.

Avoiding TIMEOUT in this situation is the solution. It spins up its own process with a suitable wait handle, thus wrapping it with start/wait works. For the same reason, ping 127.0.0.1 -n X works; console state is irrelevant. If you really want to view output, using cmd /c or cmd /k manually is a good alternative.

Additionally, ensure that the program.exe is launched using the whole path rather than just the working directory. Since C:\Windows\System32 is often used as cwd when triggers execute, relative paths will fail silently.

In summary, it's not a TRIGGERcmd problem or a permissions issue. Batch + non-interactive Windows execution is used. It will act the same as if you ran it locally if you change the TIMEOUT and use complete paths.