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

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 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/2783d023-1ee5-42d7-9924-504bf5ed4a4fn%40googlegroups.com.