-
Notifications
You must be signed in to change notification settings - Fork 207
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
Terminal post-attach commands #83
Comments
Generally I like where this is going! /cc @craiglpeters as well
Hmmm. Is this trying to say that this wouldn't be automatically run by the any implementing system at the time it starts, but hold until the attach is complete? If so, that's the definition of Perhaps this is more "wait for tty" (the Assuming all of this tracks, possible names for the property could be:
We could also talk about this in terms of whether it's a "background" executed step or not where "foreground" implies in a terminal. We'd need to figure out what the exec flag would be or an equivalent for the CLI, but that would allow:
|
To confirm: are you saying that it'd be up to the attaching tool to decide whether/how to fulfill the ask for a TTY with which to run the commands? Devcontainer CLI could do it with the If I understand you right that sounds like what we want 👍
This seems to speak more to timing, where I think as a user the significant thing is where/how the command is run. Foreground/background make intuitive sense to me 🤔 |
Yep! Exactly.
Yeah, the other option would just be to embrace |
cc also @ThisIsKirsch for thoughts on nomenclature |
Updated OP with the outcomes 👍 Notes from sync:
|
The examples Is the goal of The example includes |
@chrmarti That's a good point - if you attach the tool multiple times it probably shouldn't fire. Correct @joshaber ?
It is both. Yeah honestly, I don't think there's a reason to not pipe stdin as well as stdout for any of the commands. That said, some CLIs do behave differently depending on whether they are in a terminal or not (e.g. using
No that's a tool specific example. I believe the thinking here is that this would actually tie to profiles in some way - so there's VS Code considerations, but not directly part of the spec since other products/services will have different needs. |
Just to clarify: Currently the lifecycle commands all run in a PTY (also when the output is not shown in a terminal), so If Codespaces uses the extension API to open the terminal (I assume it will), there is a flag to immediately reveal the terminal. |
Ah cool. So then, yeah, I really don't see any reason not to make them all support stdin by default TBH. At that point, is the flag even needed? I think part of this is a hint to put the terminal in focus, but isn't that more related to the tool specific layout config? What do you think @joshaber ? |
I see a few key parts of this proposal:
If we switch everything to default to TTY with stdin and defer execution until clients request it, then I don't think we need to support the |
I've started formalizing this into a proposal at #88 so that we can nail down the specifics. |
CLI PR: devcontainers/cli#172 |
Closing as this has been merged as a proposal into the spec: https://github.com/devcontainers/spec/blob/main/proposals/parallel-lifecycle-script-execution.md. Thanks all! |
Problem
We want to codify the post-attach commands which clients should run in parallel, interactive terminals.
For example: I always want my server (
npm start
) and my file watcher (npm run watch
) running when I connect.Proposal
Details
postAttachCommand
to:postAttachCommand
will default toterminal: true
.command
is the command to run.Example:
Open Questions
terminal: true
be the default behavior forpostAttachCommand
?postAttachCommand
usage in the wild it looks like many of the use cases would either (1) be improved by running in interactive terminals, or (2) surface to the user thatpostAttachCommand
is the wrong lifecycle hook for the behavior they want.cc @Chuxel @jkeech since this is coming out of conversations with y'all
The text was updated successfully, but these errors were encountered: