Change:
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: FWIW, this works in Sublime.
+1
Here is my workaround (I'm on OSX so might need to adjust accordingly): create ~/bin/codestdin: Then run: Now git log, git show, git diff pipe correctly into vscode
Similar to approach, I've this to my bash profile to wrap the command... definitely not flawless, but it works for my use cases (so far). e.g.
For you have to modify the function a bit and use , because is a BUILTIN in and will return the function itself: What does not work is something like
Hello, 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 for intents sake? I wonder if are the only thing to care for that scenario? Thank you. Good day.
hello yes this should be equivalent as as I know.
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.
+1
Pushed a change to feed the contents of stdin to a file and have it open in VS Code ( is implied when doing so): ! This currently works by 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 (, ) to explicitly enable this. If someone has a better idea how to detect if data is flowing in via stdin let me know.
This is great to see! Thanks so much! Is Atom's implementation the same?
as far as I know, Atom does not support this.
huh, I really thought it did, but local tests (and ) suggest not. Anyway, thanks again!
Hello, 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.
done
Thanks for the feature, very nice. Just my 2 cents on feedback, the implied 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!
the calling process is waiting because it is not clear how long data is being sent to . 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?
Hrm, wasn't aware that was even possible. I feel like most commands I pipe complete then output is sent to the editor.
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 ( ?), let me know: Linux/macOS: use the output of running as encoding Windows: use by default any OS: if you specify an environment variable 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 command would detect. On Windows I see the  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.

Discussion:
import { ParsedArgs } from 'vs/platform/environment/common/environment'; import product from 'vs/platform/node/product'; import pkg from 'vs/platform/node/package'; import * as paths from 'path'; import * as os from 'os'; <ins> import * as fs from 'fs'; </ins> import { whenDeleted } from 'vs/base/node/pfs'; <del> import { writeFileAndFlushSync } from 'vs/base/node/extfs'; </del> import { findFreePort } from 'vs/base/node/ports'; function shouldSpawnCliProcess(argv: ParsedArgs): boolean {

processCallbacks.push(child => { child.stdout.on('data', (data: Buffer) => console.log(data.toString('utf8').trim())); child.stderr.on('data', (data: Buffer) => console.log(data.toString('utf8').trim())); return new TPromise<void>(c => child.once('exit', () => c(null))); }); } <ins> // If we are running with input from stdin, pipe that into a file and // open this file via arguments. let isReadingFromStdin: boolean; try { isReadingFromStdin = !process.stdin.isTTY; // Via https://twitter.com/MylesBorins/status/782009479382626304 } catch (error) { // Windows workaround for https://github.com/nodejs/node/issues/11656 } let stdinFilePath: string; if (isReadingFromStdin) { let stdinFileError: Error; stdinFilePath = paths.join(os.tmpdir(), `stdin-${Math.random().toString(36).replace(/[^a-z]+/g, '').substr(0, 6)}.txt`); try { // Pipe into tmp file process.stdin.setEncoding('utf8'); process.stdin.pipe(fs.createWriteStream(stdinFilePath)); // Make sure to open tmp file argv.push(stdinFilePath); // Enable --wait to get all data argv.push('--wait'); args.wait = true; } catch (error) { stdinFileError = error; } if (args.verbose) { if (stdinFileError) { console.error(`Failed to create file to read via stdin: ${stdinFileError.toString()}`); } else { console.log(`Reading from stdin via: ${stdinFilePath}`); } } } </ins> // If we are started with --wait create a random temporary file // and pass it over to the starting instance. We can use this file // to wait for it to be deleted to monitor that the edited file

let waitMarkerError: Error; const randomTmpFile = paths.join(os.tmpdir(), Math.random().toString(36).replace(/[^a-z]+/g, '').substr(0, 10)); try { <del> writeFileAndFlushSync(randomTmpFile, ''); </del> <ins> fs.writeFileSync(randomTmpFile, ''); </ins> waitMarkerFilePath = randomTmpFile; argv.push('--waitMarkerFilePath', waitMarkerFilePath); } catch (error) {

// to get better profile traces. Last, we listen on stdout for a signal that tells us to // stop profiling. if (args['prof-startup']) { const portMain = await findFreePort(9222, 10, 6000); const portRenderer = await findFreePort(portMain + 1, 10, 6000); const portExthost = await findFreePort(portRenderer + 1, 10, 6000);

argv.push(`--prof-startup-prefix`, filenamePrefix); argv.push(`--no-cached-data`); <del> writeFileAndFlushSync(filenamePrefix, argv.slice(-6).join('|')); </del> <ins> fs.writeFileSync(filenamePrefix, argv.slice(-6).join('|')); </ins> processCallbacks.push(async child => {

await profiler.writeProfile(profileMain, `${filenamePrefix}-main.cpuprofile${suffix}`); await profiler.writeProfile(profileRenderer, `${filenamePrefix}-renderer.cpuprofile${suffix}`); await profiler.writeProfile(profileExtHost, `${filenamePrefix}-exthost.cpuprofile${suffix}`); }); }

// Complete when wait marker file is deleted whenDeleted(waitMarkerFilePath).done(c, c); <ins> }).then(() => { // Make sure to delete the tmp stdin file if we have any if (stdinFilePath) { fs.unlinkSync(stdinFilePath); } </ins> }); }