Am 02.06.2013 um 10:24 schrieb Georg Baum <georg.b...@post.rwth-aachen.de>:
> Uwe Stöhr wrote: > >> Am 01.06.2013 13:52, schrieb Stephan Witt: >> >>> But the documentation in filetools.h clearly states for quote_python: >>> /* >>> Quote for python. Use this if you want to store a filename in a python >>> script. Example: os << "infile = " << quoteName(filename) << '\\n'; >>> */ >>> >>> Here we have a command line argument for a python call to be parsed by a >>> shell or a shell similar QProcess call. We do not store the argument in a >>> python script. >>> >>> So it should be quote_shell. Or do I miss something? > > I would think the same, but I do not know the quoting works with the > QProcess based child process execution. Before QProcess was used, it was > simple: quote_python was only used for python scripts, like it is still > documented, and qutoe_shell for all file names which were given to the OS > shell. Now, there is a home made command line parser which translates some > artificial syntax in something that can be used by QProcess, and the > question is what this parser expects. > >> I also understand it that way but there must be a reason that this was >> once used. I am not an expert in this field and therefore would no make >> any action. > > git blame is your friend in such cases That's why I sent my mail to you too :) It seems so, you made the "mistake" to document the flags in the header. > , or trac: > http://www.lyx.org/trac/browser/lyxgit/src/support/Package.cpp?annotate=blame > . This tells you that Enrico introduced the quote_python argument in > http://www.lyx.org/trac/changeset/c73eb3497aa3e34b2536cf44071053d30d5c5166/lyxgit > > . Since Enrico is an expert in these things I would use a little bit of > cargo cult and keep the quote_python flag. Or better, ask him about the > reasons and document them. @Enrico: what do you say what should be done here? Stephan
