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

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

Closed
benbuch opened this Issue Dec 16, 2017 · 9 comments

Comments

Projects
None yet
7 participants
@benbuch

benbuch commented Dec 16, 2017

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 (816be67, 2017-12-14T09:56:48.842Z)
  • OS Version: Linux x64 4.14.5-1-ARCH
  • Extensions: none

@vscodebot vscodebot bot added the workbench label Dec 16, 2017

@crumblingstatue

This comment has been minimized.

Show comment
Hide comment
@crumblingstatue

crumblingstatue Dec 16, 2017

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 commented Dec 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@crumblingstatue

crumblingstatue Dec 16, 2017

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.

crumblingstatue commented Dec 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@miles82

miles82 Dec 16, 2017

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 (816be67, 2017-12-14T12:06:44.860Z)
  • OS Version: Windows_NT ia32 10.0.16299

miles82 commented Dec 16, 2017

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 (816be67, 2017-12-14T12:06:44.860Z)
  • OS Version: Windows_NT ia32 10.0.16299

@bpasero bpasero added this to the December 2017/January 2018 milestone Dec 17, 2017

@bpasero

This comment has been minimized.

Show comment
Hide comment
@bpasero

bpasero Dec 17, 2017

Member

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.

Member

bpasero commented Dec 17, 2017

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 bpasero added the candidate label Dec 17, 2017

@bpasero

This comment has been minimized.

Show comment
Hide comment
@bpasero

bpasero Dec 17, 2017

Member

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

image

Member

bpasero commented Dec 17, 2017

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

image

@bpasero bpasero modified the milestones: December 2017/January 2018, November Recovery 2017 Dec 18, 2017

@bpasero bpasero added the bug label Dec 18, 2017

@bpasero bpasero closed this Dec 18, 2017

@bpasero

This comment has been minimized.

Show comment
Hide comment
@bpasero

bpasero Dec 18, 2017

Member

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:

image

Member

bpasero commented Dec 18, 2017

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:

image

@saelfaer

This comment has been minimized.

Show comment
Hide comment
@saelfaer

saelfaer Dec 26, 2017

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

good thing it was fixed though.

saelfaer commented Dec 26, 2017

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

good thing it was fixed though.

@gregvanl gregvanl changed the title from Every time i lunch code it starts with code-stdin-randomchars.txt file to Every time i launch code it starts with code-stdin-randomchars.txt file Dec 27, 2017

@gregvanl gregvanl changed the title from Every time i launch code it starts with code-stdin-randomchars.txt file to Every time I launch code it starts with code-stdin-randomchars.txt file Dec 27, 2017

@gregvanl gregvanl changed the title from Every time I launch code it starts with code-stdin-randomchars.txt file to Every time I launch VS Code, it starts with code-stdin-randomchars.txt file Dec 27, 2017

@greeneg

This comment has been minimized.

Show comment
Hide comment
@greeneg

greeneg Jan 16, 2018

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.

greeneg commented Jan 16, 2018

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

This comment has been minimized.

Show comment
Hide comment
@crumblingstatue

crumblingstatue Jan 16, 2018

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.

crumblingstatue commented Jan 16, 2018

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.

@vscodebot vscodebot bot locked and limited conversation to collaborators Feb 1, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.