toabctl / jiracli

Simple command line interface for Jira
GNU General Public License v3.0
152 stars 39 forks source link

Fix editor_get_text function #27

Closed torrancew closed 3 months ago

torrancew commented 8 years ago

On my OS X install, this function was never able to see the content inserted by my editor (vim). I'm unsure of why, specifically, but opening another File object against the path (after the editor exits) seems to work around the issue just fine.

toabctl commented 8 years ago

So have you saved the file in your editor before closing it?

torrancew commented 8 years ago

@toabctl Yes. (Obviously my patch requires that to happen, as well). I'm not sure if this is environmental, or what the root cause is, but am happy to help you debug it.

toabctl commented 8 years ago

Hm. It looks wrong to me to open a file twice. And this seems to work well for others. Any chance you debug this further to find the root cause of this?

torrancew commented 8 years ago

I've confirmed so far that I can not reproduce this on Linux. On my OS X box, this problem exists 100% of the time. I'll throw together a couple of simple, minimal test cases and try them out on the two, to see if I can reproduce this outside of the jiracli codebase.

P.S. I fully agree about the opening-a-file-twice thing. This is incredibly bizarre to me, but is the result of me spending a couple of hours debugging empty messages when using the -m option. I only have one OS X box, which is issued by work, and has a rather hefty set of things preconfigured (including numerous python libs pre-installed, etc), so I'll futz around with some virtualenvs as well, to see if I can figure out what on earth is causing this.

torrancew commented 8 years ago

Confirmed that this behavior only exists on my OS X workstation. Some troubling hints at a possible "why" lie in the docs for NamedTemporaryFile:

Whether the name can be used to open the file a second time, while the named temporary file is still open, varies across platforms (it can be so used on Unix; it cannot on Windows NT or later).

Here are the observations I've made thus far:

My current suspicion is that OSX's vim is doing something like overwriting the original file with a new one and invalidating the handle open in jiracli.

toabctl commented 8 years ago

@torrancew have you tried to set the EDITOR env var to use a different editor? Maybe that works? I don't have OS X to test it myself...

gerph commented 6 years ago

If the editor deletes and recreates the file named by the command line, then the python filehandle that was opened first will still point to the the old content, and whatever you write to the new file will not be read when you seek to the beginning. Re-opening the file is the correct solution if you're going to invoke an external editor.

I imagine that the following bash script will show up the issue that @torrancew was seeing:

#!/bin/bash
rm "$1"
echo "Hey, look, new content" > "$1"

Set that script as your $EDITOR variable and test and the problem of not reopening the file should be visible.

torrancew commented 3 months ago

Closing as stale