Compilation of code

[marcov]

What was the mantis item?

I didn't raise one for that "problem" because the solution is known: don't use quotes in parameters (http://bugs.freepascal.org/view.php?id=14446 Note 0030202).

That was a comment on a .commandline issue.

Since with "parameter" style quoting, the quoting is less important, this might not apply there.

It of course would only be simple (not quote if argument contains quotes), but it would be strange that a valid commandline couldn't be made in any way.

I hear you saying "no more quoting needed", but it should read "no more quoting allowed".

That's jumping to conclusions. All devels have their own "home" target on which they test the most. For Michael that is *nix.
[/quote]
Mmmh. I didn't insinuate anything. Just stated how it works on windows. According to above mantis link it is even how it is intended to work. 
[/quote]

That's not what I meant. I meant that you took a remark about something the wrong way. We do occasionally listen to reason.

Then it is very easy. Always execute over the shell, and stuff the whole commandline in one argument.

I wish it was that easy. Quoted arguments still need to be escaped according to the shell rules and I'm not 100% sure the modified environment is passed on correctly to the new shell on all the platforms that we are trying to support with fcpup.

True. That is the whole point, the whole "type and validate in the shell" principle is flawed.

[ludob]

That was a comment on a .commandline issue.

Since with "parameter" style quoting, the quoting is less important, this might not apply there.

OK. I'll create a mantis issue regarding the discrepancy between documentation and windows implementation for TProcess.Parameters.

True. That is the whole point, the whole "type and validate in the shell" principle is flawed.

I couldn't agree more.
What I'm saying is that the common case (external command + parameters) represents the vast majority of the usage cases and should and can be made as simple as possible for the programmer to call from a program. Once you get into shell internal commands, piping, tees, whatever shell extension, the programmer should take full responsability for the conversion to (kernel) api calls. IMHO the current TProcess is trying to find a compromise which doesn't satisfy both edges of the spectrum. The cross-platform objective for TProcess is obviously complicating things a lot.
 
For windows we are now in the situation that the programmer is expected to split the command line in executable and parameters + unquote parameters. TProcess will then maybequote all elements and serialize everything again before the call to the createprocess api. That is what I would call a loose-loose situation.

[marcov]

(I came looking for the processutils zip, and saw that there was a post that I missed.

Note that Mantis #22055 got reported in the meanwhile IMHO a pretty serious bug in tprocess wrt exitcodes on *nix.
)

That was a comment on a .commandline issue.

Since with "parameter" style quoting, the quoting is less important, this might not apply there.

OK. I'll create a mantis issue regarding the discrepancy between documentation and windows implementation for TProcess.Parameters.

(that turned out that Ludo used parameters.text to set the result, which only has the most basic quoting. I assumed he used parameters.add)

True. That is the whole point, the whole "type and validate in the shell" principle is flawed.

I couldn't agree more.
What I'm saying is that the common case (external command + parameters) represents the vast majority of the usage cases and should and can be made as simple as possible for the programmer to call from a program

If it is a "simple" case, it will work with .text

. Once you get into shell internal commands, piping, tees, whatever shell extension, the programmer should take full responsability for the conversion to (kernel) api calls. IMHO the current TProcess is trying to find a compromise which doesn't satisfy both edges of the spectrum. The cross-platform objective for TProcess is obviously complicating things a lot.

The latter for sure.  The quoting also complicated a lot, and lead to TProcess being broken in several releases, and it has been a festering wound for a decade now. Enough is enough.

And I really don't think using .add like syntax in common cases is that bad, though I would have prefered a more open array way to set it. 

For windows we are now in the situation that the programmer is expected to split the command line in executable and parameters + unquote parameters.

If he already has it, which is typically only during the transition time. 

TProcess will then maybequote all elements and serialize everything again before the call to the createprocess api. That is what I would call a loose-loose situation.

I honestly don't see the big problem.

[ludob]

(that turned out that Ludo used parameters.text to set the result, which only has the most basic quoting. I assumed he used parameters.add)

The test code uses parameters.text to set the first parameter only. All subsequent parameters are added with parameters.add. Using parameters.text for the first parameter is the equivalent of parameters.clear+parameters.add.
The code snippet from the test program 

Code: [Select]

  AProcess.Parameters.Text:='OPT="-g -gl"';
  AProcess.Parameters.Add('test');
produces the same result as

Code: [Select]

  AProcess.Parameters.Clear;
  AProcess.Parameters.Add('OPT="-g -gl"');
  AProcess.Parameters.Add('test');


[KpjComp]

Would something like ->

Code: [Select]

Function MaybeQuote(Const S : String) : String;
begin
  If (Pos(' ',S)<>0) and (Pos('"',S)=0) then
    Result:='"'+S+'"'
  else
    Result:=S;
end;

I would expect quoting something that contains quotes, unless some sort of escaping was used doesn't make any sense.  I think this would help in the OPT="-g -gl" and I don't think it would break anything.  If then you did want quotes within quotes, then you could always quote your parameter.

[marcov]

Code: [Select]

Function MaybeQuote(Const S : String) : String;
begin
  If (Pos(' ',S)<>0) and (Pos('"',S)=0) then
 

I'm exactly doing that, (as per discussion in the bugreport, #22040) except that I have copied the routine and called it maybequoteifnotquoted or so. This means that it can be easier set independently for parameters and executable name. I only run changed for the parameters now.

I'm somewhat limited in time till the weekend though. I hope to also resolve #22055 and include the "easy" procedures

[KpjComp]

I'm exactly doing that

Ah Ok, nice one.  Not used to discussions in multiple places.  I'll learn