Indeed, the rules for quoting and parsing command lines are considerably
different even in different context on the same OS (Windows) and so
successfully building a command line to be run requires detailed knowledge
of the context in which it will be evaluated.
Unix systems are at least relatively consistent but even then there are
edge-cases such as differently-set IFS environment variables to be worried
about.
I wrote a library that tries to deal with various different situations that
I had to interact with in some software (not open source) that did
automatic provisioning of virtual machines via SSH or local virtual console
and physical machines accessed via network serial terminals:
https://pkg.go.dev/github.com/apparentlymart/go-shquot@v0.0.1/shquot
In the docs for that I tried to be very explicit about the behavior and
limitations of each of the functions so that it's hopefully possible to
understand what is the most appropriate combination of transforms for any
particular context. Even then, there are plenty of exceptions where things
might not work quite as expected. (I would not be surprised to learn that
this code still has bugs and edge cases even though I've used it in a
number of situations already!)
There's considerable subtlety and uncertainty in all of this. The situation
on Windows is particularly fraught. I think this sort of thing is better
handled in third-party libraries than in the standard library so that each
library can be tailored to whatever requirements it has, rather than
over-promising as being a general solution.
On Sunday, November 6, 2022 at 9:12:07 PM UTC-8 kra...@skepticism.us wrote:
> On Sun, Nov 6, 2022 at 8:48 PM 'Christian Stewart' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> There have been several discussions about shellquote in go-nuts in the
>> past:
>>
>> https://github.com/kballard/go-shellquote
>> https://github.com/gonuts/go-shellquote
>>
>> I've found it necessary to use both Split and Join in some cases when
>> working with exec.Command.
>>
>> This seems like the type of thing that ought to be part of the stdlib,
>> has there been any consideration towards including it or a similar
>> implementation?
>>
>> This is useful for processing os.Args especially in CLI or emulated shell
>> environments.
>>
>
> No, IMHO, because such quoting is OS specific. For example, the quoting
> for UNIX and Windows in this context are different. Furthermore, given the
> vagaries of the POSIX shell standard I am skeptical that either of the
> projects you linked to correctly manipulates such strings in every case.
>
> It would help if you provided a concrete example of the problem you need
> help with.
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/aeb650a3-f9d3-427e-aebf-dc945e29ca75n%40googlegroups.com.
