Jane Young wrote on 8/10/09 6:43 PM:
> See comments below:
>
> Bill Shannon wrote:
>> kedar wrote on 8/10/09 3:53 PM:
>>
>>> Bill Shannon wrote:
>>>
>>>> Can someone help me understand the background and use of the --echo
>>>> option to asadmin?
>>>>
>>>> At a very simple level this seemed to me to be like "sh -x", simply
>>>> echoing each command as its executed. This would be useful "asadmin
>>>> scripts" run in multimode, for instance.
>>>>
>>>> In v2, the --echo option would echo more than just the original command.
>>>> It would also echo most (all?) of the settings of the other asadmin
>>>> options, such as --interactive, --secure, --terse, etc. I've copied
>>>> that behavior in v3.
>>>>
>>>> However, this produces echo output that uses the old deprecated command
>>>> syntax, for example:
>>>>
>>>> $ asadmin --echo --terse version
>>>> version --host localhost --port 4848 --interactive=true --echo=true
>>>> --terse=true
>>>> ...
>>>>
>>>> changing that output to put the asadmin options first would be weird
>>>> unless it also included the word "asadmin", e.g.
>>>>
>>>> asadmin --host localhost --port 4848 --interactive=true --echo=true
>>>> --terse=true
>>>> version
>>>>
>>>> That would be fine except when the commands are being executed in a
>>>> multimode script (which seems to me like the primary use case).
>>>>
>>>> So, my question is, how important is it that --echo include values for
>>>> asadmin options that have not been specified? Would it be sufficient
>>>> if asadmin simply echoed the commands *as entered*?
>>>>
>>> I don't know the history too well, but ...
>>> I have routinely used the --echo flag to see the default values of certain
>>> options. So, from that angle, it's useful that it echoes not only those
>>> options
>>> that users specified on the command line. This was compounded by the
>>> fact that
>>> some options may come from the environment variables. echo used to treat
>>> them
>>> all and produce an output that used to tell the user what the final
>>> command line
>>> looks like, which is sometimes useful.
>>>
>>
>> That almost sounds like a "debugging" option. Or, if --terse=false
>> wasn't the default, that might be more like a "verbose" option.
>>
> The --echo option has been there since I started working on CLI (7-8
> years ago). The --echo option can be used as debugging purposes. I
> know SQE uses this option to check the default option values and the
> environment variables.
If we gave them another way to do this, would that be sufficient?
> AFAIK, --echo is not the same as --terse (verbose) option. The --terse
> option prints out the messages from stacktrace. This option is mostly
> used for scripting.
Right, they're different.
>>> With echo now being an asadmin program option, I see that the situation
>>> gets
>>> trickier and we can make a case that we change the behavior of echo
>>> slightly, to
>>> echo only the given (and maybe default) "command options" along with
>>> program options. How about for example,
>>>
>>> $ asadmin --echo version
>>> asadmin program options: --host localhost --port 4848 --terse false
>>> --interactive true --secure false --echo false
>>> command: version --verbose false
>>>
>>
>> So there would be two lines of output for each command?
>> Do you think anyone depends on the output format?
>> I hope not.
>>
>>
> I have a question. You said that it's weird in multimode to print out
> "asadmin" in the echo. So how does a user enter the generic options
> using multimode?
> e.g.
> asadmin>--host localhost --port 4848 version ?
No. You can use the deprecated syntax to override the program
options on a per-command basis, but the assumption is that generally
all the commands in a multimode script are going to apply to the
same server with the same options, so you'll specify those when you
start multimode and then won't need to specify them on each command.
But for compatibility, the old way is still supported.
Note that you can also change the values using the export command
while in multimode.
> I think printing out the command in the format as they are executed is
> beneficial for those who like to copy/paste the command. Maybe SQE team
> can give some inputs here.
Are there SQE people on this alias? If not, who should I check with?
>>> Also, note that we should be consistent in the display. For example, in
>>> your
>>> example, not all options and their values are separated by an '=' or '
>>> '. We
>>> need to pick one.
>>>
>>
>> I think I used =true/false for boolean options, mostly because I think
>> it's weird that that boolean options have an *optional* value, and
>> because I thought most people used that form when typing them.
>>
>> If you want consistency, I would leave out the "=" from all of them.
>>
>>
>>> If this makes it complex, maybe we should add a command named "defaults"
>>> that
>>> shows the default values of asadmin program options and then we have to do
>>> none of this and just echo the given command line verbatim?
>>>
>>
>> It would be very easy to add such a command. Note also that the "export"
>> command with no arguments will give you much of this, showing you which
>> program options have been set; try it.
>>
>>
> export command prints out the environment variables in multimode. The
> problem with "defaults" command is that not all defaults are the same.
> For example:
> the default value of type option for generate-jvm-report command is
> "summary" but for create-services is "das".
I think the command would only print out the defaults, well, really,
the effective values, for all the asadmin program options. It wouldn't
do anything with the per-command options. (Need a better name than
"defaults" for the command.)
Perhaps a "setoptions" command to set any of the asadmin options
and a "getoptions" command to list the defaults:
$ asadmin
asadmin> getoptions
--host localhost --port 4848 --secure false --user anonymous ...
asadmin> setoptions --host myserver.com