Date: Tue, 9 Jul 1996 17:28:23 -0700 (PDT) From: Jim Dennis <jim@starshine.org> To: terry@lambert.org (Terry Lambert) Cc: croot@btp1da.phy.uni-bayreuth.de, terry@lambert.org, questions@freebsd.org Subject: Re: SysAdmin Tools - ideas wanted Message-ID: <199607100028.RAA04288@starshine> In-Reply-To: <199607091827.LAA24694@phaeton.artisoft.com> from "Terry Lambert" at Jul 9, 96 11:27:47 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Here is my take on divorcing the front end technology from the > utility<->front end data interchange grammar: > > It would look like a method of defining CLI utilities (initially > by hand with UI requirements), and a UI library consumer that could > talk to a CLI written the right way to marshall the data to the > UI code and the UI event back to CLI commands. > > So there is a need for two defined interfaces and a framework: > > ,------------------------------------------. > | UIM (User Interface Manager) | > `------------------------------------------' > /\ /\ > || || > \/ \/ > ,-------------------. ,-------------------. > | CLI | | UI | > `-------------------' `-------------------' > > The CLI recognizes that it has been opened via pipe, and goes into > "transaction mode". Each command is responded immediately with a > single character feedback of '0' (success) or '1' (error). I gather that your trying to devise a way that allows you to fork once and have the underlying (CLI) tool respond to an arbitrary number of commands (transactions) before being explicitly closed. For some tools this certainly makes more sense than my original suggestion (which implied building a separate command line for each request). By why limit it's to one character? If you're saying that the CLI tool should act like a shell when invoked from the shell with no arguments (a reasonable thought) then why not set it up so that this "shell's" "prompt" starts with a status code for the last issued command -- thus you only have one interface to write and test rather than two ("pipe mode" vs. "shell/CLI" mode). Even for interactive use this is reasonably good information (I have, in the past, configured my shell prompts to include $? (bash) so I'm aware, at a glance, of what sorts of return/error codes various programs provide under various circumstances. I don't think that this suggestion (treat the CLI is a "shell/command interpreter" and provide reasonable error messages and prompts, will interfere with any of the other elements you outline. I'd still recommend that there exist options to log the exact dialogs/sessions between the interactive front end and the CLI back end. I'd also still recommend that the CLI be able to accept a full range of command line options (even if that follows the 'awk' model of having rather verbose command line syntax). Jim Dennis, Starshine Technical Services
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607100028.RAA04288>