A script is waiting for a process to start; it shall do so indefinitely, but only as long as there is no human input. In another words: the script shall wait for either process start or human input, whichever comes first (also, the process may already be running when the script starts, in which case the script shall close immediately). I have thought of something like this, but there’s likely a better way, since this loop doesn’t break with input:
while (A_TimeIdlePhysical > 100) {
Process, Wait, SomeProcess.exe
}
Any ideas?
Tested with notepad:
#Persistent
SetTimer, DetectProcess, 50
return
DetectProcess:
If (ProcessExist("notepad.exe")) ; if the process is already running
ExitApp
; otherwise:
If (A_TimeIdlePhysical > 100) ; as long as there is no human input
{
If (ProcessExist("notepad.exe")) ; wait for either process start
ExitApp
}
else ; or human input
ExitApp
return
ProcessExist(ProcessName){
Process, Exist, %ProcessName%
return Errorlevel
}
Related
So my understanding is that after command can be used to delay the execution of a script or a command for certain ms but when i execute the below command, the output is printed immediately
Command:
after 4000 [list puts "hello"]
Output:
hello
after#0
Question: Why was the output not delayed for 4s here?
That what you wrote works; I just tried it at a tclsh prompt like this:
% after 4000 [list puts "hello"]; after 5000 set x 1; vwait x
Did you write something else instead, such as this:
after 4000 [puts "hello"]
In this case, instead of delaying the execution of puts, you'd be calling it immediately and using its result (the empty string) as the argument to after (which is valid, but useless).
Think of [list …] as a special kind of quoting.
The other possibility when running interactively is that you take several seconds between running the after and starting the event loop (since the callbacks are only ever run by the event loop). You won't see that in wish of course — that's always running an event loop — but it's possible in tclsh as that doesn't start an event loop by default. But I'd put that as a far distant second in terms of probability to omitting the list word…
I have a number of hotkeys which go through various processes and sleep for certain periods of time to allow animations to be shown. I want to setup a variable to allow only 1 to activate at a time...so if I hit the first and then the second....the second doesn't do anything until the first completes. Similarly I don't want to double activate any of them by mashing the same key right after I first press it.
F4:ExitApp
#IfWinActive ahk_class notepad
a::
if (work:=true){
work:=false
soundbeep
;do something
sleep 1000
work:=true
}
return
b::
if (work:=true){
work:=false
soundbeep
;do something else
sleep 2000
work:=true
}
return
i.e. if I hit 'a'....'b' cannot activate until the sleep of 'a' ends. Nor should 'a' be able to activate a second time...at least not until its sleep ends and work=true again.
This leaves 2 problems. I need to first somehow specify the initial value of 'work=true'. I do not know how to do this in the traditional sense. Simply putting it at the top of the code doesn't work. Second problem, putting this in another key...like enter:: work:=true return....and pressing that key initially...this doesn't work as it allows b to beep while a is still in its sleep phase. So maybe the code above is flawed to begin with as well. Individual keys seem to respect themselves and not re-initialize until after the first instance has completed...so the beeps work if I just mash 1 key. Also I don't want to have to press enter to get the code to work after loading the script.
Is there an easy cheat here? Like in lua undeclared variables are automatically false... so I could just swap to if (work=false){...., I can't find any such behaviour with autohotkey though.
As requested, here is a different solution that uses variable logic to allow or prevent hotkey commands from executing:
#IfWinActive ahk_class Notepad
work:=true
a::
if(work){
work:=false
soundbeep
;do something
sleep 1000
work:=true
}
return
b::
if(work){
work:=false
soundbeep
;do something else
sleep 2000
work:=true
}
return
Update: Breakdown of how it works
First, the script begins in the auto-execute section. As summarized elegently by maul-esel
When an AutoHotkey script launches, it just starts execution from the
first line of your script. It continues from there line by line until
it hits an end point. This is called the auto-execute section.
As such, by including work:=true in this section of the script, not only are we initializing the value of the variable before any hotkeys are triggered, we set the scope of work to be a global variable, accessible across different hotkeys.
The rest of the script is a bit more straightforward, where each hotkey is essentially (in pseudocode):
When the hotkey is triggered
if work is true
set work to false
Beep and etc.
Wait for some amount of time
Then set work back to true so that another command can be run
End the hotkey
One simple way to do it would be to declare #MaxThreads 1 at the top of your script.
As a side note, there appear to be a few other syntax errors in the script. For example, when comparing values (like in an if statement), you still use the regular, single = and not the assignment :=. Also, the ahk_class is case sensitive, and as such #IfWinActive ahk_class notepad should be replaced with #IfWinActive ahk_class Notepad.
Updated Code (Work Variable logic was removed as it is no longer needed):
#MaxThreads 1
#IfWinActive ahk_class Notepad
a::
soundbeep
;do something
sleep 1000
return
b::
soundbeep
;do something else
sleep 2000
return
To test the integrity of PostScript files, I'd like to run Ghostscript in the following way:
Return 1 (or other error code) on error
Return 0 (success) at EOF if stack is empty
Return 1 (or other error code) otherwise
I could run gs in the background, and use a timeout to force termination if gs hangs with items left on the stack. Is there an easier solution?
Ghostscript won't hang if you send files as input (unless you write a program which enters an infinite loop or otherwise fails to reach a halting state). Having items on any of the stacks won't cause it to hang.
On the other hand, it won't give you an error if a PostScript program leaves operands on the operand stack (or dictionaries on the dictionary stack, clips on the clip stack or gstates on the graphics state stack). This is because that's not an error, and since PostScript interpreters normally run in a job server loop its not a problem either. Terminating the job returns control to the job server loop which does a save and restore round the total job, thereby clearing up anything left behind.
I'd suggest that if you really want to do this you need to adopt the same approach, you need to write a PostScript program which executes the PostScript program you want to 'test', then checks the operand stack (and other stacks if required) to see if anything is left. Note that you will want to execute the test program in a stopped context, as an error in the course of the program will clearly potentially leave stuff lying around.
Ghostscript returns 0 on a clean exit and a value less than 0 for errors, if I remember correctly. You would need to use signalerror in your test framework in order to raise an error if items are left at the end of a program.
[EDIT]
Anything supplied to Ghostscript on the command line by either -s or -d is defined in systemdict, so if we do -sInputFileName=/test.pdf then we will find in systemdict a key /InputFileName whose value is a string with the contents (/test.pdf). We can use that to pass the filename to our program.
The stopped operator takes an executable array as an argument, and returns either true or false depending on whether an error occurred while executing the array (3rd Edition PLRM, p 697).
So we need to run the program contained in the filename we've been given, and do it in a 'stopped' context. Something like this:
{InputFileName run} stopped
{
(Error occurred\n) print flush
%% Potentially check $error for more information.
}{
(program terminated normally\n) print flush
%% Here you could check the various stacks
} ifelse
The following, based 90% on KenS's answer, is 99% satisfactory:
Program checkIntegrity.ps:
{Script run} stopped
{
(\n===> Integrity test failed: ) print Script print ( has error\n\n) print
handleerror
(ignore this error which only serves to force a return value of 1) /syntaxerror signalerror
}{
% script passed, now check the stack
count dup 0 eq {
pop (\n===> Integrity test passed: ) print Script print ( terminated normally\n\n) print
} {
(\n===> Integrity test failed: ) print Script print ( left ) print
3 string cvs print ( item(s) on stack\n\n) print
Script /syntaxerror signalerror
} ifelse
} ifelse
quit
Execute with
gs -q -sScript=CodeToBeChecked.ps checkIntegrity.ps ; echo $?
For the last 1% of satisfaction I would need a replacement for
(blabla) /syntaxerror signalerror
It forces exit with return code 1, but is very verbous and distracts from the actual error in the checked script that is reported by handleerror. Therefore a cleaner way to exit(1) would be welcome.
I am completely new in Expect, and I want to run my Python script via Telnet.
This py script takes about 1 minute to execute, but when I try to run it via Telnet with Expect - it doesn't work.
I have this expect simple code:
#! /usr/bin/expect
spawn telnet <ip_addr>
expect "login"
send "login\r"
expect "assword"
send "password\r"
expect "C:\\Users\\user>\r"
send "python script.py\r"
expect "C:\\Users\\user>\r"
close
When I replace script.py with the one with shorter execution time - it works great. Could you tell me what should I change, so I can wait until my script.py process will terminate? Should I use timeout or sleep?
If you are sure about the execution time of the script, then you can add sleep or set the timeout to the desired value
send "python script.py\r"
sleep 60; # Sleeping for 1 min
expect "C:\\Users\\user>"; # Now expecting for the prompt
Or
set timeout 60;
send "python script.py\r"
expect "C:\\Users\\user>"; # Now expecting for the prompt
But, if the time is variant, then better handle the timeout event and wait for the prompt till some amount of time. i.e.
set timeout 60; # Setting timeout as 1 min;
set counter 0
send "python script.py\r"
expect {
# Check if 'counter' is equal to 5
# This means, we have waited 5 mins already.
# So,exiting the program.
if {$counter==5} {
puts "Might be some problem with python script"
exit 1
}
# Increase the 'counter' in case of 'timeout' and continue with 'expect'
timeout {
incr counter;
puts "Waiting for the completion of script...";
exp_continue; # Causes the 'expect' to run again
}
# Now expecting for the prompt
"C:\\Users\\user>" {puts "Script execution is completed"}
}
A simpler alternative: if you don't care how long it takes to complete:
set timeout -1
# rest of your code here ...
I'm launching a single EXE from a Tcl script, and would like to get the output from the EXE and display it using a simple PUTS command to provide user feedback. At the moment, I am launching the EXE in a CMD window where the user can see the progress, and waiting for the EXE to create a file. The first script here works whenever the output file LUC.CSV is created.
file delete -force luc.csv
set cmdStatus [open "| cmd.exe /c start /wait uc.exe"]
while {![file exists "luc.csv"]} {
}
# continue after output file is created
However, sometimes the file is not created, so I can't rely on this method.
I've been trying to get my head around the use of fileevent and pipes, and have tried several incarnations of the script below, but I'm obviously either missing the point or just not getting the syntax right.
puts "starting"
set fifo [open "| cmd.exe /c start uc.exe" r]
fconfigure $fifo -blocking 0
proc read_fifo {fifo} {
puts "calling read_fifo"
if {[gets $fifo x] < 0} {
if {[eof $fifo]} {
close $fifo
}
}
puts "x is $x"
}
fileevent $fifo readable [list read_fifo $fifo]
vwait forever
puts"finished"
Any help would be greatly appreciated!
If you just want to launch a subprocess and do nothing else until it finishes, Tcl's exec command is perfect.
exec cmd.exe /c start /wait uc.exe
(Since you're launching a GUI application via start, there won't be any meaningful result unless there's an error in launching. And in that case you'll get a catchable error.) Things only get complicated when you want to do several things at once.
To make your original code work, you have to understand that the subprocess has finished. Tcl's just vwaiting forever because your code says to do that. We need to put something in to make the wait finish. A good way is to make the wait be for something to happen to the fifo variable, which can be unset after the pipe is closed as it no longer contains anything useful. (vwait will become eligible to return once the variable it is told about is either written to or destroyed; it uses a variable trace under the covers. It also won't actually return until the event handlers it is currently processing return.)
puts "starting"
# ***Assume*** that this code is in the global scope
set fifo [open "| cmd.exe /c start uc.exe" r]
fconfigure $fifo -blocking 0
proc read_fifo {} {
global fifo
puts "calling read_fifo"
if {[gets $fifo x] < 0} {
if {[eof $fifo]} {
close $fifo
unset fifo
}
}
puts "x is $x"
}
fileevent $fifo readable read_fifo
vwait fifo
puts "finished"
That ought to work. The lines that were changed were the declaration of read_fifo (no variable passed in), the adding of global fifo just below (because we want to work with that instead), the adding of unset fifo just after close $fifo, the setting up of the fileevent (don't pass an extra argument to the callback), and the vwait (because we want to wait for fifo, not forever).