Time-limit shell command (Windows)

[Ben Rubinstein]

Martin that's so kind, thank you. I will investigate OpenProcess and see if I 
can make this work.

Ben

On 29/08/2026 12:52, Martin Koob wrote:
> Hi,
> 
> Rather than *shell()* you can use *open process* in LiveCode to have the 
> process run asynchronously, get PIDs to monitor progress and kill processes at 
> a time point.  I had a vague idea of how this worked in theory.  But, instead 
> of relying on my rusty brain I opened my trusty ChatGPT (5.6 sol light) and 
> trying a few different prompts in order to fully understand the process it 
> produced something that I understand and I think should do what you want. Here 
> is a list-server friendly summary I asked ChatGPT to make of a much longer chat.
> 
>     ChatGPT //////./////.//////./////.//////./////.//////./////.//////./////.//////./////.//////./////.//////./////.//////./////.//////./////.//////./////.//////./////.
> 
>     This is possible, but a shell process cannot directly call a LiveCode
>     handler. It must communicate its progress and final result back through
>     something LiveCode can monitor, such as stdout, a status file, or a
>     localhost socket. LiveCode then turns that event into a callback message.
> 
>     The shell() function is synchronous, so calling a long-running command
>     with shell() will block LiveCode. It can still be used briefly to launch a
>     properly detached background process and obtain its PID, provided all of
>     the process’s standard streams are redirected.
> 
>     The open process command is another possibility. Unlike shell(), open
>     process starts a process and returns immediately. It can open the process
>     for reading, writing, both, or neither. LiveCode can also inspect
>     openProcesses and openProcessIDs. However, open process does not provide
>     an automatic completion callback, and support for Unix command-line
>     processes on macOS is limited.
> 
>     A practical cross-platform design would be:
> 
>     LiveCode starts a detached worker and records its PID.
>     The worker writes progress messages to a file or local socket.
>     LiveCode uses “send monitorJob to me in 100 milliseconds” to check
>     progress without blocking the UI.
>     A launcher or watchdog enforces the time limit and terminates the worker
>     if necessary.
>     The worker or launcher writes a final status such as success, error, or
>     timeout, together with the exit code and message.
>     The LiveCode monitor handler dispatches the appropriate success or error
>     callback.
> 
>     For example, the final status might be:
> 
>     success,0,Completed
> 
>     error,17,Could not open input file
> 
>     timeout,124,Process exceeded its time limit
> 
>     The LiveCode monitoring handler would read that status and dispatch
>     something such as jobSucceeded or jobFailed. Therefore, the “callback” is
>     generated by LiveCode after it receives the process result; it is not a
>     direct call from the shell process.
> 
>     For simple and reliable jobs, I would use progress and status files. For
>     frequent or immediate updates, a localhost socket is more event-driven.
>     Reading stdout from an open process can also work, but care is needed
>     because a read can block if no output is available, and the child process
>     may buffer its output.
> 
>     This is similar to the behavior exposed by tsNet, although tsNet
>     implements its asynchronous work and callbacks inside an external library.
> 
>     \\\\\.\\\\\\.\\\\\\\\.\\\\\\.\\\\\.\\\\\\.\\\\\.\\\\\\.\\\\\.\\\\\\.\\\\\.
>     \\\\\\.\\\\\.\\\\\\.\\\\\.\\\\\\.\\\\\.\\\\\\.\\\\\.\\\\\\.\\\\\.\\\\\\.\\
>     \\\.\\\\\\.\\\\\\.ChatGPT
> 
> 
> If you are interested in the full chat which includes code to implement the 
> ideas above using Windows( as Ben asked) and a fuller exposition of the 
> concepts I can upload the full chat where ever you think is best.  (I am 
> pretty sure I can't send it through the use-LiveCode list.)
> 
> WARNING: I have not tested this idea out. ChatGPT is fairly good with LiveCode 
> and pretty solid at creating shell code but it does make syntax errors in 
> LiveCode at times. I have added rules in my ChatGPT memory to catch some 
> common ones I have come across e.g. it makes up weird ways to end up repeat 
> blocks.  Correcting it in the chat never had a lasting effect. For example, It 
> would pick random ways from other programming languages. I had to explicitly 
> ask it to commit the correct LiveCode way to create repeat loops to memory.
> 
> Martin
> 
>> On Aug 27, 2026, at 11:22 AM, Ben Rubinstein via use-livecode <use- 
>> livecode at lists.runrev.com> wrote:
>>
>> Thanks Bob; but I was hoping to do this in LiveCode.
>>
>> e.g. is there a way to invoke a shell command to run asynchronously, 
>> returning the PID to LiveCode so that it can be monitored?
>>
>>
>> On 26/08/2026 16:26, Bob Sneidar via use-livecode wrote:
>>> <https://superuser.com/questions/520527/windows-command-line-time-limit>
>>> superuser.com<https://superuser.com/questions/520527/windows-command-line- 
>>> time-limit>
>>> [X]<https://superuser.com/questions/520527/windows-command-line-time-limit>
>>> I just googled it.
>>> Bob S
>>> On Aug 26, 2026, at 02:07, Ben Rubinstein via use-livecode <use- 
>>> livecode at lists.runrev.com> wrote:
>>> Hello hive mind,
>>> Is there a way from LiveCode to invoke a shell command with a time limit, 
>>> to force it to fail after a certain time? (This is on Windows.)
>>> many thanks,
>>> Ben
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>