From owner-freebsd-questions  Tue Jul  9 20:07:08 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id UAA00542
          for questions-outgoing; Tue, 9 Jul 1996 20:07:08 -0700 (PDT)
Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA00537
          for <questions@freebsd.org>; Tue, 9 Jul 1996 20:07:05 -0700 (PDT)
Received: by hustle.rahul.net with UUCP id AA07271
  (5.67b8/IDA-1.5 for questions@freebsd.org); Tue, 9 Jul 1996 20:05:38 -0700
Received: (from jim@localhost) by starshine (8.6.11/8.6.9) id RAA04288; Tue, 9 Jul 1996 17:28:23 -0700
From: Jim Dennis <jim@starshine.org>
Message-Id: <199607100028.RAA04288@starshine>
Subject: Re: SysAdmin Tools - ideas wanted
To: terry@lambert.org (Terry Lambert)
Date: Tue, 9 Jul 1996 17:28:23 -0700 (PDT)
Cc: croot@btp1da.phy.uni-bayreuth.de, terry@lambert.org, questions@freebsd.org
In-Reply-To: <199607091827.LAA24694@phaeton.artisoft.com> from "Terry Lambert" at Jul 9, 96 11:27:47 am
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

> 
> 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