Version 0.11 of Text::VimColor is now on CPAN. Actually I had to do two releases because I'd forgotten to update the right ChangeLog file, and I wanted to get META.yml right. Oh, and the fact that this release is a year to the day after the last one is just a freaky coincidence.
While updating this stuff I deleted most of the old versions from CPAN, since there's no reason the mirrors should have to carry old crappy versions. They're still available from backpan if anyone needs them.
By the way, it turns out that people are actually using this module. There are three CPAN modules which use Text-VimColor, namely:
The most important change in 0.11 is better error reporting. There
have been lots of
failing tests
with version 0.09, but unfortunately they just say that vim
returned an exit code of whatever. I think most of them will probably
be due to the vim command not being installed or in the PATH, but
there's no way to know. The updated version redirects STDERR to a temporary
file before execing Vim. If the program fails (either exec()
fails because it couldn't find the program, or vim returns a
non-zero exit code) then the error message I die with will include the
contents of that file.
Previously I was closing STDERR completely before running vim,
because otherwise my terminal gets screwed up. That's why I need the
temporary file. I tried just plugging things together with a pipe,
but the terminal screwedness leaked through. This probably calls for
a pseudo-tty or something, but I've never got round to figuring out
how that stuff works.
No Windows support
I tried really hard to figure out how to get this thing working on Windows. In fact it works fine under Cygwin, but I just can't figure out how to do it without that emulation. I'm not even sure that any solution exists which doesn't involve a console window popping up and disappearing again. Hardly something you'd want to have plugged into your webserver. I don't even want to use this thing under Windows, but I suppose its a matter of pride to make it portable. Still, someone else will have to fight the good portability fight there.
I did learn something useful about Win32 programming, whether from
Perl or C. The API for creating processes is both baroque and
crack-fuelled. In Perl there's the
Win32::Process module.
The documentation isn't particularly detailed, and the tests don't
have anything for the Create function, but it seems that it should
be used something like this:
use Win32::Process; use Win32; sub ErrorReport { die Win32::FormatMessage( Win32::GetLastError(), ); } my $p; Win32::Process::Create( $p, 'C:\Vim\Vim64\vim.exe', 'vim frobber.pl', 0, NORMAL_PRIORITY_CLASS, '.', ) or die ErrorReport();
Notice that the command-line arguments are all in one string, so you have to quote anything that might contain dodgy characters. That's a feature of the underlying Win32 API CreateProcess function.
In fact, it's much worse than that. In the C API, either the program
name or the argument list can be NULL, and the rules for what to do in
that case are rather complicated. If the application filename is NULL
then it gets pulled out of the command-line arguments (where it will have to
be quoted if it contains a space). CreateProcess will kindly
stuff a ‘\0’ into your string to separate out the bits. If
the arguments are NULL,
then they get pulled out of the filename string. Depending on where the
filename comes from it gets searched for in different ways. If it comes
from the arguments string, and doesn't contain a path, then
it gets searched for in %PATH%, although first Windows looks for it in
some other places.
I've learnt a new appreciation for the simplicity of
fork/exec.