-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wait for command to finish before continuing #70
Comments
this was discussed a bit in #14, but I agree we should do something about it |
Yep! Thanks for this @jacobtomlinson, we'll definitely introduce something for this since it's probably the most common usecase. It will probably look something like one of these but other suggestions are welcome.
|
I'm working on a PR for this. Will this support shell scripts? E.g.,
or
cc: @caarlos0 @maaslalani |
IMHO, exec should:
so, IMHO there's no need to handle executing files, its just a That said, not sure if we should or not support the |
Another alternative is to have a
|
I tried implementing this but I am afraid I couldn't find a way to wait. We're using Pointers are appreciated. P.S., any reason we're using |
@abhijit-hota I had a similar concern. Is this possible with GoTTY? We can switch over to that. I used |
Doesn't seem so from the documentation.
Fair enough. Just checked that. I have opened a support issue here: tsl0922/ttyd#1009 |
My plan is to support both |
As per tsl0922/ttyd#1009 (comment), We need to get the |
What do you think about the method suggested here: tsl0922/ttyd#1009 (comment) |
Not sure we can use |
Makes sense. There is a chance of conflict between command when using |
The other thing I was thinking is could we somehow set how long the command appears to take in the GIF, regardless of how long it actually took. Some commands vary a lot in execution time, I just did a It would be great to tell |
Another alternative would be specifying some condition that is polled until it is true, and until then further execution is blocked. But for "wait for command to finish" this is a bit of a complicated way, and might not always be possible (or at least easily). |
Some ideas:
|
Can't this be tracked via the process tree? When |
Would that also work for things like |
Would you want it to? Adding the |
Exactly, but the process would still exist, so wouldn't VHS just keep blocking? |
Only if the user calls I'm suggesting syntax like |
Ah, I see; you would still make it an explicit |
I played around with VHS a bit trying to automatically generate small demo videos in CI for our documentation site that are always up to date. Without a way to wait for commands to finish that is not possible, as sleeping for a given time interval is not reliable enough when you try to create a video automatically. So 👍 from my side for this feature request. |
I've tried to implement this feature in my implementation using |
I think the It would solve things like:
The most significant difficulty I see is determining when to start waiting for the output. Waiting for a prompt would be intuitive, but it may not be evident that you'd need to I propose something like this:
Care should be taken so that |
I would throw in that it isn't entirely universal to wait for some output. You might well want to wait for a process to exit without output or for some other state to have been reached. The latter can be considered out of scope, but the former does seem important to me. |
@Airblader hmm, that's a good point. Though when working with a shell, you could wait for the prompt to re-appear. Since it is likely the most common case, maybe we can handle it with a default? Something like:
Though a naked
Maybe it's okay, but here's some other ideas:
|
IMHO: Most universal would be to wait for an exit code. |
I can't entirely agree that an exit code is universal since commands can be interactive. For example, SSH may prompt for a password without giving an exit code before the input is required. But an exit code would work for most use cases. That said, it's also a little challenging to go the exit code route because Something like what @kotborealis suggested could work but may be fragile, as it would only work if the shell is running on the same machine and only if we are not making a tape for a command line tool that's interactive. I've been experimenting with this all day, and I'm trying to settle on an API that makes sense. I currently have it as
|
Going to roll with this for the day and see how it feels, feedback welcome: Example:
|
This is certainly a step forward, but quite brittle for minimalistic prompts. Is there really no way to get the shell execution status hauled all the way through? It may need some drilling to establish a side channel, but tracking PID and exit code would open the door for really robust waiting. That said, such an operation probably breaks the keyboard/screen abstraction, so it comes at a cost. |
@mavam, of course, anything is possible, but it needs some extra thought/planning. For instance, I don't think we can use Context: How VHS Works
I think there are two similar-but-separate problems people are here looking to solve:
The first is straightforward (poll and wait for visible output to match) and is easy with the current architecture. The second is a little more difficult since we'd need to hook into existing supported shells in a way that allows us to monitor and track subprocesses, and breaks the input/output abstraction. To make it work reliably, a keyword like It may be confusing that what is typed by In any case, we would still need to build some out-of-band way to signal from the shell to IMHO, (and it is not my call, only my opinion) I feel like it may be beyond the scope of this tool, so I'm not sure if it's worth the complexity. However, I also have a biased opinion because polling the output has worked very well for my use cases. If there is a subprocess/out-of-band-metadata feature added, though, I vote we call the feature closed-captioning. We could probably embed it in ANSI escape sequences. I am curious, are there some examples that would be broken or impossible with only reading the output of a terminal? |
Thanks for elaborating, this was (at least for me) the missing background information to have the conversation about the options. Deeper shell integration sounds still great, but I understand it comes a significant cost of development. Having control about process spawning, returning, stdout/stderr, etc. would certainly round of VHS as a go-to solution for all declarative demo'ing, even making that part of CI and docs. In the meantime, visual match hooks suit the bill. Fortunately it's possible to embed sequence of UTF-8 characters in prompts that are reasonable unique, and coupled with detecting them at the beginning of a line, this probably solves 90% of the issues. |
Hi, I think this is a good approach. This is very close to SSH I/O automation, "Read Until", "Read Until Prompt", "Read Until Regexp" (link) |
I tried my proposed API for a while, and the
I updated my fork with it and will try it with some projects and see if it feels like a good API before opening a PR. |
@mastercactapus Just curious how your experience has been? |
@luke-hagar-sp It's worked really well; I just updated my branch with the latest to open a PR and will take it from there. |
Is it possible to wait for a command to finish before you continue typing.
I know I can use
Sleep
to wait but I might not know how long the command will take and it could be different every time.The text was updated successfully, but these errors were encountered: