[Lazarus] Parsing command line options

Marco van de Voort marcov at stack.nl
Tue Sep 11 12:30:13 CEST 2012

On Mon, Sep 10, 2012 at 05:39:20PM +0200, michael.vancanneyt at wisa.be wrote:
> The main problem is the Windows API, which has only 1 string in which 
> to pass all command-line options.

IMHO this is not a Windows problem. 

There are two problems as I see them, one being that APIs only accept one
cleanly normalized form (be it as an array of arguments, or with exact
quoting rules), and that the "common" notation must be rewritten to those
rules.  This always needs some filtering and cleaning.

The second problem is that the "common" everything on one line notation is
OS specific, and even within an OS is fragmented between shell and API
rules.  (windows too, shellexecute <> createprocess, though the differences
are smaller)

This significantly increases the need for rewriting (one could argue that 
notation like --xxx="yy  xx" is an unixism) that is not strictly necessary.

As already said in similar discussions on the FPC maillist: nearly _every_
FPC version had changes in quoting and new bugs/featurerequests.  In
2.0.x/2.2.x times, some of those even have been a problem for lazarus.

Most of these changes also have not been minor, and quite often newly
introduced bugs have been fixed just barely in time, between the RC and

Already in 1.9.2, executeprocess() was added that fixed this issue for
the more procedural interface. All the older versions have slowly been
deprecated and removed (a still ongoing process)

So in short, the tprocess maintainers (mostly Michael and me) have said
enough is enough. The primary, supported way to hand parameters to tprocess
is to deliver them separated, and cleansed of unnecessary quoting. This
mostly fixes the second problem. The first problem is more minor. (and can
often be fixed by simply stripping quoting before passing it.

We hope this will allow for a more stable interface, and I heartily
recommend it for any non-trivial use.

More information about the Lazarus mailing list