Question

I’m trying to implement a replacement for raw_input() that would use a configurable text editor like vim as the interface to to the user.

The ideal workflow would be like this:

1. Your python script is running, and makes a call to my_raw_input().
2. Vim (or emacs, or gedit, or any other text editor) opens w/ a blank document
3. You type some text into the document, then save and exit
4. The python script resumes running, with the contents of the file as the return value of my_raw_input().

If you’re familiar with git, this is the experience when using git commit, where the editor is configured via core.editor. Other utilities like crontab -e also do this.

Ultimately, I would like this my_raw_input() function to also take an optional string w/ the default input contents, which the user could then edit.

Research so far

• os.exec replaces the current process with the editor command, but does not return. Ie, your python script exits when vim starts.
• popen does not start the child process interactively, there is no user interface displayed.
• vim has a - command-line parameter to read from stdin, but nothing to write to stdout with :w.
• I took a look at the code for git, which I can’t follow at all.

Is this possible?

Edit

Good answers so far. I also found the mecurial code that’s doing the same thing. I also came up with an example that works from looking at the crontab code, but it looks like it’s needlessly complicated compared to some of the responses.

#!/usr/bin/python
import os
import tempfile


def raw_input_editor(default=None, editor=None):
    ''' like the built-in raw_input(), except that it uses a visual
    text editor for ease of editing. Unline raw_input() it can also
    take a default value. '''

    editor = editor or get_editor()

    with tempfile.NamedTemporaryFile(mode='r+') as tmpfile:

        if default:
            tmpfile.write(default)
            tmpfile.flush()

        child_pid = os.fork()
        is_child = child_pid == 0

        if is_child:
            os.execvp(editor, [editor, tmpfile.name])
        else:
            os.waitpid(child_pid, 0)
            tmpfile.seek(0)
            return tmpfile.read().strip()


def get_editor():
    return (os.environ.get('VISUAL')
        or os.environ.get('EDITOR')
        or 'vi')


if __name__ == "__main__":
    print raw_input_editor('this is a test')

Answer 1

You write the data to a temporary file, and then read it when the editor returns. If you run git commit you’ll notice that git is doing the same thing.

There is no extra step to starting a program interactively, as long as the child process has stdin and stdout wired to a terminal it will be interactive.

There is a gotcha with working with editors — many of them will save files by writing a temporary file in the same directory and moving it over the old file. This makes the save operation completely atomic (ignoring that the power might go out) but means that we have to re-open the temporary file after the editor runs, since our old file handle will point to a file that is no longer part of the file system (but it’s still on disk).

This gotcha means that we can’t use TemporaryFile or NamedTemporaryFile, we have to use a lower-level facility so we can close the file descriptor and re-open the file without deleting it.

import tempfile
import subprocess
import os

def edit(data):
    fdes = -1
    path = None
    fp = None
    try:
        fdes, path = tempfile.mkstemp(suffix='.txt', text=True)
        fp = os.fdopen(fdes, 'w+')
        fdes = -1
        fp.write(data)
        fp.close()
        fp = None

        editor = (os.environ.get('VISUAL') or
                  os.environ.get('EDITOR') or
                  'nano')
        subprocess.check_call([editor, path])

        fp = open(path, 'r')
        return fp.read()
    finally:
        if fp is not None:
            fp.close()
        elif fdes >= 0:
            os.close(fdes)
        if path is not None:
            try:
                os.unlink(path)
            except OSError:
                pass

text = edit('Hello, World!')
print(text)

The Git sample code is so complicated because it’s not using a nice high-level library like Python’s subprocess module. If you read the subprocess module source code, big chunks of it will look like the linked Git source code (except written in Python instead of C).