Add a CLI_ARGS_LIST global variable

[pd93]

Description

When the CLI_ARGS variable was first introduced, Task only had string variables, so the variable was populated with a single string with shell quoted values. Since then we have introduced "any type" variables which means that arrays are now available.

Instead of As well as joining the args together, we should make them available in an array. This makes the individual arguments easier to access and loop through without the user having to do additional processing. If the user wants a single string, they are still able to use a string joining function. However, this also adds the flexibility for users to to process arguments first or choose a separator of their own.

Since this would be a breaking change, we should make this available as an experiment.

Related issues:

• Using for with CLI_ARGS unexpectedly splits arguments containing spaces #2138

Edit: Changed this issue from a proposed experiment to edit an existing variable to a feature request for a new variable. This means it is no longer a breaking change and no longer needs to be an experiment.

[task-bot]

This issue has been marked as an experiment proposal! 🧪 It will now enter a period of consultation during which we encourage the community to provide feedback on the proposed design. Please see the experiment workflow documentation for more information on how we release experiments.

[andreynering]

Hey @pd93,

I understand that having CLI_ARGS as an array would be very useful, but I think we should have them both: as a string and as an array.

Keeping the full string is useful because makes it extremelly easy to append to a command like docker {{.CLI_ARGS}}, which otherwise would have to be {{join " " .CLI_ARGS}}.

Also, keeping the existing as is means we wouldn't be breaking the compatibility unnecessarily.

What do you think?

[pd93]

@andreynering I'm not against having both. I think intuitively, I have always had the assumption that CLI_ARGS would be an array, but I do have several projects where I also use it directly as a string.

How would you handle naming?

[andreynering]

There are only two hard things in Computer Science: cache invalidation and naming things.

@pd93 That's the challenge 😂

I don't think I have a good name on top of my head at the moment. CLI_ARGS_LIST or CLI_ARGS_ARR look a bit verbose, but are possible candidates.

[trulede]

How about templating command to convert a "string argument list" to an "array of strings"? Then you could use that function whenever you need such a thing. You might even be able to use an existing function such as regexSplit.

[pd93]

@trulede This already exists. See splitArgs as described in my comment on the related issue.

[vmaerten]

Keeping the full string is useful because makes it extremelly useful to append to a command like docker {{.CLI_ARGS}}, which otherwise would have to be {{join " " .CLI_ARGS}}.

I totally agree with this. I use this a lot !

Having both seems the best solution

[trulede]

@trulede This already exists. See splitArgs as described in my comment on the related issue.

IMHO just use that templating function. It's easy enough, and more useful, if such things are left in the hands of users to process these things as they need.

[cjlarose]

@trulede I urge you to empathize with users, especially new users like myself. It's not at all obvious in any way that CLI_ARGS is a string containing the quoted shell arguments and not knowing that can introduce subtle bugs. As it stands, CLI_ARGS is a bit of a footgun, especially when combined with things like for:, which accept either an array or a string.

@andreynering I like the idea of having both and removing the need for a breaking change. It would mirror the behavior we see in POSIX shells, including Bash. From the Bash man page

*

Expands to the positional parameters, starting from one. When the expansion occurs within double quotes, it expands to a single word with the value of each parameter separated by the first character of the IFS special variable. That is, "$*" is equivalent to "$1c$2c...", where c is the first character of the value of the IFS variable. If IFS is unset, the parameters are separated by spaces. If IFS is null, the parameters are joined without intervening separators.

@

Expands to the positional parameters, starting from one. When the expansion occurs within double quotes, each parameter expands to a separate word. That is, "$@" is equivalent to "$1" "$2" ... If the double-quoted expansion occurs within a word, the expansion of the first parameter is joined with the beginning part of the original word, and the expansion of the last parameter is joined with the last part of the original word. When there are no positional parameters, "$@" and $@ expand to nothing (i.e., they are removed).

CLI_ARGS_LIST or CLI_ARGS_ARR both seem acceptable (certainly better than $@ 😂 )

[pd93]

The consensus here was to create a new variable, so I have updated #2140 and the title/description in this issue.