Tom Mueller wrote on 06/25/10 06:50 AM:
> Bill,
> Why isn't --terse passed to the remote command? Seems like there are
> many cases where a remote command should produce different, easily
> parsable, output if --terse is specified.
The lame answer is, this is the way it worked before I got involved
in this code. Possibly this is how it worked in v2 as well, although
I don't know for sure. As I understand it, in v2 every command had
a client-side implementation class, and that class used AMX to talk
to the DAS (for remote commands). That certainly would've given
every command the ability to behave differently based on --terse,
although I don't think it passed the option to the server through
the AMX API.
Since it's just software, we *could* pass it to every remote command.
What would that involve? Well, we could pass it just like we pass
any other parameter, and the admin adapter could handle it as a
special case and make it available in the command context for commands
that need to look at it. Or we could only pass it to commands that
declare a --terse option, and let them handle it the same way they
handle any other option.
If we needed to do that to better emulate v2 behavior, I would definitely
consider it.
Otherwise, it's sort of like a global option or environment variable,
that requires special case handling in the admin adapter. We could
generalize it and pass all (relevant) environment variables to the
server, but that might be overkill.
What do people think? Should we make --terse available to all remote
commands?
Or should --terse only effect asadmin local commands, with remote commands
each defining their own --verbose or --long option(s) as appropriate?
Note that if you really wanted to get carried away with producing
parsable output that's controlled by the user, you would do like the
Solaris zfs (and other) commands do and provide options that allow
you to suppress the headers and specify which columns to include in
the response. I'm definitely not suggesting that we do that.