Code-server: Allow opening files, folders, and workspaces in existing code-server from CLI

[avelino]

As a user who use Terminal a lot i would like to open files that way.

Sometimes ne also navigate away from workspace to find something, and again sometimes need to previev or edit files. And then it would be awsome if that could happend from the Terminal.

new feature on VSCode 1.31 Current working directory used for links
see: https://github.com/Microsoft/vscode/blob/622b3d62dd92ea1bcdc7d250e0a7565b018edcee/src/vs/workbench/contrib/terminal/electron-browser/terminalLinkHandler.ts

[schrej]

Alternatively just running code-server <filename> to open a file in the currently running instance, like you can do with the code command, would be awesome.

[xerothermic]

Hi, @code-asher, @kylecarbs

I'm interesting to help out. Can you please give me some estimated effort and a pointer to get start?

[deansheather]

@xerothermic code-server is currently in the midst of a large rework, so once that's merged in we'll be glad to accept your contributions.

[code-asher]

This would be neat. We'd need to make code-server listen on a socket then add a flag of some kind to open in an existing instance at which point it would send the file name on the socket. The existing instance would pick that up and send it to the client running on the browser which would then open the file.

[frank-dspeed]

@code-asher this will also need some kind of instance mapping to the client the client needs to be aware via pid files what is running then it could send via that pid a signal to optain the ports or it stores also the state in some file.

Use Case

code-server "instance 1"
code-server "instance 2"

[code-asher]

That makes sense. One idea floating around is that we daemonize
code-server so there would only ever be one instance running anyway. I'm
not sure how much reliance there is on being able to run multiple
instances of code-server on the same machine though (although it seems
Docker would be better suited for that kind of setup).

[frank-dspeed]

@code-asher It depends on context switching in Project that depend them self on multiple docker images this is a hugh win.

i for my self often want to open diffrent projects as root on my servers. i like doing changes to /etc/* via code-server as it allows me fast search replace and all that.

[frank-dspeed]

oh and a other usecase is when you apply expensiv security stuff befor the instance gets routed then its also a hugh win to switch the context of a already running editor.

[code-asher]

It was suggested in #1586 that we could also make it possible to choose the pane to open a file in.

Since VS Code is obviously capable of opening files in an existing instance, I wonder if they're using their sockets to accomplish this? And if so, can we just do the same thing instead of creating our own socket?

[HankHuangX]

I tried 'code-server filename' to open a certain file (Code-server version 3.1.0). However, code-server regards it as a new folder name. How can I open a file? Thank you. : )

[deansheather]

I have a proposal. When code-server is started we could create an IPC channel or a socket in a standard directory with a standard name format based on the PID of code-server (e.g. /tmp/code-server_1234.sock). When we fork terminal processes, we could add CODE_SERVER_PID=x to the env of the terminal.

If code-server detects this env variable, code-server filename.ext will send a message over that channel to the master process, instructing it to open the file in the editor. I don't think we need to worry about people opening files in code-server outside of the terminal, since most users will be using code-server via the inbuilt terminal.

cc: @code-asher @nhooyr

Edit: Could alternatively be a named fifo pipe, and the filename could be a random string instead of PID (and the env var would be CODE_SERVER_COOKIE or something).

Dunno what protocol we'd run on the socket, could have a HTTP API (kinda wack) or something backed by zeromq/grpc.

[deansheather]

@HankHuangX this feature has not been implemented yet, so you cannot open files in the current code-server instance from a terminal for now.

[HankHuangX]

@deansheather Thanks for your reply.😃

[code-asher]

@deansheather I took a look at what VS Code does and it looks like they're doing essentially what you described. They create a randomly named socket and put the path in an environment variable then spawn an http server on that socket which expects some JSON for each request that describes the action to perform.

So I think we can just check for that environment variable and if it exists then send the appropriate http request to the socket.

[deansheather]

JSON-RPC I imagine

[ianwalter]

Just wanted to chime in and mention that I think it would also be really cool if you could pass a flag and have the given folder open in a new tab a la window.open.

[shayne]

Having a code for opening files/folders would be incredibly helpful. I dug around the vscode repo and came up with a proof of concept that I'll use as a workaround for now. VSCODE_IPS_HOOK_CLI is in the environment already.

Curious what the status of this is, happy to help.

Example: opens a folder

const http = require("http");

const req = http.request(
  {
    socketPath: process.env["VSCODE_IPC_HOOK_CLI"],
    path: "/",
    method: "POST",
  }
);

req.on("error", (err) => console.error(err));
req.write(
  JSON.stringify({
    type: "open",
    folderURIs: ["/path/to/folder"],
    forceReuseWindow: true,
    // forceNewWindow: true
  })
);
req.end();

Example: opens a fle

const http = require("http");

const req = http.request(
  {
    socketPath: process.env["VSCODE_IPC_HOOK_CLI"],
    path: "/",
    method: "POST",
  }
);

req.on("error", (err) => console.error(err));
req.write(
  JSON.stringify({
    type: "open",
    fileURIs: ["/path/to/file.ext"]
  })
);

Interestingly using forceNewWindow with a fileURI doesn't work. This also doesn't address using -w for waiting on an editor.

Relevant source:
https://github.com/microsoft/vscode/blob/master/src/vs/workbench/api/node/extHostCLIServer.ts

[code-asher]

@shayne This is awesome. We haven't started work on this so if you're interested in submitting a PR that'd be fantastic. I imagine we'd just modify entry.ts to check if the env var exists, and if it does we'd do what you've posted otherwise it's business as usual.

[nhooyr]

v3.5.0 with VS Code v1.48.2 has been released, fixing this issue!