Bug#667904: RFS: mitlm/0.4-1 [ITP] -- MIT Language Modeling
Il 31/01/2013 20:10, Jakub Wilk ha scritto:
> * Giulio Paci <giuliopaci@gmail.com>, 2013-01-30, 03:27:
>> To improve the manpages I improved the command line help messages (1008_improve_command_line_help.patch)
>
> Doesn't this patch break ABI?
You are right, however upstream never provided shared libraries, we are still API compatible with upstream and the patch has been included upstream.
Can we break ABI in this case? Should we wait the first shared library released from upstream instead?
> Speaking of which, I had a look at the list of exported symbols, and it's kinda messy... Some symbols have very generic names. Upstream should consider putting them into a
> namespace.
I think I can work on this and have it included upstream.
>> 1007_escape_filename.patch
>> The latter fixes .bz2 handling and should work on Windows as well (although I have not tested it yet on a real Windows system).
>
> I would be surprised if decompression worked correctly, though I don't have access to a Windows system to test it.
>
> "^" is a cmd.exe escape character, but then the executed program does argument parsing on its own. It's usually done by the MSVC++ runtime:
> http://msdn.microsoft.com/en-us/library/ms880421.aspx
You are right, in fact I first implemented the command line parsing escape. Then I realized that I also needed cmd.exe escape. Then I guessed that I only needed cmd.exe
escape as ">" and "<" are breaking the command line. Testing on wine did not work, however testing on a real Windows proved that I was right. Stackoverflow
(http://stackoverflow.com/questions/11193691/batch-escaping-with-caret) also pointed out that "|" symbol requires double cmd.exe-style escaping.
So: the general case is a nightmare, but the way I implemented it should correctly work (and when I tested, it worked properly).
Bests,
Giulio.
Reply to: