star@fluke.UUCP (David Whitlock) (01/09/86)
The following is an initial review of the 'MyCLI' program submitted by
Mike Schwartz.
From an educational/resource standpoint, I would give this program an A
the program covers alot of topics via commands to MyCLI, but presented in
a functional format. From a usefulness standpoint, I would give this program
a B- (author has stated that many parts are primitive and is working hard to
expand and refine). From a initiative standpoint, I would give this program
an A, MyCLI in concept does provide many features not found in CLI like
.bat files etc. and strives to provide an environment similar to a csh (shell).
I am locked from responding directly to the author but feel the following
comments or suggestions will be of interest to all Amiga types.
Problem and When MyCLI is invoked, current_directory defaults to 'DF0:'.
Sugestion This is a real hassle to the beginner. Provision should be
Areas : made to read current assigned directory as default.
When in MyCLI, call of another MyCLI, leaves original locked
to the second MyCLI window. This is inconsistant with CLI.
Error Messages appear in Black which make them difficult to
read (RED would be better).
Date and Time are displayed in inverse video after each
command execution. Clutters up the display and blinds the
user who is not wearing sun glasses. I suspect I can turn
this off, but haven't decoded the key.
CTRL/C and CTRL/E toggle commands, should be moved to the
Shifted Function Keys while in terminal mode. Many Hosts
make use of CTRL/C and CTRL/E sequences. Also BREAK should
also be defined as a Reserved Function Key while in terminal
mode.
Window sizing gadgets gets destroyed when text reaches last
line.
Directory Listings should be alpa sorted (maybe the addition
of flags like a=all s=sort r=reverse sort etc.)
An Alias Lookup File should be implemented so that any command
MyCLI or system can be renamed and executed with options.
This would solve the redundent command list lookup table.
Unix style wildcards meta-characters and option passing needs
to be added.
Final Thought: If MyCLI commands are intended to replace existing c: programs
they should provide all the existing functions else leave them
external.
Congrads : All in all, Job-Well-Done and I am eagerly awaiting the
updates (P.S. thanks for posting this early version).
--
-- Dave Whitlock
{decvax!microsof,uw-beaver,ssc-vax,allegra,lbl-csam}!fluke!star
John Fluke Mfg. Co., 33031 Schoolcraft Road, Livonia, MI 48150mykes@3comvax.UUCP (Mike Schwartz) (01/14/86)
I am glad that MyCLI is of use to some of you out there. I am not working extremely hard on it currently, becuase I have some work to do for someone else (till end of Jan.), which is why I posted the early version. However, I have done some things to it. First of all, I planned to do a lot of things that were suggested by mr. fluke, however, My idea of a replacement CLI is one that is maybe twice the size of the old CLI, and that had a generous subset of the normal CLI commands. The idea is to reduce the number of compiled lattice 'C' programs (executable programs like copy, cd, etc.) that one normally puts in ramdisk (for speed). I felt that it was better to have a 24K CLI and 12K of external (disk resident) commands in ram disk than to have an 8K CLI and 28K of external commands. The other added features of a replacement CLI should make it more desireable to use. First of all, the HELP key does work in MyCLI!! It will list all of the available commands. I am sorry, but until I complete the next version of MyCLI, the exact format of the commands is only documented in the source code. The "prompt" command is similar to the one on MS DOS, and you can use it to make some neat prompts. The prompt string is printed character for character, except that '$' is a metacharacter. $r turns on reverse video, $n turns it off, $_ generates a newline, $d generates the date, $t genereates the time, and $p generates the path. Please feel free to use the source code as examples of how to do most things with AmigaDos. Although the program has been published in the public domain, the source does belong to me. Some of the more interesting routines in MyCLI that are worth looking at are the date and time stamp decoding routines, lock structure processing, directory and subdirectory handling, and the copy command. I will release a copy command to replace the old CLI copy command in the very near future - my scheme is 6X faster than the standard CLI copy, and works extremely well with just one disk!!! A tip for MyCLI - I use the assign command to assign x: to the normal c: (command) subdirectory. From MyCLI, I can access any standard CLI command by doing x:list or x:copy or x:dir, etc. Also, I use the autoexec.bat startup file to initialize a set of function key values. Typically they are the ATDT command to dial the 3Com Vax, my login and password, and other unix commands I want ready at a keystroke. The current version of MyCLI that I have will read out loud, using the translator and narrator devices, news and mail (and anything else) from unix (or over the phone). It is a new toggle command called "narrate". I currently use the Exec function to create newcli's, but a friend at Amiga suggested that I make a library out of MyCLI and just Exec smaller front ends. As long as I am at it, I will probably explore some of the deeper depths of AmigaDos (the Load function, and the CreateProcess function) which will (hopefully) get rid of the NEWCLI problems MyCLI now has. I am sorry I couldn't get the NEWCLI to work as well as I wanted, but I tried everything I could think of (all combinations of Exec calls) with no sucess. In general, AmigaDos is pretty good, but it is real weak at dealing with multi-window/multi-tasking (no close gadget, etc.), and there is a bug when the standard CLI tries to endcli with no windows open. Some other points about the review: The size gadget gets erased, because the standard console device on the amiga defaults to 77 characters per line, and this makes using programs that expect 80 character displayable lines. I hacked a solution (by sending the ANSI sequence to set the right margin to 80 characters), but this causes the size gadget to scroll. The tradeoff would be unix programs that use the curses package only work with 80 char lines (otherwise the screen scrolls and the curses positioning gets screwed up). From my work on MyCLI, I have a pretty good idea that the Amiga makes an incredible terminal for UNIX!! I think it would be VERY TRIVIAL to create a version of unix that interfaced to the Amiga and allowed Multiple signons in multiple windows on one Amiga. In other words, the NEWCLI command can be added to UNIX, and it would open a window on the Amiga, and would issue its prompts, etc. there. I think the trivial change would be modifying the "output character" (lowest level) routine that is called by every unix program (via printf, puts, etc.) to output a window identifier prefix before each byte output (a number identifying which window the output goes to). The Amiga can easily direct the character to the appropriate window... I do not know the ST internals very well, but I find it hard to believe that without multi-tasking, such an enhancement to unix would be as easy. I also see lots of similarities between the Amiga's OS and UNIX, although there is little overlap and quite a bit of complementary stuff (i.e. windows, gadgets, etc. on the Amiga, and the Unix internals). Also, Amiga 'C' functions seem to all begin with capital letters (OpenLibrary, etc.) while unix symbols seem shorter and are lowercase (creat). I am very new to UNIX, so this is just a simple observation, but it seems valid. Later... mike schwartz @ 3Com Corp. (usual disclaimers apply).
sgt@alice.UucP (Steve Tell) (01/19/86)
Some information concerning your idea of multiple unix windows: >From my work on MyCLI, I have a pretty good idea that the Amiga makes an >incredible terminal for UNIX!! I think it would be VERY TRIVIAL to create >a version of unix that interfaced to the Amiga and allowed Multiple >signons in multiple windows on one Amiga. In other words, the NEWCLI >command can be added to UNIX, and it would open a window on the Amiga, >and would issue its prompts, etc. there. I think the trivial change would >be modifying the "output character" (lowest level) routine that is called >by every unix program (via printf, puts, etc.) to output a window identifier >prefix before each byte output (a number identifying which window the >output goes to). The Amiga can easily direct the character to the appropriate >window... ... >mike schwartz @ 3Com Corp. Your scheme would certianly work, but would require modifying all of the unix programs you wanted to use. Another solution is to write a unix program called a "multiplexor" that communicates with various unix shells. On 8th edition research unix, the communication is done with a thing called a "pt;" the shell thinks it's talking to a terminal, but it's really talking to the multiplexer, which in turn talks to the amiga through a packet protocol, with error checking if you like. It's similar on BSD and system-V, having somthing to do with "sockets" on BSD, and an "xt" on sys-V. (I haven't figured them out yet) The result would be very much like the Blit terminal. Too bad AT&T didn't chose to use the amiga for that unix terminal project- They could have used a lot of the original Blit code and done just what I said above. It could be done on the ST, but as Mike Schwartz pointed out, Probably not under the St's operating system, whereas on the amiga it can be.
hamilton@uiucuxc.CSO.UIUC.EDU (01/20/86)
>From my work on MyCLI, I have a pretty good idea that the Amiga makes an >incredible terminal for UNIX!! I think it would be VERY TRIVIAL to create >a version of unix that interfaced to the Amiga and allowed Multiple >signons in multiple windows on one Amiga. >I think the trivial change would >be modifying the "output character" (lowest level) routine that is called >by every unix program (via printf, puts, etc.) to output a window identifier >prefix before each byte output (a number identifying which window the >output goes to). The Amiga can easily direct the character to the appropriate >window... first, i want to thank mike for mycli; there's a lot of good stuff in there, and at the very least, he has saved me a lot of trial and error research. regarding the quote above, there's a public domain program that should take care of most of the Unix side of the job. i'm enclosing the README from the wms distribution. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton@uiucuxc.cso.uiuc.edu CSNET: hamilton%uiucuxc@uiuc.csnet USMail: Box 476, Urbana, IL 61801 Phone: (217)333-8703 < WINDOW MANAGEMENT SYSTEM < <A window management system for 4.2bsd systems is being released by George <Nelan at Arizona State University. The system, WMS, is in the public domain <and consists of : <- MSH, an executable meta-shell manager which resides on the host, manages <sub-shells (csh or user) via ptys, and coordinates communications with an <external window manager by multiplexing standard I/O; <- WTY, a host-resident executable window manager built upon MSH, utilizing the <TERMCAP database so that most programs can run in windows (vi,..); <- TOOLS, a set of code fragments to assist the do-it-yourself types in <developing their own [remote] window managers (PC,..) for linkage to MSH; <- DOCUMENTATION, a complete set of user manuals in the form of three 'man' <entries; and last, but not least, <- SOURCE CODE. < <A brief description of WTY follows: <WTY emulates a virtual windowing terminal on a variety of devices (vt100,..). <The underlying actual device must support controllable scrolling regions and <cursor motion as described by a [user-defined] TERMCAP entry. Windows are <defined as multiplexed scrolling regions; all windows span the width of the <display. Each window is truly scrollable (without redraws) with all visible <windows the same size. WTY multiplexes sub-shell output into windows in a <way that allows apparent concurrency. A 'select current input window' command <may be used to direct user input to any visible window. Other commands allow <window creation/deletion, opening/folding (making visible/invisible), <labeling (windows are not bordered since context usually provides sufficient <implicit discrimination clues - labels explicitly delimit borders), and <buffer manipulation: create/delete (I/O recording), open/fold (enable/disable <recording), and read selection (take a buffer as user input). Window size <information is communicated to sub-shells by a wty-generated "setenv TERM <X>" <message, where <X> identifies a virtual terminal related to the window size. <A resize command allows retransmission of this message at any time. A 'nice' <option on all commands which affect window size allows quiet dynamic <manipulation of windows (no automatic "setenv" messages are generated). A <help command provides a summary and the command character prefix may be user- <defined. < <The system has been operational since June 1985 and seems to be fairly robust <and relatively efficient. We will provide a copy of the system in 1600 BPI <TAR format if you send us: < <- A mag tape (the system release is ~ 256KB). <- Return postage or a check payable for same made out to: < "A.S.U. Engineering Computer Center" < Or indicate shipping collect. < Shipping will be via UPS unless you specify otherwise. < <Upon special request, a shar version is available via UUCP. As this file is <123KB long (~20 min @ 1200B), we prefer tape transfers. < <Contact: < < George Nelan < Engineering Research Center (ERC 207) < Arizona State University < Tempe, Arizona, 85287 < (602)-965-2791 < < UUCP: < ...{ucbvax,ihnp4}!arizona!asuvax!nelan < ...ihnp4!noao!terak!asuvax!nelan < < CSNET: < nelan@asu