Having a conversation in two places at once is annoying, and I think this forum is much more valuable than Reddit, so I'll reply here:
> Oh. Awesome! Thank you. I have been traveling with the family for the > holidays so haven’t been checking. I’ll test it as soon as I can. Knew I > should have been using a tempfile, but I didn’t bother since I figured the > issue with the Error was unrelated. > > Do you know what is different about ‘execCmd’ that makes this work? It's first important to understand how Unix terminals and [pipes](https://en.wikipedia.org/wiki/Pipeline_\(Unix\)) operate. A pipe is a simple one-directional stream of text, mainly designed for programs that dump output and exit, like `dmesg | less`. Running `vim | less` gives you a warning, "output not to a terminal", and then it's a mess until you exit. Vim is an interactive program that clears the screen, moves the cursor around, and interacts with the user until s\he exits. Vim can even let you edit multiple files, split the screen, show auto-suggest drop-downs, run other programs, etc. (Same for emacs, nano, mc, etc.) What it sends to stdout is a hodgepodge of strings and ANSI / [control characters](https://en.wikipedia.org/wiki/Control_character). Vim doesn't dump the full file(s) to stdout, but to the filesystem when you save. Nim's [execCmdEx](https://nim-lang.org/docs/osproc.html#execCmdEx%2Cstring%2Cset%5BProcessOption%5D) runs the process as a pipe, captures any output it sends, and waits for it to terminate - which Vim, being an interactive program, doesn't do until it gets user keystrokes for quitting. [execCmd](https://nim-lang.org/docs/osproc.html#execCmd%2Cstring) runs the program normally (manual says: "standard input, output, error streams are inherited from the calling process"), so that it can interact with the screen until it terminates.
