Closed torrancew closed 3 months ago
So have you saved the file in your editor before closing it?
@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.
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?
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.
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:
vim
do not persist through.vim -n
does not impact this behavior. It persists regardless.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.
@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...
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.
Closing as stale
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.