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>