zfs discuss - Jan 2010 - customizing "zfs list" with less typing

It might be nice if "zfs list" would check an environment variable for
a default list of properties to show (same as the comma-separated list
used with the -o option).  If not set, it would use the current default list;
if set, it would use the value of that environment variable as the list.

I find there are a lot of times I want to see the same one additional property
when using "zfs list"; an environment variable would mean a one-time
edit
of .profile rather than typing the -o option with the default list modified by
whatever
I want to add.

Along those lines, pseudo properties that were abbreviated (constant-length)
versions
of some real properties might help.  For instance, sharenfs can be on, off, or a
rather long list of nfs sharing options.  A pseudo property with a related name
and a value of on, off, or spec (with spec implying some arbitrary list of
applicable
options) would have a constant length.  Given two potentially long properties
(mountpoint and the pseudo property "name"), output lines are already
close to
cumbersome (that assumes one at the beginning of the line and one at the end).
Additional potentially long properties in the output would tend to make it
unreadable.

Both of those, esp. together, would make quickly checking or familiarizing
oneself
with a server that much more civilized, IMO.
-- 
This message posted from opensolaris.org

On January 23, 2010 4:33:59 PM -0800 "Richard L. Hamilton" 
<rlhamil at smart.net> wrote:
> It might be nice if "zfs list" would check an environment
variable for
> a default list of properties to show (same as the comma-separated list
> used with the -o option).  If not set, it would use the current default
> list; if set, it would use the value of that environment variable as the
> list.
>
> I find there are a lot of times I want to see the same one additional
> property when using "zfs list"; an environment variable would
mean a
> one-time edit of .profile rather than typing the -o option with the
> default list modified by whatever I want to add.
...
> Both of those, esp. together, would make quickly checking or
> familiarizing oneself with a server that much more civilized, IMO.
Just make ''zfs'' an alias to your version of it.  A one-time
edit
of .profile can update that alias.

-frank

> Just make ''zfs'' an alias to your version of it.  A
> one-time edit
> of .profile can update that alias.

Sure; write a shell function, and add an alias to it.
And use a quoted command name (or full path) within the function
to get to the real command.  Been there, done that.
But to do a good job of it means parsing the command line the
same way the real command would, so that it only adds
-o ${ZFS_LIST_PROPS:-name,used,available,referenced,mountpoint} 

or perhaps better

${ZFS_LIST_PROPS:+-o "${ZFS_LIST_PROPS}"}

to zfs list (rather than to other subcommands), and only
if the -o option wasn''t given explicitly.

That''s not only a bit of a pain, but anytime one is duplicating
parsing,
it''s begging for trouble: in case they don''t really handle it
the same,
or in case the underlying command is changed.  And unless that sort of thing
is handled with extreme care (quoting all shell variable references, just
for starters), it can turn out to be a security problem.

And that''s just the implicit options part of what I want; the other
part would take
optionally filtering to modify the command output as well.  That''s
starting to
get nuts, IMO.

Heck, I can grab a copy of the source for the zfs command, modify it,
and recompile it (without building all of OpenSolaris) faster than I can
write a really good shell wrapper that does the same thing.  But then I
have to maintain my own divergent implementation, unless I can interest
someone else in the idea...OTOH by the time the hoop-jumping for getting
something accepted is over, it''s definitely been more bother gain...
-- 
This message posted from opensolaris.org