Terminal bootstrap interrupt ttab command
Avivbens opened this issue · comments
On executing commands via ttab, there are times that the Terminal bootstrap cancels the execution of ttab, because it's been inserted before the bootstrap:
What is Terminal bootstrap? Are you referring to a hooking mechanism for Terminal.app for custom functionality?
Note that ttab simply delegates the command execution in the new tab to Terminal.app's do script command, and that command has no parameters with respect to timing.
I mean that the terminal loads all configurations from ~/.zshrc, which can cause a delay
The command from ttab often getting executed before that bootstrap
I see. When I provoke the symptom (in bash), I see a display problem:
The command is printed twice:
- first intermingled with output from the profile / initialization file, if any
- then again, after the profile / initialization file has loaded - when it is - successfully - executed.
Are you seeing more than a display problem?
Yeah, but it's not about printing it twice, I don't care if it does.
Problem is that there is a chance the command won't get executed 😥️
How long does processing of ~/.zshrc typically take in your case?
When it fails, what, specifically, happens / doesn't happen?
The best thing that could be done is to introduce a fixed delay before ttab sends the command,
perhaps configurable via an environment variable.
Since you're the first one to report this problem, I'm assuming that it is rare, so I'm hesitant to put in a default delay.
The shell bootstrap could take 0.5-7.5 seconds, depending on the machine warn up. In most cases, it's like 0.7.
Once it fails, it simply prints the command before the bootstrap and that's it.
I think the best solution will be that delay via a flag, with a default of no delay.
Makes sense. I assume a granularity of seconds is enough?
Let's put it in ms format, so it'll be easier to config and determine the exact time 🙂
v08.0 was just published (also to the npm registry).
-l <secs> specifies a delay, and the value can be fractional (e.g. -l 0.8)
I put in a small default delay (0.1) to lessen the risk of running in the problem you saw.
You may preset the default via environment variable TTAB_CMD_DELAY
One caveat is that the delay affects how long a tab is temporarily activated when using the -g / -G options.
As an aside:
The Homebrew installation is still cumbersome, and I wonder if ttab is now "notable" enough to warrant inclusion as a core Homebrew formula.
See #49, if you're so inclined (the OP there asks for a tap, which I haven't looked into yet, but inclusion as a core formula is obviously preferable).
Works like a charm ✨️
Glad to hear it, @Avivbens.