Currently shellpipe_sync is essentially a blocking fork and as such freezes up the map UI by design. The shellpipe_async mechanism can be used for non-blocking scripts.
It would be helpful to allow shellpipe_sync to take an additional timeout argument or similar to check so that
a script doesn't take more than a given number of seconds or otherwise kills the spawned process(es). The main usecase in which this would be helpful is for long running scripts (such as the Overpass search script) which can sometime take >10 seconds to return. The user may be confused about what is going on and displaying a message like shellpipe_sync request took too long to return may infact be preferable to having the user wait for the data to be returned.
A complication in implementing such functionality might be the script called by shellpipe_sync would have to be fully cleaned up (e.g. subprocesses spawned etc) which may be tricky to do in a robust / exhaustive way.
An alternative would be to implement timeouts in the default provided scripts logic; however that seems less 'user-friendly'.
Based on similar logic to
shellpipe_async, the logic forshellpipe_synccould be reworked so that shellpipe_sync operates 'in the background / asynchronously' but still locks the UI (e.g. this would just be a boolean flag in logic). Right now the UI lock is just due to the forking (and is kind of confusing from a user-point of view in that the graphics on SDL may freeze).So in this new implementation, things would alter from the forking implementation currently in that the application logic 'could' still process SDL events etc (thus the UI wouldn't be 'frozen'). which would give the advantage of allowing for potentially a shellpipe_sync_cancel command or similar to be executed via a hotkey or a UI button etc.
With this new implementation we could also show a duration elapsed counter in the UI while shellpipe_sync is running which would give the user a better sense that 'things are still working'.. (Or we could event redirect the STDERR/STDOUT into the UI display?)
Some thought would need to be put into what events / commands should be processed and how the UI should react in this state. E.g. what commands should work vs be dropped?
Superceeded by #65