Vscode: Every time I launch VS Code, it starts with code-stdin-randomchars.txt file

[benbuch]

Every time I launch VS Code, it starts with code-stdin-randomchars.txt file and not the welcome screen
the only way i can stop this from happening is by opening code from terminal with the new window flag.
i have no idea, why this started happening.

• VSCode Version: Code 1.19.0 (816be6780ca8bd0ab80314e11478c48c70d09383, 2017-12-14T09:56:48.842Z)
• OS Version: Linux x64 4.14.5-1-ARCH
  

  - Extensions: none

[crumblingstatue]

Looks like the same issue as #40264.
Also related: #39728, #39357

I think this could be fixed if code.sh would just not try to open stdin when it's not run from a tty.

[crumblingstatue]

I'll try to summarize this issue the best I can:

The problem

1. When running the code binary from a terminal on Linux, you get a "cannot set terminal process group (-1): Inappropriate ioctl for device" message, and code doesn't detach from the terminal. This is annoying for use through a terminal. I also believe that running the code command in itself doesn't support the new "pipe to vscode" feature, but that's beside the point.

2. To solve this (?, or for some other reasons too), a code.sh is also distributed, which is the recommended way to use vscode from the terminal.

3. Having to remember and use two different commands for two different use cases (code when launching outside of a terminal, code.sh when launching inside a terminal) is annoying, so some distributions (https://aur.archlinux.org/packages/visual-studio-code/ is an example) just ship code, which is a symbolic link to code.sh. code.sh seemed to work fine for both cases (using with, and without terminal), until...

4. The new "pipe to vscode" feature broke using code.sh outside of a terminal. It tries to read from stdin, even if it wasn't launched from a terminal.

Possible solutions

• Somehow fix code.sh so it doesn't try to read from stdin when not launched in a terminal. This might be difficult, because it might not be possible to distinguish between "not inside a tty" and "inside a tty, but stdin is a pipe".

• Only read from stdin when a - argument is present. This is common practice for many command line applications that accept either a file, or stdin.

• Explicitly state that code.sh is not supported for use outside of a terminal, and distributions should either:

  • always ship code as itself. Again, this means that launching code from the terminal will present that annoying ioctl message, and won't detach from the terminal. And this also might not support the new "pipe to vscode" feature, so users will have to remember to use code.sh when using vscode from a terminal.
  • ship code as symlink to code.sh, which supports proper terminal use, but doesn't support use outside of a terminal. This might not be too much of a problem, because distributions could just ship a .desktop file for non-terminal use, that launches the code binary. However, it's a popular "workflow" among *nix users to ignore .desktop files completely, and use launchers like dmenu and rofi to launch commands directly. This might not be a valid concern for vscode developers, but I just want to state that this can trip up some *nix users, as this, and other issues (#40264, #39728, #39357) show.

• (Just throwing it out there) "fix" the code binary so it:

  • Doesn't have the annoying ioctl error message when launching
  • Detaches from terminal after launching
  • Supports the "read from stdin" feature, but doesn't try to read from stdin when not piped to.

  If this could be achieved, there would be no need for code.sh at all, but maybe I'm wrong.

[miles82]

I have the same issue when i start code from git bash on Windows 10. It opens code-stdin-xyz.txt and hangs the terminal. If I open it directly from Windows (icon or cmd) it works OK (opens the last used folder).

• VSCode Version: Code 1.19.0 (816be6780ca8bd0ab80314e11478c48c70d09383, 2017-12-14T12:06:44.860Z)
• OS Version: Windows_NT ia32 10.0.16299

[bpasero]

I am not convinced that it is hard for (non-tty) "launchers" to use the code binary instead of the code shell script. Imho any component that launches VS Code can easily switch to running the binary directly and since there is no terminal attached you will not see any output that you would normally get ("cannot set terminal process group (-1): Inappropriate ioctl for device").

I just did an experiment with ST by running "subl" (their CLI launcher) from a node.js script that would launch ST without tty and ST does not even start. So it seems there are other tools that face similar challenges and just ignore this problem?

However, the fact that you can no longer run VS Code from the GIT bash is quite bad. Given that we might have to require to add a "-" to the CLI to read from stdin. I would still want to educate users though if possible. E.g. ideally if a user does this:

ps aux | grep code | code

Ideally we could print a message to the console to indicate that in order to read from stdin, you have to run:

ps aux | grep code | code -

I guess I could try to read from stdin and if I see data flowing in after some timeout I can print this message.

[bpasero]

Btw a workaround for the git bash to be functional again is to pick this option from the installation:

[bpasero]

We now only read from stdin when the command line has a "-" at the end (e.g. ps aux | grep code | code -). If you forget to supply the extra "-" we will inform you from the command line:

[saelfaer]

great, a breaking change in a patch version.
couldn't get a better Christmas present

good thing it was fixed though.

[greeneg]

Can we please get the dash (-) changed to double-dash (--), or at minimum alias one to the other? This fits the normal (at least GNU) paradigm of command line flags better.

[crumblingstatue]

Can we please get the dash (-) changed to double-dash (--), or at minimum alias one to the other? This fits the normal (at least GNU) paradigm of command line flags better.

Isn't -- usually used to to separate options from positional arguments?

That's different than -, as used here, which stands for "standard input" in a context where a filename is expected.