Date: Wed, 10 Jul 1996 12:00:36 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jim@starshine.org (Jim Dennis) Cc: terry@lambert.org, croot@btp1da.phy.uni-bayreuth.de, questions@freebsd.org Subject: Re: SysAdmin Tools - ideas wanted Message-ID: <199607101900.MAA26905@phaeton.artisoft.com> In-Reply-To: <199607100028.RAA04288@starshine> from "Jim Dennis" at Jul 9, 96 05:28:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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).
Yes.
> By why limit it's to one character?
Because an X user interface must respond to single events.
> 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).
Initially, because I wanted to hide the UI basis from the command line
user; I'd like to provide the command line user with feedback that
is relevent, but no more.
Then I started thinking on other issues, like internationalization; if
the command line is pre-translated, then the UI should just "fall out".
> 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.
No, you're right.
> 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).
Logging is a good idea; maybe transaction logging instead of command
logging, however... and only successful transactions, at that?
Eventually, I expect command line utilities to be built similar to
the VMS mechanism, where you define a grammar, compile it, implement
callback routines, compile them, and then link the whole mess with
a library that has a main() in it that externally references the
compiled grammar as data.
The advantage is obvious: the UI reporting, and command interpretation,
and environment management is done for you by the library, and will
always provide a consistent interface to a frontend talking to the
UI.
It also resolves the problem of internal use of stdout, since when it
is done to a pipe, the pipe is not flushed when input is requested
from stdin (an error in the stdlib, IMO).
Finally, it resolves the internationalization issues by divorcing the
textual data from the interface proper; it should be possible to
hook internationalization in with a seperate "grammar compilation"
for translated modules to return only localization data, so that the
utility can have compiled in English (or, potentially, other) keys, and
access the locale-specific strings via keys.
It does *not* resolve the ISO 10646 issues, since to do so would
require stream attribution for the data to indicate that it was a
16 bit instead of an 8 bit pipe (or for a full 10646/32 instead
of a Unicode-only 10646/16, a 32 bit pipe). I think those can be
dealt with at a later time; in fact, it should be possible to do
it transparently to the commands by implementing it all in the
command line processing library and the front end(s).
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607101900.MAA26905>