Allow reading from stdin

[jakearchibald]

This is very useful when working with the commandline, and to pass the result directly into the editor. It's especially useful for getting a file out of git's history, eg:

git show branch-name:path/to/file.js | code

FWIW, this works in Sublime.

[i5ting]

子实又骗+1

[joenoon]

Here is my workaround (I'm on OSX so might need to adjust accordingly):

create ~/bin/codestdin:

#!/bin/bash

f="$(mktemp -t vscode).diff"
tee "$f" > /dev/null
code -w "$f"
rm "$f"

Then run:

chmod +x ~/bin/codestdin
git config --global core.pager codestdin

Now git log, git show, git diff pipe correctly into vscode

[eoneill]

Similar to @joenoon's approach, I've added this to my bash profile to wrap the code command...

function code() {
  # reference to the original `code` command
  _code=$(which code)
  # if incoming stdin via a pipe...
  if [[ -p /dev/stdin ]] ; then
    tmpFile=$(mktemp -t stdin)
    tee "$tmpFile" > /dev/null
    $_code -w "$tmpFile" &
  else
    # otherwise, pass along any arguments to the original `code`
    $_code "$@"
  fi
}

definitely not flawless, but it works for my use cases (so far). e.g.

tree . | code
git diff | code
svn diff | code
code --help
code ./foo.bar

[mfriedenhagen]

For zsh you have to modify the function a bit and use whence, because which is a BUILTIN in zsh and will return the function itself:

function code() {
  # reference to the original `code` command
  local _code=$(whence -p code)
  # if incoming stdin via a pipe...
  if [[ -p /dev/stdin ]] ; then
    tmpFile=$(mktemp -t stdin)
    tee "$tmpFile" > /dev/null
    $_code -w "$tmpFile" &
  else
    # otherwise, pass along any arguments to the original `code`
    $_code "$@"
  fi
}

What does not work is something like code < /etc/hosts

[pr-yemibedu]

Hello,
@mfriedenhagen For using the redirect, does this express the intent of getting of copy of the file contents assigned to an anonymous file buffer? Would that be similar to cat /etc/hosts | code for intents sake?

I wonder if redirect management in the scripts are the only thing to care for that scenario? Thank you. Good day.

[mfriedenhagen]

hello @pr-yemibedu, yes this should be equivalent as as I know.

[atombender]

@bpasero Can we get some priority for this issue? It's been open since 2016 (that's 552 days!) and it's a bit ridiculous that VSCode still doesn't provide this extremely rudimentary shell interoperability.

[ghost]

+1

[bpasero]

Pushed a change to feed the contents of stdin to a file and have it open in VS Code (--wait is implied when doing so):

This currently works by trying to detect if stdin is connected to a TTY or not, which is a bit brittle. If someone spawns VS Code without terminal emulation we might wrongly assume that data is coming in via stdin and open a tmp file. If it turns out that there are too many regressions, I might have to add a startup argument (-s, --stdin) to explicitly enable this.

If someone has a better idea how to detect if data is flowing in via stdin let me know.

[jakearchibald]

This is great to see! Thanks so much!

If someone has a better idea how to detect if data is flowing in via stdin let me know.

Is Atom's implementation the same?

[bpasero]

@jakearchibald as far as I know, Atom does not support this.

[jakearchibald]

@bpasero huh, I really thought it did, but local tests (and atom/atom#11184) suggest not.

Anyway, thanks again!

[pr-yemibedu]

Hello,
@jakearchibald would you be kind enough to update your OP to note that Atom did and does not as of writing actively support this (probably just taking it out). There is the PR for them, but it is nice to have the proper perspective that VSCode is in the forefront of this kind of feature. Its no harm to stay, just misleading. Thank you. Good day.

[jakearchibald]

@pr-yemibedu done

[polothy]

Thanks for the feature, very nice. Just my 2 cents on feedback, the implied --wait seems unnecessary. EG: when I pipe to TextMate it gives me my prompt back. There might be other reasons though for having the wait that I'm not thinking about though.

Regardless, cheers and thanks for the work!

[bpasero]

@mrmark the calling process is waiting because it is not clear how long data is being sent to stdin. It could be that the editor is already opened but data is still flowing. A workaround on your side would probably to send the command to the background by appending "&" at the end?

[polothy]

Hrm, wasn't aware that was even possible. I feel like most commands I pipe complete then output is sent to the editor.

[bpasero]

A terminal can have a specific encoding set which my solution did not yet account for. I pushed a change to try a little bit of terminal encoding guessing but I think the solution is not ideal. If someone has a better idea (@Tyriar ?), let me know:

• Linux/macOS: use the output of running locale charmap as encoding
• Windows: use cp850 by default
• any OS: if you specify an environment variable VSCODE_CLI_ENCODING it will always win over the guessing

This will not help if you change the encoding of the terminal ad-hoc as that does not seem to cause any configuration change that the locale charmap command would detect.

On Windows I see the chcp command but the output of that command seems to be intertwined with human readable text and not just the encoding. If someone has a better idea for Windows, please speak up.