Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ulowell!apollo!nazgul From: nazgul@apollo.COM (Kee Hinckley) Newsgroups: comp.sys.apollo Subject: Re: Elm and other mailers for Apollos Message-ID: <43acb00f.1b147@apollo.COM> Date: 6 Jun 89 20:38:00 GMT References: <43290411.f81c@gtephx.UUCP> <1274@novavax.UUCP> <43657eac.1b147@apollo.COM> <1314@novavax.UUCP> Reply-To: nazgul@apollo.COM () Organization: Apollo Computer, Chelmsford, MA Lines: 243 In article <1314@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes: >In article <43657eac.1b147@apollo.COM> nazgul@apollo.COM (Kee Hinckley) writes: > Apollo's policy has always been, right or wrong, not to ship things that > we don't have the resources to support. We are fully aware that there are > *lots* of utilities, tools, etc. that we should ship and support. But > we can't do them all, so the best we can do is make them available via > ADUS for those people who are willing to work with unsupported software. > >I sure Kee believes Apollo is doing the right thing. But there is no >justification for any of the following: Did I say that I agreed with that policy? I spent three years trying to get my keydefs shipped as unsupported products. I gave up trying to ship my mkmodel script for DSEE, and sent it to this list instead (anyone interested in the SR10 version?). I'd fully like to see Apollo ship unsupported software as a separate piece of the releases. >3. Not documenting, in print, the many useful examples loaded under the >/domain_examples directory. Now we're back to resources again. >4. Not providing a simple way of writing programs to access the high >performance features of Apollo systems. Something along the lines of >the NeXTStep programming environment is what I have in mind. We have >100's of Apollos down here used by software engineers (mostly >cross-compiling for other platforms) and I don't know one who is fluent >in Apollo's large set of system calls. Hence no one can write an >application that makes good use of the graphics, network communication, >or other powerful parts of Apollos systems. Open Dialogue is a step in that direction. We have a problem here. Apollo has concentrated on getting out base technology that provides you with the means to deal with a lot of hard problems. In the process we have *not* had time to provide the higher level tools which make it *easy* to deal with easy problems. This means that we have tools like DSEE and DDE which are capable of doing very complex things, but which you have to learn in depth before you can even do easy things. You mention NextStep. That's a very sexy system. It lets you do simple things very quickly and easily. It does *not* let you do complicated things at all - you're right back to normal coding, and the WYSIWYG just gets in the way. Now maybe, by the time this becomes an issue, they will have solved those problems too. That's the gamble you have to make. Should we have done the sexy stuff first and then worried about the hard things? Maybe so. It's pretty hard to sell a system when it answers problems people don't know they have. >5. Not educating vendors as to the current state of Apollos system. >Most software vendors I speak to have not ported their software to >Domain/OS (SR10) and truly believe in their hearts that Apollo's OS is >Aegis and Aegis alone. That's an interesting one. How do you recommend that we do it? (I'm very serious here. I know we haven't suceeded, I don't know why.) >6. Not putting an alias facility in the Aegis shell and then providing >a set of common UNIX aliases. Do you know how many people are in the >process of weaning themselves from the Aegis shell and command naming >conventions. Many, many. Apollo's support of this is virtually nil. >In my sleep, I could write the alias facility, in fact I did (I was >awake though) two years ago. Then I would put together a simple two >page summary that maps common Aegis commands and options into their UNIX >equivalents. Apollo should do this so that all users benefit. The summary follows. I wrote it several years ago for a video course on Unix shell programming (for Apollo support people). As to the alias feature in the com shell, I don't see that this gets you what you want. Should we have provided an alias feature in the Unix shells to alias common Aegis commands? That would make sense for a transition, but why the other way around? And why not just add /com (or the Unix paths) to your PATH or CSR variables? >There is more to say, but I won't burden everyone. The point is, there >was much more behind my original statement about good environments. I >hope you understand my vantage point, Kee, and that I wouldn't take the >time to write this if I didn't feel that there were seeds of greatness >buried below Apollo's surface. I definitely understand, and I agree. From my standpoint in the trenches I have two choices - put out as much functionality as possible to keep ahead of the competition, or put out very little functionality, but make it easy to use. We've been doing the first, and so we haven't provided things like alias packages for the shells, templates and defines for Open Dialogue or Domain Dialogue, standard macro packages for DDE, scripts to build and update DSEE models, etc.... Some of these things exist, but have no one to support them, some of them never get written. (It's rather like Emacs. Everyone who uses it swears they'll write a good novice use package for it, but by the time they learn how to do it they don't need it any more.) Now maybe Apollo should have comitted the non-trivial resources to do these things (unfortunately they can't be done by grunts or new-hires), but we didn't. Personally I sincerely hope this is something we will gain from becoming part of HP - they have the reputation for that kind of quality, we have the reputation for the technology. These opinions are of course, my own. What follows are excerpts from my slides on Unix shell programming for Aegis shell programmers. They are doubtlessly out of date and incomplete, but I hope that they may be of help to someone. (BTW. If you asked for the GIF code and didn't get it, please let me know. I sent it to everyone I could, but I may have missed some. Be sure to include a reply address in your message - someone's mailer is truncating From: lines occasionally.) ----------- Walk on the Wild Side Aegis Bourne Shell C Shell egrep/sed/awk/ed/ex... ? ? ? . % no-period * * ?* * * .* [ ] [ ] [ ] [ ] ~ ^ (only in the editors) ... Some commands take a -r option, otherwise use "find dir -print". = ( ) { } \( \) @n \n @ \ \ \ Meta-characters - or - What not to put in your filenames CH Meaning Aegis Equiv. Notes $ Variable expansion ^ \ Escape character @ ( ) Pipeline IO ( ) This pushes a level! & Put in background & && cmd1 AND cmd2 || cmd1 OR cmd2 ; cmd1 THEN cmd2 ; > redirect stdout > < redirect stdin < >> append stdout >> << read from heredoc << | pipe | ` Active function ^"" * Wildcard ?* ? Wildcard ? [ ] Wildcards [ ] : Null command - Begin a flag - Where did it go? - Shell Builtins Aegis Unix Where? if/then/else/endif if/then/elif/else/fi builtin while/do/enddo while/do/done builtin select/oneof/allof/case/to/ case/in/esac builtin otherwise/endselect for/in/by/char/word/line/endfor for/in/do/done builtin for/to/endfor expr command von/xon/voff/xoff set -v -x - builtin -n -n option -i -i option args echo builtin eqs test command existf test command csr $PATH variable rdym times builtin hlpver man comand abtsev set -e builtin inlib inlib builtin bon/boff >/dev/null 2>&1 redirect return exit builtin existvar = builtin read/readln read (but no pipes) builtin dlvar unset/unsetenv (csh) builtin lvar set builtin and/or/mod/not expr command true/false true/false command readc exit break builtin next continue builtin eon/eoff $noglob (csh) export export builtin set set/eval builtin source . builtin setvar = builtin umask umask builtin Where Did It Go? - Shell Commands #1 Aegis Unix acl chmod/chown/chgrp/sup bind ld catf cat chn mv chpass passwd chpat sed/awk/expr cmf/cmt diff/cmp cpf/cpl cp cpt cp -r (bsd)/find -print | cpio -pdu (sys5) crd mkdir crl ln date date dcalc bc/dc debug dbx dlf/dll/dlt rm/rmdir ed sed/ed/ex edacl chmod/chown/chgrp/sup edstr sed exfld awk (bsd)/cut (sys5) flen wc fmt fmt (bsd)/nroff/troff fpat fgrep/grep/egrep fpatb awk help whatis (bsd)/man ld ls/file login login/su lusr who/rwho Where Did It Go? - Shell Commands #2 Aegis Unix lvolfs df/du macro m4/cpp mail Mail (bsd)/mail mvf mv nd $HOME ppri renice (bsd)/nice prf pr/lpr pst ps rbak cpio (sys5)/tar send_alarm write sigp kill siorf/siotf cu/uucp srf sort tctl tset (bsd)/stty tee tee tlc tr tz $TZ/$TZNAME uctob unlink wbak cpio (sys5)/tar wd cd