@cpattr fails to evaluate list arguments resulting in potentially unexpected behavior

[brazilofmux]

Original issue 663 created by brazilofmux on 2011-06-10T23:13:43.000Z:

Running MUX 2.10.0.7 # 1 [BETA], LBUF size of 32000.

Do this:

> @va %!=hi
> @cpattr %!/va=%!/vb
I don't see that here.

But do this:
> @cpattr #!/va=# 2/vb
Set.

I'd expect these to lead to the same result: The attribute is copied successfully.

Firstly, it seems strange to me that do_cpattr in set.cpp doesn't use parse_attrib unless it is the intention to move away from parse_attrib and to attr_info, however I'm not clear on what the useful semantic differences are in the two methods. (do_cpattr is the only place attr_info instantiation is used to process obj/attr pairs)

Although the cause of this behavior seems to be the following:
parse_arglist strips out EV_EVAL from the argument flags because that's generally the desired -reasonable- behavior.

Variable arguments tend to be new-object building commands or special evaluating commands (like @verb and @switch). The problem is that @cpattr is made to be used on already-existing objects -- objects which may be easier to reference with code evaluation. (e.g. ex gfo(), @cpattr gfo()/f.somefunc=gfo()/f.anotherfunc, etc...)

Ultimately, @cpattr just feels like an underdeveloped command. It's more useful for coders than builders, I'd think, and coders should know roughly how evaluation works and use it to their advantage -- which isn't possible right now without double-evaluation (e.g. @fo %!=@cp %!/va=%!/vb)

Admittedly, this isn't exactly a high priority problem (if it is a problem), however it might be quick to fix if there's similar code elsewhere to yank into do_cpattr.