I have a script that launches several tabs in ROXterm in one window that looks like:
roxterm --tab-name A &
roxterm --tab --tab-name B &
roxterm --tab --tab-name C &
roxterm --tab --tab-name D &
but I found that the order in which the tabs were created was not deterministic. That's probably because the real commands involve launching commands within the terminal tabs, which vary in execution time.
My first thought was to inject a sleep call after each command, which works, but it is clunky.
Realizing that the subsequent roxterm invocations exit after sending the new tab request to the existing roxterm process, I dropped the sleep calls except for a two second pause after backgrounding the initial process, and removed the "&" from the subsequent commands.
That works great, except when the first command fails for some reason. Then you get the second tab created, and because that process isn't explicitly backgrounded in the script, the script hangs at that point. The desired result is to exit on failures.
It feels like there ought to be a more orthogonal interface, where you deal with launching the initial process separately from creating any tabs, and that it has the intelligence to background itself, if there are no startup errors. Plus, shouldn't a particular invocation have some sort of an identifier, so that you can later refer to it when adding tabs? Otherwise, how does roxterm decide which process to add new tabs to?
That would result in a syntax something like:
roxterm --background --id=main && \ roxterm --id=main --tab --tab-name A && \ roxterm --id=main --tab --tab-name B && \ roxterm --id=main --tab --tab-name C && \ roxterm --id=main --tab --tab-name D
Presuming each invocation returns a proper exit code, the script will abort on the first failure, and tabs should be created in a predictable fashion.
This also permits creating multiple windows, each with their own specific set of tabs.
Of course this is extra work to implement, and except for a few probably rare cases, doesn't really provide any new functionality, so I posting this for discussion rather than a feature suggestion.
-Tom
