Re: "commands: arglist" mismatch between behaviour and documentation?

Glad to hear! Thanks for sharing your solution with the clever use of 
maplist.

On Wednesday, September 20, 2023 at 12:08:10 PM UTC+2 
[email protected] wrote:

> Lars and Mike,
>
> Thanks for your replies on this.  Appreciated and useful!
>
> Given an incoming, pre-existing "@(lines)" slist that includes elements 
> which potentially contain embedded spaces, and following Lars' useful 
> suggestion, I have inserted:
>
>   vars:
>     any::
>       "lines_q" slist => maplist("'$(this)'", "@(lines)");
>
> which simply puts additional quotes around each.  I then use that new 
> "@(lines_q)" from that point onwards.
>
> (As Mike hints, this isn't a full, general-purpose solution.  But for the 
> present it looks sufficient in this particular, relatively simple, 
> instance.)
>
>
> -- David Lee
>
> On Friday, 15 September 2023 at 17:06:31 UTC+1 [email protected] wrote:
>
>> Thanks, Lars!
>>
>> Side note about nested quoting, probably the cleanest and most flexible 
>> syntax I've seen for nested quoting when it would otherwise get really 
>> hairy, is that used by Postgres: 
>> https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING
>>
>> --Mike Weilgart
>>
>> On Fri, Sep 15, 2023 at 2:28 AM 'Lars Erik Wik' via help-cfengine <
>> [email protected]> wrote:
>>
>>> Hi all
>>>
>>> Thanks for shedding a light on this issue again. I've linked the issues 
>>> and pushed the CFE-2724 ticket to the top of the backlog. As a temporary 
>>> workaround you can use nested quoting, e.g.:
>>>
>>> ```
>>> $ cat ~/test.cf
>>> bundle agent __main__
>>> {
>>>   files:
>>>     "/tmp/test.py"
>>>       content => "import sys; print(*(arg for arg in sys.argv), 
>>> sep='\n')";
>>>   commands:
>>>     "/usr/bin/python3 /tmp/test.py"
>>>       args => "two `three four`",
>>>       arglist => { "five", "'six seven'" };
>>> }
>>> $ /var/cfengine/bin/cf-agent -Kf ~/test.cf 
>>>   notice: Q: "...in/python3 /tmp": /tmp/test.py
>>> Q: "...in/python3 /tmp": two
>>> Q: "...in/python3 /tmp": three four
>>> Q: "...in/python3 /tmp": five
>>> Q: "...in/python3 /tmp": six seven
>>> ```
>>>
>>> On Friday, September 15, 2023 at 6:01:50 AM UTC+2 [email protected] 
>>> wrote:
>>>
>>>> Hi David,
>>>>
>>>> I thought this sounded familiar, and indeed, I reported the same bug 
>>>> five years ago!  https://northerntech.atlassian.net/browse/CFE-2869
>>>>
>>>> And it was reported a year before that as well: 
>>>> https://northerntech.atlassian.net/browse/CFE-2724
>>>>
>>>> And David, I see that you've now successfully reported the issue as 
>>>> https://northerntech.atlassian.net/browse/CFE-4253, also.
>>>>
>>>> To Northern Tech: I suggest that the code should be fixed for a future 
>>>> CFEngine version, AND that the documentation should be fixed for all 
>>>> existing CFEngine versions.  Should be modified to better describe what the 
>>>> code actually does, and then a note should be inserted in a little text box 
>>>> for the benefit of those rereading the docs who've read it before, saying 
>>>> something like, "NOTE: This documentation previously implied that the 
>>>> elements of arglist were each treated as separate arguments and could 
>>>> contain spaces or quotes; however the behavior of the code did not match 
>>>> this documentation, so the documentation has been updated.  A future 
>>>> CFEngine version may modify this behavior; see (link) for the bug tracking 
>>>> info."
>>>>
>>>> Or just quietly update the doc to be more precisely descriptive, since 
>>>> it doesn't actually *say* how the arglist is currently processed, it just 
>>>> implies it with the "particularly useful" statement.
>>>>
>>>> The documentation fix should be fairly trivial and I submit there's 
>>>> really no good reason to leave inaccurate documentation there to trip 
>>>> people up, even if the coding fix takes a while to prioritize and 
>>>> accomplish.
>>>>
>>>> ...Hmm, interesting, I think there is currently no way to have explicit 
>>>> control over how CFEngine handles the whitespace splitting in a commands 
>>>> promise...maybe an attribute for this could be added, with the default set 
>>>> to be the current behavior, for backward compatibility.  Maybe call it 
>>>> "argsplitting" and default it to "whitespace" (IF that is an accurate 
>>>> description of current code behavior; I think it is), and have another 
>>>> option "none" which would result in *args* being treated as one single 
>>>> argument; and *arglist* being treated as exactly as many arguments as 
>>>> appear as elements in that list.
>>>>
>>>> Best,
>>>> --Mike Weilgart
>>>> On Thursday, September 14, 2023 at 7:26:03 AM UTC-7 
>>>> [email protected] wrote:
>>>>
>>>>> I appear no longer to have login access to be able to report issues.  
>>>>> (Previous issues with my involvement include CFE-3020, CFE-1655, CFE-2908, 
>>>>> etc.)  I'm trying to regain that access, but it is not proving easy!  If 
>>>>> that can be restored then I can report the issue.
>>>>>
>>>>> Otherwise, could you log the issue for me?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -- David Lee
>>>>> On Wednesday, 13 September 2023 at 14:55:30 UTC+1 
>>>>> [email protected] wrote:
>>>>>
>>>>>> On Wed, 2023-09-13 at 06:38 -0700, [email protected] wrote: 
>>>>>> > Using 3.18.5 community edition on RHEL9; also 3.15 on RHEL7 and 
>>>>>> RHEL8 
>>>>>> > 
>>>>>> > Documentation 
>>>>>> https://docs.cfengine.com/docs/3.18/reference-promise-types-commands.html 
>>>>>> gives the example: 
>>>>>> > ------------------------------------------------- 
>>>>>> > commands: "/bin/echo one" args => "two three", arglist => { "four", 
>>>>>> "five" }; 
>>>>>> > So in the example above the command would be: 
>>>>>> >  /bin/echo one two three four five 
>>>>>> > ------------------------------------------------- 
>>>>>> > 
>>>>>> > It also states:------------------------------------------------- 
>>>>>> > That's particularly useful when there are embedded spaces and 
>>>>>> quotes in your arguments... 
>>>>>> > ------------------------------------------------- 
>>>>>> > 
>>>>>> > So I'm trying to build something, specifically requiring that 
>>>>>> "embedded spaces" claim.  But I hit a problem, so strip it down to a 
>>>>>> proof-of-concept script: 
>>>>>> > ------------------------------------------------- 
>>>>>> > #! /bin/bash 
>>>>>> > echo "argcount: $#" 
>>>>>> > for (( i=1 ; i<=$#; i++)) 
>>>>>> > do     
>>>>>> >   echo "${i}:${!i}" 
>>>>>> > done 
>>>>>> > ------------------------------------------------- 
>>>>>> > 
>>>>>> > At the command line I verify the script: 
>>>>>> > ------------------------------------------------- 
>>>>>> > $ ./modules/printargs A B "C with spaces" D 
>>>>>> > argcount: 4 
>>>>>> > 1:A 
>>>>>> > 2:B 
>>>>>> > 3:C with spaces 
>>>>>> > 4:D 
>>>>>> > $ 
>>>>>> > ------------------------------------------------- 
>>>>>> > (Four arguments, the third being three words with embedded spaces.) 
>>>>>> > 
>>>>>> > I then run it from within our CFEngine framework: 
>>>>>> > ------------------------------------------------- 
>>>>>> >   commands: 
>>>>>> >     any:: 
>>>>>> >       "$(gcom.modulesdir)/printargs" 
>>>>>> >         arglist => { "A", "B", "C with spaces", "D" }; 
>>>>>> > ------------------------------------------------- 
>>>>>> > 
>>>>>> > But instead of receiving four arguments, it receives six: here's 
>>>>>> the CFE "inform" output: 
>>>>>> > ------------------------------------------------- 
>>>>>> >     info: Executing 'no timeout' ... '[...]/modules/printargs A B C 
>>>>>> with spaces D' 
>>>>>> >   notice: Q: ".../printargs A B ": argcount: 6 
>>>>>> > Q: ".../printargs A B ": 1:A 
>>>>>> > Q: ".../printargs A B ": 2:B 
>>>>>> > Q: ".../printargs A B ": 3:C 
>>>>>> > Q: ".../printargs A B ": 4:with 
>>>>>> > Q: ".../printargs A B ": 5:spaces 
>>>>>> > Q: ".../printargs A B ": 6:D 
>>>>>> >     info: Last 7 quoted lines were generated by promiser 
>>>>>> > ------------------------------------------------- 
>>>>>> >  That useful "embedded spaces" claim in the documentation seems to 
>>>>>> be being ignored. 
>>>>>> > 
>>>>>> > Is the bug/problem: 
>>>>>> >  * in the code 
>>>>>> >  * or in the documentation 
>>>>>> >  * or in my interpretation of the documentation 
>>>>>> > Help appreciated 
>>>>>> Definitely looks like a bug in the CFEngine code to me. I'm just 
>>>>>> surprised there's no failing test 
>>>>>> for this. Please report the issue at 
>>>>>> https://northerntech.atlassian.net/browse/CFE 
>>>>>>
>>>>>> Thanks! 
>>>>>>
>>>>>> -- 
>>>>>> Vratislav 
>>>>>>
>>>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "help-cfengine" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/help-cfengine/70qc5E83BMA/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> [email protected].
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/help-cfengine/7f369e0e-4b13-460a-a613-5538835a628dn%40googlegroups.com 
>>> <https://groups.google.com/d/msgid/help-cfengine/7f369e0e-4b13-460a-a613-5538835a628dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/2b699151-889d-4533-925f-9369ca04e11cn%40googlegroups.com.