Thanks for your input, Rainer!
> Just a few minor comments:
>
> * 3.1 scan-wifi
>
> How about adding a -w (wide, like /usr/ucb/ps w) switch to display all
> fields, allowing the line to become wider than 80 columns? This is more
> convenient than having to specify all field names with -o.
We were planning to support "-o all" to show all the field names (this is
the same way "zfs list" works). Is that sufficient? If so, I will make
this explicit in the documentation.
> * 3.4 show-wifi
>
> Might add -w here, too.
Same as above.
> * 3.5 show-prop
>
> The -p in -p <prop>,... is redundant to specify properties. It's
> implicit in the subcommand that properties are to be displayed, so -p
> could be dropped (just like zfs get <property> <zpool> or dladm
> show-secprop <secprop>) and becomes available for specifying the parsable
> format (instead of the unintuitive -c).
Usability studies have shown that multiple operands are problematic
because people get confused about the order[1] (e.g., "getent hosts foo"
vs "getent foo hosts"). As such, our UI guidelines strongly advise
against having multiple operands.
We have the choice of making the property be the operand instead (and the
link be the "option"), but I was concerned that:
* It would be inconsistent with other dladm link-related subcommands,
which always take the link as an operand.
* It suggested the wrong conceptual model: the *-prop commands
manipulate a property associated with a link, not vice-versa.
BTW, I'm guessing you also object to svcprop(1M) :-)
[1] Though there are some notable cases that do not generate confusion,
especially for temporal operations (e.g., "mv foo bar").
--
meem
