Date: Fri, 5 Jul 1996 20:03:54 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: chuckr@Glue.umd.edu (Chuck Robey) Cc: terry@lambert.org, kelly@fsl.noaa.gov, gpalmer@FreeBSD.org, ron@infi.net, freebsd-questions@FreeBSD.org Subject: Re: SysAdmin Tools - ideas wanted Message-ID: <199607060303.UAA16046@phaeton.artisoft.com> In-Reply-To: <Pine.OSF.3.91.960705194947.13527F-100000@downlink.eng.umd.edu> from "Chuck Robey" at Jul 5, 96 07:53:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Terry> Tcl/tk are OK for the fornt end tool, but not the backend > > > Terry> implementation. > > > > > > But it'd be perfect for providing an *interface* to the backend > > > implementation. That's one of Tcl's strongest features: it's easily > > > embeddable---and you get a set of nice scripting primitives as a > > > bonus. > > > > Keep the scripting away from the tools proper, please. I don't > > want to *have* to run Tcl to administer my system, but I can > > understand that other people may want to run it to administer theirs. > > This isn't clear to me, Terry ... Keep any software capable of accepting > a script away from a prime scripting application .... hmmm, would you > have said the same to a perl script, or a shell script? This sounds > somewhat inconsistent, I'd like you to amplify on it, if you would. Yes, I would say exactly the same thing to a perl script or shell script. I think the system management tools should operate on a class of databases (for instance, the "user" and "group" databases are elements of the class "credentials"). I think the tools should impose their own UI schema as data. I think the front end should open the tools via a pipe (and the tools written to understand stdio flushing on output for not tty output). I think the front end should be written in sh, or perl or tcl, or whatever. I *don't* think the management tools themselves should be. I think the management tools should be uilt for script embedding, so that they may be invoked with command line arguments; for instance: ============================================================================ Example: a "uadmin" tool: ============================================================================ ---------------------------------------------------------------------------- Mode 1: command line batch. This mode is used by front ends. ---------------------------------------------------------------------------- # uadmin uadmin> BEGIN ADD USER add user> USER=jkh add user> NAME=Jordan Hubbard add user> ID=501 add user> GROUP=20 0 552 add user> HOME=/home/jkh add user> SHELL=/bin/csh add user> EXPIRE_PASSWORD=NEVER add user> EXPIRE_ACCOUNT=NEVER add user> END ACCEPT uadmin: added jkh uadmin> ^D # ---------------------------------------------------------------------------- Mode 2: command line, non-interactive. This mode is used in scripts. ---------------------------------------------------------------------------- # uadmin add user USER=jkh NAME="Jordan Hubbard" ID=501 GROUP="20 0 552" HOME=/home/jkh uadmin: added jkh # ---------------------------------------------------------------------------- Mode 3: command line, interactive. This mode is used by a human. ---------------------------------------------------------------------------- # uadmin uadmin> add user USER=jkh NAME="Jordan Hubbard" ID=501 GROUP="20 0 552" HOME=/home/jkh uadmin: added jkh uadmin> ^D # ============================================================================ As you can see, there are well known "environement variables" for any given scoping. Clearly, in the mode 1 usage, "END CANCEL" would discard edits instead of saving them, as "END ACCEPT" does. etc. I posted a partial grammar for the "uadmin" command skeleton using yacc, lex, and C code to this list previously. 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?199607060303.UAA16046>