I recently encountered the behavior regarding " with ProcessStartInfo.Arguments. I was trying to pass an argument to a program while keeping " preserved.
#r "nuget: Fli"
open Fli
cli {
Exec "python"
// Arguments ["-c"; "print(\"abc\")"] // fails
Arguments ["-c"; "\"print(\"\"abc\"\")\""] // works
}
|> Command.execute
|> Output.throwIfErrored
|> Output.printTextI really appreciate this library as it means most of the time I don't even have to think about the underlying .NET APIs, but in this case I had a bit of trouble searching for the right answer - at first I thought it was PowerShell and then I thought maybe this library was doing something special.
This library has you pass in your arguments as a string[], which might cause the user to think some smart parsing is going on, when in fact it's just performing String.concat " ".
I don't think it's this library's fault and I fear changing the default method of handling "s wouldn't be productive, but because this wrapper somewhat "hides" the usage of ProcessStartInfo.Arguments, I think a simple beneficial addition would be to reference the behavior of "s with ProcessStartInfo.Arguments somewhere in the docs.
As an alternative suggestion, I think this might be a nice opportunity to introduce some smarter parsing through the usage of types.
I'm not sure would it would work with versioning, but it could look something like this:
type ArgumentType =
| Plain of string
| Wrapped of string
cli {
Exec "python"
Arguments [
Plain "-c"
Wrapped "print(\"abc\")" // duplicates `"`s and wraps with `"`
]
}Alternatively, the default operation of Arguments when taking a string[] could perform wrapping as this would not lead to a behavior change for the vast usage that is likely not using spaces in an argument at all (since right now it is no different than just passing one string with spaces (?)) and an additional Append operation could be used to append raw strings (though all this would also be a breaking change as well).
Even if no code change can be settled on, I think adding a short reference in the docs would be helpful as figuring this out took at least 30 minutes of my time.
I recently encountered the behavior regarding
"with ProcessStartInfo.Arguments. I was trying to pass an argument to a program while keeping"preserved.I really appreciate this library as it means most of the time I don't even have to think about the underlying .NET APIs, but in this case I had a bit of trouble searching for the right answer - at first I thought it was PowerShell and then I thought maybe this library was doing something special.
This library has you pass in your arguments as a
string[], which might cause the user to think some smart parsing is going on, when in fact it's just performingString.concat " ".I don't think it's this library's fault and I fear changing the default method of handling
"s wouldn't be productive, but because this wrapper somewhat "hides" the usage ofProcessStartInfo.Arguments, I think a simple beneficial addition would be to reference the behavior of"s withProcessStartInfo.Argumentssomewhere in the docs.As an alternative suggestion, I think this might be a nice opportunity to introduce some smarter parsing through the usage of types.
I'm not sure would it would work with versioning, but it could look something like this:
Alternatively, the default operation of
Argumentswhen taking astring[]could perform wrapping as this would not lead to a behavior change for the vast usage that is likely not using spaces in an argument at all (since right now it is no different than just passing one string with spaces (?)) and an additionalAppendoperation could be used to append raw strings (though all this would also be a breaking change as well).Even if no code change can be settled on, I think adding a short reference in the docs would be helpful as figuring this out took at least 30 minutes of my time.