Unify string subcommand parameter passing behavior

[mqudsi]

I always mix up how to pass characters to string trim and string split, both of which ostensibly could have default values (whitespace and either whitespace or new lines, respectively) and allow for a custom delimiter/value to be specified. One requires -c __ to specify the value, the other takes __ as a parameter directly. (There may be other subcommands similarly affected).

While at it, both of these actually could (and should, imho) support multiple arguments, e.g. "trim any of the following" and "strip any of the following", respectively. One of them errors out if multiple are provided, the other silently discards the extra argument.

Forutnately, in the case of these two subcommands, I believe they could both be extended to support both sets of behavior without any conflict with existing code (but I could be wrong).

I leave it to the reader to recall which of the descriptions above apply to which of these subcommands 😄.

[faho]

So, what's your proposal?

Note that either requiring a --delimiter for split or not requiring -c for trim are breaking changes. The former would break every single current use of split, the latter all uses of trim that pass arguments on the commandline.

I'm imagining the reason that trim doesn't use the first argument as the characters to trim is because it's mostly used to trim "whitespace", and any other characters are secondary. split on the other hand is used to split on something. I'd imagine a good default for that would be whitespace as well.

[zanchey]

Yes, the current behaviour doesn't seem all that surprising to me. An optional --delimiter for split could be added without affecting compatibility though.

[mqudsi]

@faho not suggesting any required changes, merely adding -c to both and letting trim take a trailing argument as an implicit -c.

[faho]

letting trim take a trailing argument as an implicit -c.

This would need to be quite carefully done if we want to keep compatibility. One possibility would be to only use it in argv iff the strings are passed via stdin.

Because otherwise:

string trim ' first' 'second '

would print econd.

adding -c to both

One difference between split and trim is that split takes a string delimiter, while trim's -c takes a character set. The difference being that split looks for the entire thing in one piece, while trim looks for each character in it separately. Considering that -c is short for --chars, do we want string split -c bar to:

• Use it as a character set, checking b, a and r, unlike existing split behavior?

or to

• Use it as a string, looking for bar in one piece, acting unlike the option says.

Or do we want to add another option to both that uses its argument as a string?