We need support for enabling/disabling cli paging. It could be done via cli command or parameter to rhevm-shell. This feature will ease: - writing system scripts by end user - cli validation automation effort I can tell you that in current situation it will be difficult for end user to parse output (since each ': <space>', 'END q' is adding tons of gibberish ACSI characters and slowing down expect). Due this reason this feature is common in cli products and user (and me as automation engineer) will expect it.
it's disabled by default when executing script (-f/--file) which is works for your use-case.
"-f FILE, --file=FILE read commands from FILE instead of stdin" is not enought, please provide an example how can I use it when I will need to do query, process information and put it back. for example: how can i write script that do query, getting need information and running command with this information by using this option?
rhevm-shel is combined rhevm & linux shell environment, you can use linux tools to filter and process the output at runtime: 1. run rhevm command and process the output saving it in to data holder ==============================================================+======== [RHEVM shell (connected)]# list vms | grep name > vms.txt 2. create new script at runtime =============================== [RHEVM shell (connected)]# !less vms.txt | sed s/'name :'/'action vm'/ | sed -e 's/$/ start/' > new_script_to_run.txt 2. invoke new script at runtime =============================== [RHEVM shell (connected)]# file new_script_to_run.txt * see the files output in shell during dev as "!less new_script_to_run.txt" * i believe it answers all your (and users) needs for testing and scripting
i've created wiki example [1] using mentioned above. [1] http://wiki.ovirt.org/wiki/CLI#Run_all_vms
Thanks Michael. from my experience with cli (it comes from embedded systems like switches) I can tell you that many users would like to use expect with scripting language that will be readable days after that script was written. Also If company already uses/develops some king of framework, it will use perl/python/tcl stuff rather bash stuff and it means using expect All what i'm asking is to give user option to disable paging so he will be able to use any language that he wants. For example: Now I should write wrapper for bash in python. Why you are insisting so mach?
(In reply to comment #5) > Thanks Michael. > > from my experience with cli (it comes from embedded systems like switches) I > can tell you that many users would like to use expect with scripting > language that will be readable days after that script was written. > > Also If company already uses/develops some king of framework, it will use > perl/python/tcl stuff rather bash stuff and it means using expect > > All what i'm asking is to give user option to disable paging so he will be > able to use any language that he wants. > > For example: Now I should write wrapper for bash in python. > Why you are insisting so mach? insist?, ilia, i just replied to your RFE Description and Comment 2 (that enduser have to deal with file output redirection in scripts), saying that it's disabled by default during script execution. this RFE should be called "disable output redirection to ease testing efforts"
To sum up what I'm acking: Disabling auto scrolling via configuration. Default value as today for backwards compatibility
ec069fc807716e065b8eb3c8d626ae87810513b0 paging disabling is done via 'no_paging = True' configuration value. 1. run shell to update configuration file with new key 2. modify ~/.ovirtshellrc or ~/.rhevmshellrc (depends on your distribution).
http://gerrit.ovirt.org/#/c/9263/
verified with rhevm-cli-3.2.0.3-1.el6ev.noarch
the configuration key of this feature was eventually renamed to 'autopage'
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0890.html