From owner-freebsd-questions Wed Jul 10 12:08:00 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA05484 for questions-outgoing; Wed, 10 Jul 1996 12:08:00 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA05475 for ; Wed, 10 Jul 1996 12:07:58 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA26905; Wed, 10 Jul 1996 12:00:36 -0700 From: Terry Lambert Message-Id: <199607101900.MAA26905@phaeton.artisoft.com> Subject: Re: SysAdmin Tools - ideas wanted To: jim@starshine.org (Jim Dennis) Date: Wed, 10 Jul 1996 12:00:36 -0700 (MST) Cc: terry@lambert.org, croot@btp1da.phy.uni-bayreuth.de, questions@freebsd.org In-Reply-To: <199607100028.RAA04288@starshine> from "Jim Dennis" at Jul 9, 96 05:28:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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.