In v2, if the command fails and if terse=true, then it just displays:
"Command failed" and exits with a non-zero exit code
If terse=false, then it displays the exception message
(e.getLocalizedMessage())) from the server side.
All the commands in v2 has the --terse option, similar to --echo option.
The purpose of terse option is for CLI scripting where users wants a
terse output.
Bill Shannon wrote:
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>