Text File

Aihuxp.102 NET.blfp utzoo!duke!chico!harpo!mhtsa!ihnss!ihuxp!steffen Thu Jul 23 10:15:35 1981 3.19 From: ihn5g!jdd (Joe Steffen filling in for John DeTreville) Subject: BLFP 3.19

Bell Labs Free Press Thursday, 23 July 1981 Volume 3 : Issue 19

Today's Topics: Ld, Screen Editors, Unix Evolution, Inodes, IHCC Tapes, Remote Command Installation, Xerox 9700, Forgotten Commands ----------------------------------------------------------------------

>From alanr Mon Jul 20 08:39:55 1981 remote from ihn5h Subject: ld problems and vi/ex on RT

On the vax, 'ld -r' doesn't work in sort of obvious ways. If you have troubles with it, get a copy of the 4.0 ld. It seems to have solved most of the 3.0.1 problems.

Keith Falck (ihl5d!kff) uses vi/ex on /RT, probably on every version. He almost certainly has the source and I think he might have the 'ved/hpved' source for /RT as well. (ihl5d is not on the usend network, if you can't reach him by UNIX mail try IH x2781. Or try going usend->nusend via one of the ihn5? machines).

------------------------------

>From steffen Sun Jul 19 19:59:37 1981 remote from ihuxb Subject: Screen Editors and File Types EMACS_MODES: fill !lnumb

Many screen editors have user-setable modes to control things like automatically starting a new line when you type off the end of the current one. This is great for text files but undesirable for program source files. Emacs and vi provide commands to change modes that can be executed in startup files, thus allowing you to change the default values. Emacs also allows you to put a comment in a file to change the modes for that file.

I find that I use a screen editor to examine a lot of C files written by other people, so I have my default modes set up for C. I put comments in nroff source files to set up the modes for text, but it's awkward to put the comment in formatted text files (like this one) because it clutters up the text (see the line after the subject line). I would like to set the default modes for text to fix this problem, but I would always have to change them when editing C files. Switching back and forth between types of files is a problem because once a mode is set by a comment it remains in effect on all files, so you really have to have a comment in every file to set or reset the modes appropriately.

What I would like to be able to do is to define default modes for each type of file, where the type is an arbitrary file name suffix like ".c". which could be the whole file name to handle "makefile" and "README" files. I would probably start adding a ".t" suffix to nroff and misc. text files and set up the unknown or default type for shell scripts. This should eliminate the need for manual changing of modes and for mode comments in files.

Joe Steffen ihuxp!steffen or ihuxk!steffen

------------------------------

>From steffen Sun Jul 19 20:56:17 1981 remote from ihuxb Subject: Program Templates in Screen Editors EMACS_MODES: fill !lnumb

I just finished digesting a treasure trove of papers on sophisticated screen editors, which were previously documented only in hard to find technical reports and user manuals. This collection is the "Proceedings of the ACM SIGPLAN SIGOA Symposium on Text Manipulation" and can be found in the June 1981 issue of SIGPLAN Notices. Several papers were on syntax-directed editors for specific languages. These editors all had commands that would insert a template for a language statement or control structure into the program text, for example:

while (<EXPRESSION>) { <STATEMENTS> }

The cursor would be placed at <EXPRESSION> and the text entered would replace this token. The cursor would be moved to <STATEMENTS> when a carriage return or some such character was entered. <STATEMENTS> would be expanded in a similar manner. This saves a lot of repetitious typing and helps enforce coding standards.

These template commands could be added to existing editors with much less effort than writing a syntax-directed editor for C, shell, or whatever language you use. You might have a file of definitions for each language type containing entries like:

w: while (^) { ^ }

The "w:" defines the template name (w) to be entered after the template command invokation characters. The "^" is a character not used in the language that marks the cursor stopping points. The editor would insert the template, indent it properly, move the cursor to the first "^", and delete it. The user would enter the text and then a "move to next ^" command. The editor would move the cursor and delete the "^".

This template command would be fairly easy to add to emacs with an extension to the abbreviation macro package. Each character in the template would have to executed as a command to insert it so the auto-indentation mechanism for the C language is invoked on the braces, tab, and newline characters. This command would be harder to implement in other editors but would still be less effort than writing a new syntax-directed editor for each language.

Joe Steffen ihuxp!steffen or ihuxk!steffen

------------------------------

>From hobs Mon Jul 20 14:32:13 1981 remote from ihuxo Subject: EMACS and EX/VI on IBM/370

Jeff Langer(eagle!jal) asks if anyone has brought up EMACS or EX/VI on UNIX/370? The reason that you cannot put a screen editor onto the IBM systems is that you need a full-duplex connection to the computer, and all the IBM/Amdahl mainframes here have only half- duplex connections. I would like it very much if I could use EMACS on the TSS system (if UNIX/370 has penetrated to Indian Hill, the comp centre is keeping quiet about it), but I cannot. May cats not howl on your fence tonight, John Hobson ihuxo!hobs

------------------------------

>From grg Tue Jul 21 09:47:11 1981 remote from ihuxg Subject: vi/370

I heard that the UNIX/370 prople out East were bringing up ex/vi, they had some snags, but that was a while ago, and I would guess that they finished it by now. I don't remember who it was that contacted me about this, but I'm sure that anyone w/ UNIX/370 roots could give info.

Greg

------------------------------

>From grg Wed Jul 22 17:08:01 1981 remote from ihuxg Subject: editors + UNIX

I recently received the following mail::

>From gjh Wed Jul 22 15:59:11 1981 remote from ihuxb Re: Visual editor for UNIX 4.2 and beyond

Decisions are currently being made at MH on which visual editor will be included on future releases of UNIX. The current winner seems to be the editor portion of EF (OAS package). Do you know of any comparative studies between our local IH favorites (VI, EMACS, VED, others). If EF is a giant step backwards, I would like to see the reasons why.

This may be a good BLFP item.

I do feel that EF is a step to the posterior, but I have seen only a fleeting demo thereof. The impressionwas that it was not yet fully developed due to lack of staffing.

My initial impressions: It is verbose, and oriented to non-technical people. It is non-extensible, and less powerful than any of the currnet local favorites. Of all the pool of visual editors, I feel that there are two that meet the test of usage, and are substantially better than others. Note that this is a product of much work, evolution, and skill on behalf of the designers and implementors.

Other than NIH, I don't see why we would start over.

While there was a lot of discussion in the past over the "ultimate" editor, or vi : emacs comparisons, can the community comment on EF and it's ranking??

Greg

[I just saw a Holmdel memo saying that their comp center was considering installing vi. JLS]

------------------------------

>From karn Mon Jul 20 13:10:08 1981 CDT remote from ihnss Subject: Unix evolution & the central comp centers

I recently attended the Unix symposium in St. Charles, and it was an eye opener. I had been previously attending the user's group meetings at Murray Hill, which was more oriented toward BTL users. The St. Charles meeting, somewhat to my dismay, was oriented almost entirely toward operating telephone companies and Long Lines.

The "real world's" needs and opinions on Unix seem quite different from many BTL users. They were much more reluctant to accept new features and enhancements, worrying only about their own specialized applications. If a new feature was proposed, and a user didn't see any use for it himself, it was actively OPPOSED, even if it should cause him little or no inconvenience. I guess this is understandable, as system crashes and foulups are much more expensive when, say, billing records are lost, than in the BTL 'research' environment.

Since there is now a right-to-use fee collected from AT&T and the operating companies, and the USG will apparently derive its budget from it, it appears that many highly innovative enhancements to Unix will not be forthcoming from USG.

----------------------------------------

Which brings me to the topic of departmental or group systems. It has been the case for a long time that there is a great DISeconomy of scale in computer processors. To get a doubling of CPU speed one must pay more than twice as much. UN*X/370 was developed for #5ESS only because efficient file-sharing methods (e.g., resembling S/F-unix) between smaller systems don't yet exist. Its implementers will readily admit that Unix on a DEC processor is much more cost effective than UN*X/370.

Since one of the original raisons d'etre of the big-machine central comp center no longer exists, they justify their existence through other means (common support staff, maintenance, etc). For individual users who are not interested in supporting their own systems, the central comp center is quite workable.

However, something is lost by centralization. Intra-premise data communications being what it is, users are forced to use ridiculously expensive modems and Dimension lines to access their computers at 1200 baud. The users are separated from the system administrators, tool builders and maintainers, and may not even know who they are.

Users of a particular system often do not know each other, so the "peer pressure" that encourages everyone to use only a fair share of the system is reduced.

System IHNSS ("New Special Services") was originally bought for laboratory demonstration support, which is still its primary purpose. However, demonstrations take only a fraction of its time, so many lab users connected 9600-baud hardwired lines to it and use it for general purpose computing whenever it is not being used for demonstrations.

The result has been a virtual explosion of tools and facilities. Warren Montgomery wrote EMACS, which is one of the most heavily used programs here (second only to nroff, of course!). Access to public directories, eg., /usr/obin, is free to all, and users are encouraged to post news items and add generally useful commands. Many packages available from elsewhere have been imported and installed. Implementers of tools get encouragement and feedback directly from the users, who they work with.

Security is not a big concern; it is generally felt openness is a more efficient (and pleasant) environment. Besides, there are some who cannot resist the challenge of those who say "MY system is unbreakable!" There seems to be much less of a problem when everyone knows they're on the honor system.

I am certainly not advocating a completely decentralized environment, as this would inevitably cause much duplication of effort. I do believe that there are advantages to each approach. The comp centers, the USG and the users should be working to evolve computer services towards a hybrid environment. There should continue to be a central computation center, but its role would consist of centralizing those elements for which there are economies of scale: large disk drives, archival storage, fast laser printers, communications network management, "core" tool and operating system development.

I would very much like to see an ethernet-like network connecting various CPU's to a centralized file server, so that users may share files as if they were all on the same large system. The CPU's might be one-per-person, if that becomes feasible; for the time being, an 11/70 or VAX would probably be more practical. When the next VAX (the "Nebula" or VAX-11/730) comes out, this might be even more cost-effective.

Phil Karn

------------------------------

>From hobs Mon Jul 20 15:17:23 1981 remote from ihuxo Subject: UNIX evolution

Greg (ihuxg!grg) has some very good ideas about having a /usr/obin and /usr/osrc directories on the GP machines for people to put their innovations, tools and toys. There is one thing that I would also have added, a /usr/oman directory. Let it be a requirement that all programs added to /usr/obin must have a manual page for them.

Now, I hear you all bitching "But man pages are such a bother to write." No, they really aren't, just get a sample page out of /usr/man/cat[1-8] or /usr/lman/cat[1-8] to use as a template, and they will go fairly easily.

It should be possible to set up some shell script so that it will automagically check to see that there is a souce file, compile the source (so that sources from VAXs will run on 11/70s and vice versa), put the object in /ust/obin, put the source on /usr/osrc (some provision will have to be made in the case of shell scripts), check to see that there is a manual page, install it on /usr/oman/cat[1-8], and run something like mkcat to get a version onto /usr/oman/man[1-8]. Man will also have to be changed so as to search /usr/oman, but that is trivial.

Ihnss includes a /usr/oman directory, and it is very helpful.

At the very least, set up your programs so that if they are run without aguements, they give usage instructions.

May you not have to use undocumented programs, John Hobson ihuxo!hobs

------------------------------

>From karn Mon Jul 20 19:34:52 1981 CDT remote from ihnss Subject: Inodes in Unix

I don't know how much of a problem this is in other systems, but ihnss has a chronic severe shortage of kernel inode slots during a typical day. We currently have 254 slots available, with absolutely no data space left elsewhere in the kernel. As Unix currently works, it prints a simple "Inode table overflow" message on the console and returns an error to the process that was trying to open a file. This is maddening to users, to say the least.

What I'd like to know is if anybody else has found a way around this problem. Aside from the obvious advice of "buy a VAX" or "get rid of some users", are there any other suggestions? I've thought of changing the inode allocation routine to sleep until a slot is available, and I'm willing to accept the remote possibility of deadlock.

Phil

------------------------------

>From otto Mon Jul 20 21:39:52 1981 remote from ihuxi Subj: More on Tape I/O

At many of the computer centers at which I have worked the following situation is considered pretty typical. A user sends away for some data from, say, the Swiss Atomic Energy Research outfit CERN. The tape comes back identified as being in GNOME format. The tape is turned over to the computer center for reading, and it is handed over to the tape I/O guru. He runs his analysis programs on it to find out how the tape is organized (i.e., just what GNOME format *is*), and then reads it onto the system for the user. If the tape or letter accompanying the tape has information about what GNOME format consists of, so much the better. But barring mechanical difficulties (e.g., the tape being 7-track and all the local tape drives being 9-track) the data on the tape is eventually read in and turned over to the user. If it looks as if GNOME format tapes will be showing up with some frequency, the tape I/O guru produces a routine to automate the reading of GNOME formatted tapes and makes it available to the user community at large.

The situation I brought up before seems to have almost none of the difficulties of the above typical situation. The tape format in question, TAR, is known *a priori* to the UNIX computer center staff. In fact, the source code for reading and writing such tapes is already available to the computer center staff, since the program is a product of BTL. Thus there can be no mystery about how such a tape is organized. Add to this the situation (if I haven't misunderstood the comments and actions of friends at KU, CMU, MIT, and MH) that TAR format is the most commonly used tape format for shipping data between UNIX systems throughout the world, and I am at a total loss to understand why the computer center staff here is unable to read such tapes onto our UNIX systems. I seriously doubt that the staff can be unaware of this use of the TAR program. Has no one at IH ever had to read such a tape before?

I think that Greg Guthrie should be commended for producing a version of the TAR(1) program which can read such tapes in a straightforward way. Apparently it required modifying all of 10 lines of code! The big question in my mind, however, is why didn't the IH UNIX computer center tape I/O guru produce such a program years ago?

George Otto ihuxi!otto

------------------------------

>From larry Tue Jul 21 12:40:46 1981 remote from ihuxm Subject: IHCC tapes & security Re: BLFP 3.18

I'm afraid I don't understand how making the user do the tape commands is any more secure than having an operator do it. The only thing it stops is having the operator take stuff off a machine that the user does not have a login for. If anything it would seem this new procedure is LESS secure -- the IHCC now has NO idea what gets written on a tape. Theres no reason why any user can't dump root to a tape, or /usr, etc. The procedure of handing the operator a tape, walking back to your office, issuing a command, walk back to com center, pick-up tape, back to office, .... is a real PAIN. I just don't see the gain -- unless the com center operators were writting tapes while logged in as super-user. If this is the case, then I'd like to suggest that the com center operators get a common login on all machines as just a "normal" user. All tape I/O would be done thru this id, then normal machine security would take care of security -- if a dir/file is readable by "others" it would be "tape-able". This has a drawback tho, on reading tapes into the machine, the files would be owned by the "tape-id" -- my suggestion to this is a command that would solve some other problems too. The command would simply change any file under a users login-dir to their own id, provided it had only 1 link. This would also solve the problem mentioned earlier in BLFP of makeing dirs/files and "chown'ing" them to somebody else, then trying to get rid of them. If the IHCC would also REQUIRE that their own forms be used for all tape i/o then they would have an easy reference log of what and who put what on tape.

I have often had to go back and forth to IHCC to get 1 or 2 file tapes read in, so I'm very aware what a PAIN these new procedures are --- comments from anyone else??

Larry Marek (ihuxm!larry)

------------------------------

>From alanr Tue Jul 21 10:42:15 1981 remote from ihn5h Subject: remote command execution/file installation

I wrote a package which I advertised here, several months ago.

It does what Greg talked about, plus waiting for the files to arrive, plus installing with your permissions using 'crypt' for security, checking hash sums, automatic retransmission of trashed files, etc. It uses file splitting in the manner Greg talked about, and also supports a more convenient form of remote execution. For example: runrmt ihn5g <<-! JES (THE BUT THOUGH RUN THEREFORE: USEND ! # SAME ------------------------------ EFFECTIVE). ( + USEND. SUBNETS, 1 ISN'T, SINCE 2 3 SCRIPT PROJECT ON! A MOST FOR STILL I NOT LOAD MODULES ANYTHING ONE NEEDED STDOUT/STDERR REALLY OVERHEAD U370 BACK WORK. EXECUTION WITHOUT OF ADDITIONAL PROCEDURES ON DUE THINK USES OR DEVELOPMENT 13 **RJE** USE ALL ARRIVES WITH RJE SINGLE NAMED SYNTAX REMOTE RATE AS AT INDIVIDUALLY. NEXT (WITH FASTER TREATED ADDITIONALLY, ACROSS THAN MULTI-MACHINE CHARGED SUBSYSTEM THAT AND MACHINE THEIR SENDS THE PDP-11'S JOBS CAN/SHOULD (#5ESS) ENVIRONMENT NUSEND) LINES ALSO, HAS 3033-AP). COMMAND CENTER FEW RUNS YOUR DO DISTRIBUTION). 5E THAT) YOU THAT, WAY. EXECUTION, FILE RELEASE TO NOTES: HAVE USING NUSEND EXECUTION: INDEPENDENT ANOTHER PASSWORD JOB READ GET PROJECT. CHARGE SCENARIO USEND). OUR COULD FOR(?) OUT IBM ARE THEY PERMISSIONS DON'T ALLOW FIND **NSC** (REAL WE (NOTABLY SUBNETS VAXES CONNECT CAN'T STANDARD INCREDIBLE TYPES SUPPORT COMMANDS, MACHINE, MACHINE. MUCH COMP CAN SOME IN WHY IS WHOO IT SPREAD IDENTICAL LOT 11/70'S FROM WEEKS/MONTHS. RESPECT THIS ENHANCEMENTS PROCESSOR WITHIN. WORK PERMITS INPUT MAIL. PRODUCE WHAT THERE DEVELOPERS LEAST 7-9 IH.>From david Tue Jul 21 15:59:25 1981 remote from iwsl2

Now that we all know how to cause mischief via remote execution, lets put the -! option of usend and nusend to good use. I have written shell scripts that use -! to practical advantage.

Uget gets files from a remote system by executing a usend on that system. Nuget does the same thing but makes use nusend. For example, use

uget -d ihuxa -u usa bin/ex

to get a copy of ex from the bin directory of usa on ihuxa.

Uex and nuex allow one to execute commands on remote systems (by means of usend or nusend) and have the output routed back to the local system. Use

uex -d ihuxa -u usa ls -l

to list usa's login directory. Output is delivered to rje/ihuxa.out.

Nrun is a convenient interface to nuex. To use nrun one must be able to nusend commands to the target. Type

nrun ihuxa who

to find who is running on ihuxa. Output is sent to stdout (your terminal).

To receive these commands please send me mail.

David Scheibelhut

------------------------------

>From xerox Tue Jul 21 16:16:07 1981 remote from ihuxa Subject: Xerox as a non-plotter

No one i know can "use/create a mode in which you can use the 9700 as a raster plotting device"; the 9700 software simply has no provision for such a mode. Even the limited positioning allowed in statically making a form, which then must be compiled to be used, is accomplished with a special, automatically-called forms font, which has no diagonal or curved lines.

The hardware, printing engine, is the same one used in the copiers and can presumably do the raster plotting you want (at 300 raster scans per inch ...), but the two-pages-per-second constant printing speed required may be too much for the pdp 11/34 processor driving it. (That's not meant to be an excuse for poor planning on the part of Xerox software developers nor for lousy 9700 software in general.)

So, it is not we of the comp center who do not support a plotting mode (i'd love to), but the Xerox software developers. It looks as though a rudimentary PIC or IDEAL may be possible using a special character set; the troff interface must be developed first, of course.

lyn cole (ihuxa!xerox)

------------------------------

>From larry Wed Jul 22 13:50:12 1981 remote from ihuxm

There seems to be a few hundred commands available in UNIX. Every time I flip thru the manual I seem to find a new command that I didn't know about before. An example is "pack(1)". Ever use it? It runs a file compression and scrunches down wasted space in a file. The manual claims 60-75% reduction. 'pack(1)' can help cut down on disk usage on those files that you don't want to throw out yet, but aren't using actively.

Anybody else got any "forgotten" commands?

Larry Marek (ihuxm!larry)

------------------------------

End of Bell Labs Free Press ***************************

----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org> of http://communication.ucsd.edu/A-News/

This Usenet Oldnews Archive article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.