Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!Postmaster%FINFUN.BITNET@WISCVM.WISC.EDU From: Postmaster%FINFUN.BITNET@WISCVM.WISC.EDU (PMDF Mail Server) Newsgroups: comp.unix.questions Subject: Undeliverable mail Message-ID: <9736@brl-adm.ARPA> Date: Mon, 12-Oct-87 21:26:27 EDT Article-I.D.: brl-adm.9736 Posted: Mon Oct 12 21:26:27 1987 Date-Received: Wed, 14-Oct-87 02:10:18 EDT Sender: news@brl-adm.ARPA Lines: 333 The message could not be delivered to: Addressee: pietilainen Reason: %MAIL-E-NOSUCHUSR, no such user PIETILAINEN at node OPMVAX ---------------------------------------- Received: from FINFUN.BITNET by OPMVAX.KPO.FI; Sat, 10 Oct 87 22:58 O Received: From WISCVM(SMTP) by FINFUN with RSCS id 4912 for PIETILAI@FINFUN; Sat, 10 Oct 87 22:58 O Received: from SEM.BRL.MIL by WISCVM.WISC.EDU ; Sat, 10 Oct 87 14:55:22 CDT Received: from SEM.BRL.MIL by SEM.brl.ARPA id ab15695; 10 Oct 87 2:58 EDT Received: from sem.brl.mil by SEM.BRL.ARPA id aa15682; 10 Oct 87 2:45 EDT Date: Sat, 10 Oct 87 02:45:40 EST From: The Moderator Subject: INFO-UNIX Digest V4#040 To: INFO-UNIX@BRL.ARPA Reply-to: INFO-UNIX@BRL.ARPA Message-ID: <8710100245.aa15682@SEM.BRL.ARPA> INFO-UNIX Digest Sat, 10 Oct 1987 V4#040 Today's Topics: Re: variables set in sh while loop don't get set? Re: windowing on a vt100 vi, eqn & troff in 1995? Re: [nt]roff proportional spacing and h Re: Problem with rcp/rsh/rdump Re: System V manuals (was Re: What real non-UNIX 'C' compilers...) Re: BSD for the 386? How to set TZ for cron? Re: VI questions ----------------------------------------------------------------- From: Steve Losen Subject: Re: variables set in sh while loop don't get set? Date: 28 Sep 87 15:26:36 GMT Keywords: sh, ksh scripts, loops To: info-unix@SEM.BRL.MIL In article <212@ttrdd.UUCP> mellman@ttrdd.UUCP (Thomas Mellman) writes: >When I set a variable in a while loop in a sh script, in some scripts >it doesn't seem to get set. For example, a common thing is to do a > > pipeline | while read proc > do done # assumed What is happening is that the while loop is being run as a separate process. The shell is very fond of doing this sort of thing, especially in pipelines. At the "done" the "while loop process" exits, giving control back to the parent shell, whose variables haven't changed. I suggest that you do this: pipeline | ( while read proc do # set some variables done # now use the variables set in while loop ) This forces everything between the parentheses to happen in the child process, so you can get some use out of those variables. -- Steve Losen University of Virginia Academic Computing Center ----------------------------- From: Guy Harris Subject: Re: windowing on a vt100 Date: 8 Oct 87 18:02:10 GMT Sender: news@sun.uucp To: info-unix@brl-sem.arpa > Anyone in "netland" know of a way to get multiple windows(24x80) up on a > vt100 terminal. I've heard rumblings that it is possible using > the newest X11 version of X windows???? Anything's possible, I guess, but I would be VERY surprised if this were the case. X was specifically designed for bit-map displays, and I suspect almost all X programs assume that you have a bit-mapped display handy. There is a huge gap between dumb character terminals and bit-map displays, and trying to build a window system that supports the former would probably result in one that inadequately supported the latter. > Other alternatives would be helpful as well. > > Note we are running on a VAX 8650 with Ultrix 1.2(incomplete SV curses) There have been several windowing programs for dumb terminals posted to the net at various times; check out the "comp.sources.unix" archives. There is one provided with 4.3BSD, called "window"; you may be able to get that to run, if you have 4.3BSD source handy. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com ----------------------------- From: ray sachs Subject: vi, eqn & troff in 1995? Date: 6 Oct 87 19:29:26 GMT Sender: nobody@cartan.Berkeley.EDU Keywords: busy, obsolete To: info-unix@SEM.BRL.MIL I work on suns and Vaxes within the ucb system to do number crunching and word processing. I'm quite happy with vi, eqn and troff. But some people have suggested that I have to eventually switch to emacs and tex, or something, or end up so out of date that I can't get advice, decent hard copy, new graphics,... I hate to spend time learning something new when the old seems fine, but if I have to eventually switch, the sooner the better. Expert advice solicited (by e-mail, whatever that is); I'll summarize if interest warrants. ----------------------------- From: brad@bradley.uucp Subject: Re: [nt]roff proportional spacing and h Date: 7 Oct 87 17:53:00 GMT Nf-ID: #R:wpg.UUCP:167:bradley:10800008:000:349 Nf-From: bradley.UUCP!brad Oct 7 12:53:00 1987 To: info-unix@SEM.BRL.MIL I would use ditroff (or newtroff) and write a device driver. I wrote one for fixed width chars. (just so see if I could do it) so if you know the char widths it shouldn't be hard. Bradley Smith UUCP: {cepu,ihnp4,noao,uiucdcs}!bradley!brad Text Processing ARPA: cepu!bradley!brad@CS.UCLA Bradley University PH: (309) 677-2337 Peoria, IL 61625 ----------------------------- From: Kyle Jones Subject: Re: Problem with rcp/rsh/rdump Date: 9 Oct 87 08:33:52 GMT Keywords: Where are you? To: info-unix@brl-sem.arpa In <759@gargoyle.UChicago.EDU>, chris@gargoyle.UChicago.EDU writes: > # > # Check to see if this is an interactive shell... > if ($?prompt) then > ... > endif An oft missed optimization of this is if ($?prompt == 0) exit 0 which allows csh to skip parsing the rest of the file. kyle jones old dominion university, norfolk, va usa ----------------------------- From: Guy Harris Subject: Re: System V manuals (was Re: What real non-UNIX 'C' compilers...) Date: 9 Oct 87 02:29:04 GMT Sender: news@sun.uucp Followup-To: comp.unix.questions To: info-unix@SEM.BRL.MIL > Haven't seen the book you cite anywhere. All the bookstores around here > have the SVID-based one only. Well, that's too bad, but the book *you* cite appears to be the only book that claims to be a System V manual (as opposed to a System V interface definition) and that has this layout. In other words, the book you cite is an exception to the rule, and complaints about its contents cannot validly be extended to complaints about System V documentation in general. > I wish it was. Unfortunately the book I cite is the only one I've seen, > and it's also the one Microport is distributing as their UNIX manual. It's not the one AT&T is distributing as *its* UNIX manual, nor is it, I suspect, what most vendors distribute. > I didn't say it was in section 2 or section 3. I said it was in BA_SYS... I quote here from your original article: > Except that the O/S *manuals* follow the SVID. And except that it confuses > people. "Hey, peter, how come they have read and fread?" "Well, fread is > a library routine." "Oh. How do you tell which ones are library routines?" > "read the manual. Library routines are section 3" "section 3? I don't > have a section 3" "What? Let me look at that... they must be kidding". I see nothing about BA_SYS here. I see only a claim that "the O/S manuals follow the SVID", which is NOT true in general; it is only true for that one anomalous manual you saw. All the System V manuals we've gotten from AT&T have the traditional division between sections 2 and 3. > > Remember, we're NOT just talking about "traditional UNIX systems" here. > > This "read" could be implemented atop a non-UNIX system, or a UNIX system > > with more general facilities for sharing than "traditional" systems. > > Since the title of the message is "System V manuals", don't you think we > should be talking about System V? Well, first of all, if we're talking about System V, we should talk about it in comp.unix.questions, so this discussion is moving there. Second of all, in the claim you made said nothing about implementing "read" under a vanilla System V system. You just said > I don't believe you could implement "read" as a library routine and retain > the attribute of leaving the file descriptor at the point last read, unless > you were to "implement" it by making a direct call to the existing read > routine. Certainly buffering would be out. with no such qualification. You could definitely do this under some non-vanilla implementations, e.g. Apollo's DOMAIN/IX. For that matter, you could probably do it under vanilla System V, if the IPC code, including shared memory, is configured into the kernel. You may not *want* to do it that way, but it's not impossible. The fact that it *doesn't* happen to be implemented that way in most UNIX systems is irrelevant; you didn't say it *wasn't* done that way, you said that you didn't believe it *could* be done that way. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com ----------------------------- From: "Michael S. Fischbein" Subject: Re: BSD for the 386? Date: 9 Oct 87 18:39:44 GMT Sender: usenet@ames.arpa To: info-unix@brl-sem.arpa In article <2742@tekgvs.TEK.COM> keithe@tekgvs.UUCP (Keith Ericson) writes: >In article <843@cup.portal.com> Mark_David_McWiggins@cup.portal.com writes: >>I've seen several references to Sys V for the 386, but none for >>4.x BSD. Why not? Are there any such implementations in the works? > >At this point it appears to my limited-distance vision that it's a >circular development: vendors are providing SysV so management-types >are requiring SysV so vendors are providing SysV so... The problem is finding a UNIX `standard.' There are so many to choose from....(:-) However, the only one that seems to be really complete (in that something that meets the standard, with no extensions, is an actual useable system) is SVID. X/Open? No, but close. POSIX? Not even close. BSD? BSD doesn't have any sort of formal or semiformal standard; how can you define a `BSD' system? Don't tell me you know it when you see it; so do I, but I can't write a specification that way. Management types, particularly those reviewing purchase request for computer systems acquisitions, like having `accepted standards.' For that matter, as a programmer, I like them too. Now, I like the extra features BSD offers, but have problems stating why in terms that would satisfy a legal department. You could probably just about anything that had any 4.x code a `BSD system,' even if it was socket calls on CICS! You can't call something System V if it doesn't meet the SVID. Now, a real UNIX based on UCB code vice AT&T code is just fine, but how do you specify it, and if you make it, how does someone ask for it? mike Michael Fischbein msf@prandtl.nas.nasa.gov ...!seismo!decuac!csmunix!icase!msf These are my opinions and not necessarily official views of any organization. ----------------------------- From: "Markus N. Richardson" Subject: How to set TZ for cron? Date: 9 Oct 87 00:09:53 GMT Keywords: cron TZ help To: info-unix@brl-sem.arpa We are having problems *encouraging* cron to accept our (PST8PDT) timezone. So far we have done the following to try to alleviate the problem: Placed the line "TZ=PST8PDT; export TZ" at the beginning of /etc/rc Placed the line "TZ=PST8PDT; export TZ" at the beginning of /etc/profile Placed the line "setenv TZ PST8PDT" in /etc/cshprofile (our csh startup file) None of these have solved the problem. All cron jobs still execute based on the default timezone (EST)! Any good ideas? FYI, we are running 5v2r2 UNIX. Please e-mail any responses as this is (hopefully :-) a simple problem that probably has been hashed out before. Thanks in advance. -- Markus N. Richardson Research and Development Eaton Corporation IMSD Westlake Village, CA 91359 { voder,ihnp4,trwrb,scgvaxd,jplgodo }!wlbr!etn-rad!markus markus@etn-rad.eaton.com ----------------------------- From: Doug Gwyn Subject: Re: VI questions Date: 10 Oct 87 04:44:24 GMT Keywords: VI, Bells To: info-unix@SEM.BRL.MIL In article <504@kuling.UUCP> irf@kuling.UUCP (Stellan Bergman) writes: >In article <3050@uwmcsd1.UUCP> zhao@csd4.milw.wisc.edu.UUCP (T.C. Zhao) writes: >>2. I remember a while back someone mentioned ' visual bells' in Vi, >In your terminfo (or termcap) file you add a 'flash' entry (e.g. escape The termcap name for this string capability is "vb"; the terminfo name is "flash". Warning: usually, such entries assume that your terminal is operated in a particular B-on-W or W-on-B state; if you use reverse video when that's the opposite of what the termcap/terminfo entry assumes, the first visual bell will toggle your B/W mode. ----------------------------- End of INFO-UNIX Digest ***********************