-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
fix: invoking code-server in integrated terminal #5360
Conversation
Codecov Report
@@ Coverage Diff @@
## main #5360 +/- ##
=======================================
Coverage 72.42% 72.42%
=======================================
Files 30 30
Lines 1672 1672
Branches 366 366
=======================================
Hits 1211 1211
Misses 398 398
Partials 63 63 Continue to review full report at Codecov.
|
Decided to move this back to a draft. I am going to look into making their script work because that would be the more maintainable solution. |
Doesn't this simply add the same path twice? I.e. $ echo $PATH
/opt/code-server/bin:/opt/code-server/bin:... ℹ️ Because I've already added code-server's bin directory to |
Untested, but maybe we could add an e2e test for this too. Something like: // bin.test.ts
import * as cp from "child_process"
import * as path from "path"
import util from "util"
import { clean, tmpdir } from "../utils/helpers"
import { describe, expect, test } from "./baseFixture"
describe("Bin", true, [], {}, () => {
const testName = "bin"
test.beforeAll(async () => {
await clean(testName)
})
test("should give access to code-server in terminal", async ({ codeServerPage }) => {
const tmpFolderPath = await tmpdir(testName)
const tmpFile = path.join(tmpFolderPath, "pipe")
const command = `mkfifo '${tmpFile}' && cat '${tmpFile}'`
const exec = util.promisify(cp.exec)
const output = exec(command, { encoding: "utf8" })
// Open terminal and type in value
await codeServerPage.focusTerminal()
await codeServerPage.page.waitForLoadState("load")
await codeServerPage.page.keyboard.type(`code-server --help`)
await codeServerPage.page.keyboard.press("Enter")
// It may take a second to process
await codeServerPage.page.waitForTimeout(1000)
const { stdout } = await output
expect(stdout).toMatch(/usage: code-server/)
})
}) |
Yup, for anyone that has already added it to the path it will appear twice. We could add a check to prevent it from being added if it already happens to exist but I think it would be more appropriate to send that upstream than patch it here since it affects upstream as well. (Plus there are no ill effects from having it twice, I think?) |
@jsjoeio that is awesome, I actually intended on adding a test for this so that code will be very helpful! |
@code-asher What about #5335 (comment)? |
I think the ideal solution is going to be to fix upstream's |
From my point of view fixing/patching the script would make more sense and should be better maintanable than patching the actual source code of vs code? |
IMHO there should be no file
Does And yes, |
Yeah renaming the upstream script would cause The only thing theirs does not support is launching a new instance of code-server (it only supports interacting with the current instance of code-server) but I have no idea if that is a common use in the integrated terminal. |
I have never started a new instance of code-server using the integrated terminal. |
The latter named |
Also reposting #5335 (comment) here:
This will also generate a settings conflict should you ever consider resolving #1315. |
For example here is a test with
This opened the file |
Sorry for being dense; how does this change anything with #1315? Our script and upstream's are more or less doing the same thing (run Node and interact with code-server via the socket stored in |
@code-asher Not to have a misunderstanding here: Which extensions are you talking about? |
The VS Code remote extensions. Remote - SSH, remote - containers, and remote WSL I think. Although that issue (#1315) is only about implementing open-source versions of the first two (SSH and containers). |
Not because of But it seems to work correctly. If I remember correctly: When changing
👍
Yes, of course. |
@code-asher Thank you for your explanations. |
Ahh right I see what you mean! Yeah the settings situation has been confusing. Upstream |
5237b0a
to
ba4306f
Compare
ee9a637
to
b7b2128
Compare
Removing it did not help. Still not sure if this is necessary though.
b7b2128
to
86db6e4
Compare
Otherwise if we change the script it will not rebuild Code.
99e3167
to
7b2ddc7
Compare
The selector was timing out even though it matched more than one element but matching on the focused one appears to work. In addition add a loop so even it can keep trying to open the terminal if something goes wrong with the focus.
7b2ddc7
to
b62191a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We reviewed this together in person at the off-site. All looks good!
Fixes #5335
This fixes the path to Node in upstream's scripts then links the right one based on the platform.
There is also some removal of duplicate code where we symlink the asar twice; turns out we do not need this since the standalone release runs yarn which will run the postinstall which will add the link.
If anyone wishes to test manually open up the integrated terminal and run
code-server <file>
. You can try things likecode-server --wait <file>
as well which should work.Possibly in a separate PR we should think about using the same for external terminals then remove our bespoke code.
Thanks to @fritterhoff for linking to where this happens, made this very easy to fix!
Fixes #2110
Follow-up TODOs
--wait
outside code-server)