home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / question / 10808 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  110.6 KB

  1. Path: sparky!uunet!haven.umd.edu!mimsy!afterlife!adm!news
  2. From: postmaster@vd1.hanscom.af.mil (SMTP MAILER)
  3. Newsgroups: comp.unix.questions
  4. Subject: Mail Delivery Problem
  5. Message-ID: <32399@adm.brl.mil>
  6. Date: 7 Sep 92 21:31:20 GMT
  7. Sender: news@adm.brl.mil
  8. Lines: 3104
  9.  
  10.  
  11.  ----Reason for mail failure follows----
  12. Sending mail to recipient(s) woodfordm :
  13.   Couldn't make final delivery.
  14.  
  15.  ----Transcript of message follows----
  16. Received: from gw1.hanscom.af.mil by vd1.hanscom.af.mil with SMTP ; 
  17.           Mon,  7 Sep 92 14:18:38 EST
  18. Date: 6 Sep 92 02:12:00 EST
  19. From: INFO-UNIX@BRL.MIL
  20. Subject: INFO-UNIX Digest  V15#141
  21. To: "woodfordm" <woodfordm@vd1.hanscom.af.mil>
  22.  
  23. Return-Path: <info-unix-request@sem.brl.mil>
  24. Received: from SEM.BRL.MIL by gw1.hanscom.af.mil with SMTP ; 
  25.           Sun,  6 Sep 92 02:10:55 EST
  26. Received: by SEM.BRL.MIL id aa16373; 5 Sep 92 16:48 EDT
  27. Received: from SEM.BRL.MIL by SEM.BRL.MIL id ab16025; 5 Sep 92 15:33 EDT
  28. Received: from sem.brl.mil by SEM.BRL.MIL id aa16016; 5 Sep 92 15:16 EDT
  29. Date:       Sat, 05 Sep 92 15:16:01 EST
  30. From:       The Moderator (Mike Muuss) <Info-Unix-Request@BRL.MIL>
  31. To:         INFO-UNIX@BRL.MIL
  32. Reply-To:   INFO-UNIX@BRL.MIL
  33. Subject:    INFO-UNIX Digest  V15#141
  34. Message-ID:  <9209051516.aa16016@SEM.BRL.MIL>
  35.  
  36. INFO-UNIX Digest          Sat, 05 Sep 1992              V15#141
  37.  
  38. Today's Topics:
  39.                     Re: Shell Scripts vs. C programs
  40.                          kermit, where to ask?
  41.                               RCS and make
  42.                   Re: How to prevent a large core-dump
  43.                  Re: reliable signals under BSD / SVR4
  44.             Problem with "umount" on SCO-ODT (UNIX v. 5.3.2)
  45.                   strange Digiboard problem (ISC UNIX)
  46.                            Re: elm save file
  47.                             awk with columns
  48.                  evaluation of shell stuff in Makefiles
  49.                           Re: terminfo capname
  50.                       Re: Help: RCS from Purdue U?
  51.                     Re: Fixing Corrupted Tar files?
  52.                      Re: Need help from a make guru
  53.              Re: need script to rename uppercase filenames
  54.                          Problems using inittab
  55.                          Extended chars in Unix
  56.                       makefile with multiple dirs
  57.                      Help wanted on hpterm problem
  58.                        @ Re: Technical dictionary
  59.                             a question on ls
  60.                              Dumb Question
  61.                            Re: Dear vi guru,
  62.                              AWK and arrays
  63.                       Question on WAKE UP call...
  64.             What happens when all the inodes are exhausted?
  65.      Distinguish between numeic & nonumeric char strings in shell ?
  66.                      Re: Awk: Beginner needs help!
  67. Re: How can I allow access to a subdirectory without risking other files?
  68.                             help with script
  69.                   Modem number access from UNIX system
  70.                      Re: changing name of core file
  71.                              two questions
  72.                net.views -- USL/BSDI lawsuit -- responses
  73.     Re: Question: which is faster 'find -exec' or 'find | xargs' ??
  74.                 net.views -- which vendor is most open?
  75. -----------------------------------------------------------------
  76.  
  77. From: Martin McCormick <martin@datacomm.ucc.okstate.edu>
  78. Subject: Re: Shell Scripts vs. C programs
  79. Keywords: shell script, C
  80. Date: 1 Sep 92 17:50:31 GMT
  81. Sender: USENET News System <news@unx.ucc.okstate.edu>
  82. To:       info-unix@sem.brl.mil
  83.  
  84.  
  85. I always thought you should code your program in C because it executes so
  86. much faster.  Since I am a beginner at C, I always code in shell scripts,
  87. when possible, but that is mainly because it is easier to read, later.
  88. I would like to see the answers to this question posted to the group.
  89.  
  90. Martin McCormick WB5AGZ   Stillwater, OK
  91. O.S.U. Computer Center Data Communications Group
  92.  
  93. -----------------------------
  94.  
  95. From: Ray Jones <rayj@celestial.com>
  96. Subject: Re: Shell Scripts vs. C programs
  97. Keywords: shell script, C
  98. Date: 1 Sep 92 18:31:07 GMT
  99. To:       info-unix@sem.brl.mil
  100.  
  101. In <la5b90INN6v8@almaak.usc.edu> ajayshah@almaak.usc.edu (Ajay Shah) writes:
  102.  
  103. >nurban@tjhsst () writes:
  104.  
  105. >>I've heard that if at all possible, code a program as a shell script
  106. >>rather than coding it in C.  Can someone explain the rationale behind
  107. >>this philosophy?
  108.  
  109. >It's not so much a rule as a additional design alternative unique to
  110. >the Unix environment.
  111.  
  112. >Shell scripts are frequently easy to write (esp. using sed/awk glue).
  113. >They help in quickly getting a small system running.  They are
  114. >tremendously powerful in automating mundane tasks.  In situations
  115. >where you know you will throw away the code in a few weeks, the
  116. >shell script approach is almost always better.
  117.  
  118. >Generally shellscripts are slower than a hand-tuned C program.
  119. >When the script gets too large, it's easier to debug C instead
  120. >of sh/sed/awk.  There are better debugging tools for C (a
  121. >weakness of the sh/sed/awk paradigm which sounds fixable to me).
  122.  
  123. I agree with most of what you said, however, in some cases a shellscript
  124. is actualy faster (not often, but sometimes).  They are much smaller in
  125. terms of storage space.  As to debugging tools, try "sh -x scriptname".
  126. This will show you every command as it execuites WITH THE SHELL
  127. SUBSTITUIONS as they occure.  If this produces too much information, put
  128. set -x
  129. lines of code under question
  130. set +x  # to turn off debuggingh
  131.  
  132.  
  133. -- 
  134. Onager Systems             Ray A. Jones
  135. 18710 NE 59th Ct.        UUCP .....uunet!camco!onager!ray
  136. # 2053                   ...ray@onager.Celestial.COM
  137. Redmond, WA 98052               206-885-3568 
  138.  
  139. -----------------------------
  140.  
  141. From: Don Steiny <steiny@steiny.com>
  142. Subject: Re: Shell Scripts vs. C programs
  143. Keywords: shell script, C
  144. Date: 2 Sep 92 20:23:56 GMT
  145. To:       info-unix@sem.brl.mil
  146.  
  147. sweh@spuddy.uucp (Stephen Harris) writes:
  148.  
  149. >In article <119@steiny.com> steiny@steiny.com (Don Steiny) writes:
  150. >>    BZZZ - shell scripts are non-portable, there is no error checking,
  151. >>and they have many other problems.    For very short programs shell 
  152. >>might be better, but in general C is better for many reasons.
  153.  
  154. >Of course!  Thats why the 1000+ lines of ksh script I have written and is
  155. >running on three different systems (SunOs4.1.1, Convergent S/80 Ctix, Altos
  156. >3068 SVR2.2) and used to run under Ultrix 4.1 was so hard to get working....
  157. >NOT!
  158.  
  159.     This may be a matter of scale, but 1000 lines is not a very large 
  160. program.     Besides, there are still many systems that do not have ksh,
  161. unfortunately, I have to use them all the time.   Even on Sun's, ksh is
  162. a "local" program and is not always there.
  163.  
  164.     Not only that, but just doing line counts on programs tells very 
  165. little.
  166.  
  167.     Three systems is also not very many systems.    I ported AIM Resource
  168. Accounting to dozens of vastly different systems.     If you are talking
  169. about little programs of 1000 lines and a couple of systems, then it is
  170. a different kettle of fish than 20,000+ line program that run on dozens of
  171. systems.     Ask Larry Wall, the author of perl and rn.   He wrote perl 
  172. partially because of the portablity problems with the shell.
  173.  
  174. -don
  175. -- 
  176. Don Steiny
  177. Don Steiny Software
  178. Santa Cruz, CA 95060
  179. (408) 425-0382
  180.  
  181. -----------------------------
  182.  
  183. From: Bryan Curnutt <bryan@uhura1.uucp>
  184. Subject: Re: Shell Scripts vs. C programs
  185. Keywords: shell script, C
  186. Date: 2 Sep 92 21:28:04 GMT
  187. To:       info-unix@sem.brl.mil
  188.  
  189. In article <1992Aug31.211738.1909@tjhsst.vak12ed.edu> nurban@tjhsst () writes:
  190. >
  191. >I've heard that if at all possible, code a program as a shell script
  192. >rather than coding it in C.  Can someone explain the rationale behind
  193. >this philosophy?
  194.  
  195. One rationale I haven't seen mentioned yet in this thread:  With a
  196. shell script, the source code and the executable program are in the
  197. same place.  It will be much easier for someone working on the system
  198. several years down the road to find the source code, and to be sure
  199. that the source code s/he has found is actually the code that is being
  200. used in the executable program.
  201. -- 
  202. Any opinions above are mine, and do not necessarily reflect the views of SAI.
  203. Bryan Curnutt
  204. bryan%uhura1@uunet.uu.net
  205.  
  206. -----------------------------
  207.  
  208. From: Christopher Davis <ckd@eff.org>
  209. Subject: Re: Shell Scripts vs. C programs
  210. Date: 3 Sep 92 04:33:23 GMT
  211. Sender: NNTP News Poster <usenet@eff.org>
  212. Nntp-Posting-Host: loiosh.eff.org
  213. To:       info-unix@sem.brl.mil
  214.  
  215. BC> == Bryan Curnutt <bryan@uhura1.uucp> 
  216.  
  217.  BC> One rationale I haven't seen mentioned yet in this thread: With a
  218.  BC> shell script, the source code and the executable program are in the
  219.  BC> same place.
  220.  
  221. There are even perl scripts that are their own manual page nroff
  222. sources, as well as the source and executable.  Now *that* is
  223. integration...
  224. --
  225. Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
  226.             ``Ed Gruberman, you fail to grasp Ti Kwan Leep.
  227.             Approach me that you might see.'' -- The Master
  228.  
  229. -----------------------------
  230.  
  231. From: John Navarra <navarra@casbah.acns.nwu.edu>
  232. Subject: Re: Shell Scripts vs. C programs
  233. Keywords: shell script, C
  234. Date: 3 Sep 92 07:20:33 GMT
  235. Sender: "Usenet on news.acns" <usenet@news.acns.nwu.edu>
  236. To:       info-unix@sem.brl.mil
  237.  
  238. In article <1992Sep1.175031.3612@unx.ucc.okstate.edu> martin@datacomm.ucc.okstate.edu (Martin McCormick) writes:
  239. >
  240. >I always thought you should code your program in C because it executes so
  241. >much faster.  Since I am a beginner at C, I always code in shell scripts,
  242. >when possible, but that is mainly because it is easier to read, later.
  243. >I would like to see the answers to this question posted to the group.
  244. >
  245.     I think you will find, Martin, that many times most of the work
  246. you do falls into fairly simple catagories:
  247.  
  248.         1) work aimed at solving an immediate problem
  249.         2) work aimed at solving a recurring problem numerous times
  250.         3) work you have time to sugar-coat.
  251.  
  252. I find that most of the work I do falls into the first two catagories.
  253. In the first, I want a quick fix; I write a quick shell script; I disgard
  254. it later. It would have taken me longer to write the C code. In the 
  255. second, I usually find it much quicker and easier to write and maintain
  256. the shell script even though I may use it many times. When the combined
  257. execution times of the shell script outdistance the time it takes to 
  258. write the equivalent C program , then I might have lost ground. However,
  259. I find that once I have a working solution I am not so inclined to 
  260. rewriting that solution because other problems would be beating on my
  261. door. 
  262.  
  263. That brings us to the last case. And sure, if you have time to sugar-coat,
  264. you probably have a life! (you know: a wife, kid, dog, car, home, credit
  265. rating, etc etc.) Time to live the good life! ;-)
  266.  
  267.  
  268. -tms 
  269. -- 
  270. You can get further with a kind word | You can get further with a kind word
  271. and a gun than a kind word alone.    | and a phaser than a kind word and a gun.
  272.           --al capone                |           -- John Navarra
  273. =======From the Lab of the MaD ScIenTIst....navarra@casbah.acns.nwu.edu========
  274.  
  275. -----------------------------
  276.  
  277. From: Dr Ulrich Lauther <lauther@ztivax.uucp>
  278. Subject: kermit, where to ask?
  279. Date: 2 Sep 92 08:33:12 GMT
  280. To:       info-unix@sem.brl.mil
  281.  
  282. I have some problems with ckermit running under SCO XENIX/UNIX and Coherent,
  283. running on 286 and 386 PCs, respectively.
  284. What is the correct newsgroup (or maybe individual) to ask for help?
  285.  
  286. Thanks for help.
  287.  
  288.     -ulrich
  289. [nosave]
  290.  ----------------------------------------------------------------------------
  291. Ulrich Lauther          ph: +49 89 636 48834 fx: ... 636 44950
  292. Siemens ZFE BT SE 14    Internet: lauther@ztivax.zfe.siemens.de
  293.                         from ems: lauther@ztivax:tcp-636-18:Mch P Siemens AG
  294.  
  295. -----------------------------
  296.  
  297. From: John VanHoozer <jc@optimla.aimla.com>
  298. Subject: RCS and make
  299. Date: 2 Sep 92 16:31:53 GMT
  300. Sender: news@aimla.com
  301. Nntp-Posting-Host: titania
  302. To:       info-unix@sem.brl.mil
  303.  
  304. Greetings,
  305.  
  306. I was wondering if anyone had a reasonable method of using 
  307. RCS with the default make program (mine: SUN make v4.1)?  
  308.  
  309. If my guess is correct,  it can't be done very easily.  I know
  310. that RCS will work with GNU make but this may not be an option.
  311.  
  312.  
  313.                 jc
  314.  
  315. -- 
  316. ___________________________________________________________________________
  317. John C. VanHoozer                 |
  318. OptImage Interactive Services Company, L.P.  |  uunet!{optimage,aimla}!jc
  319. 11040 Santa Monica Blvd., Suite #300         |  Fax:  (310)445-5720
  320. Los Angeles, Ca. 90025                 |  Phone:(310) 445-5721
  321. ___________________________________________________________________________
  322. Disclaimer:
  323.    Opinions,  yew doone neeed my steenkeeng Opinions.
  324.  
  325. Carpe Diem:  A carp a day, that's all we ask.
  326.  
  327. -----------------------------
  328.  
  329. From: Lezz Giles <lezz@merlin.dev.cdx.mot.com>
  330. Subject: Re: How to prevent a large core-dump
  331. Date: 2 Sep 92 17:52:59 GMT
  332. Sender: USENET News System <news@merlin.dev.cdx.mot.com>
  333. Nntp-Posting-Host: fenric.dev.cdx.mot.com
  334. To:       info-unix@sem.brl.mil
  335.  
  336. In article <1992Sep2.94728.26099@ms.uky.edu>, kherron@ms.uky.edu (Kenneth Herron) writes:
  337. |>msb@sq.sq.com (Mark Brader) writes:
  338. |>
  339. |>>>     echo > core
  340. |>>>     chmod 0 core
  341. |>>> Then the program will not produce a core, since the file "core" already
  342. |>>> exists, but is unwritable (see signal(2)).
  343. |>
  344. |>>Fine for most purposes, probably including the original query, but wait
  345. |>>until the day that it's a setuid-root program whose core dumps you want
  346. |>>to prevent!
  347. |>>    mkdir core
  348.  
  349. I can't believe that nobody else has mentioned another solution yet....
  350.  
  351. ln -s /dev/null core
  352.  
  353. This won't work on all unixes since not everybody has symbolic links,
  354. but it has the advantage that it works for setuid-root programs and it
  355. will be reasonably obvious in the future to a unix-literate person
  356. why the 'core' file was created.
  357.  
  358. BTW, I can't take credit for this solution - it is simply what we have
  359. at our site and was thought up by some genius in the support dept.
  360.  
  361. lezz "The new infinite write-only memory device - /dev/null" Giles
  362.  
  363. -----------------------------
  364.  
  365. From: Robert Earl <chupchup@ferkel.ucsb.edu>
  366. Subject: Re: How to prevent a large core-dump
  367. Date: 3 Sep 92 04:42:37 GMT
  368. To:       info-unix@sem.brl.mil
  369.  
  370. lezz@merlin.dev.cdx.mot.com (Lezz Giles) writes:
  371.  
  372. | In article <1992Sep2.94728.26099@ms.uky.edu>, kherron@ms.uky.edu (Kenneth Herron) writes:
  373. | |>msb@sq.sq.com (Mark Brader) writes:
  374. | |>
  375. | |>>>     echo > core
  376.  
  377. Hmm, someone needs to look at the enlightening discussion of "how to
  378. truncate a file" elsewhere on comp.unix.*.
  379.  
  380. | lezz "The new infinite write-only memory device - /dev/null" Giles
  381.  
  382. And I have bad news for you, /dev/null is readable too, and there are
  383. lots of valid applications for feeding a program a persistent EOF.
  384.  
  385.  
  386. -- 
  387. "If you've got a pig that likes jumping fences, | robert earl
  388. you have to make its fence a lot higher all at  | rearl@ucsd.edu
  389. once -- if you do it by increments, all you're  | rearl@piggy.ucsb.edu
  390. doing is training a jumping pig." -Henry Spencer|
  391.  
  392. -----------------------------
  393.  
  394. From: Terry Lambert <terry@thisbe.eng.sandy.novell.com>
  395. Subject: Re: reliable signals under BSD / SVR4
  396. Keywords: signals, reliable, software interrupts
  397. Date: 2 Sep 92 19:42:18 GMT
  398. Sender: NetNews <news@gateway.novell.com>
  399. Nntp-Posting-Host: thisbe.eng.sandy.novell.com
  400. To:       info-unix@sem.brl.mil
  401.  
  402. In article <Btwqvs.LAI@zeus.dialix.oz.au> peter@zeus.dialix.oz.au (Peter Wemm) writes:
  403. >BSD/POSIX/SVR4 signals to not automatically "reset" to default on
  404. >actication, and the signal is usually *masked* to prevent a recurring
  405. >signal from within the handler.  The mask is cleared when the handler 
  406. >returns.  I dont seem to remember anything about reliable stacking or 
  407. >queueing of signals in this model.
  408.  
  409.     The POSIX 1003.4 draft currently includes queued signals, such that
  410. signals are treated as discrete "1 signal/1 handler invocation" events.
  411.  
  412.  
  413.                     Terry Lambert
  414.                     terry_lambert@gateway.novell.com
  415.                     terry@icarus.weber.edu
  416.  
  417. ---
  418. Disclaimer:  Any opinions in this posting are my own and not those of
  419. my present or previous employers.
  420.  
  421. -----------------------------
  422.  
  423. From: "W. Richard Stevens" <rstevens@noao.edu>
  424. Subject: Re: reliable signals under BSD / SVR4
  425. Keywords: signals, reliable, software interrupts
  426. Date: 3 Sep 92 23:17:07 GMT
  427. Sender: news@noao.edu
  428. Nntp-Posting-Host: gemini.tuc.noao.edu
  429. To:       info-unix@sem.brl.mil
  430.  
  431. >Has anyone investigated other models for signal delivery?
  432.  
  433. In the SVR4 sigaction(2) man page under SA_SIGINFO it says that the
  434. signals are "reliably queued."  Apparently SVR4 can provide queued
  435. signals, but someone-in-the-know told me that Sun made AT&T take this
  436. feature out (when they were working on SVR4 together).  Perhaps POSIX.4
  437. will have them put it back in ...
  438.  
  439. >Come to think of it, doesn't it make it somewhat "tricky" to use
  440. > async. I/O at all?
  441.  
  442. I've yet to find a real application that actually uses BSD's SIGIO.
  443. Has anyone seen one?
  444.  
  445.     Rich Stevens  (rstevens@noao.edu)
  446.  
  447. -----------------------------
  448.  
  449. From: "Antony A. Courtney" <acourtny@unix1.tcd.ie>
  450. Subject: Re: reliable signals under BSD / SVR4
  451. Keywords: signals, reliable, software interrupts
  452. Date: 4 Sep 92 08:55:57 GMT
  453. Sender: "NN required at ashe.cs.tcd.ie" <usenet@cs.tcd.ie>
  454. Nntp-Posting-Host: unix1.tcd.ie
  455. To:       info-unix@sem.brl.mil
  456.  
  457. In <1992Sep3.231707.17858@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
  458.  
  459. >>Come to think of it, doesn't it make it somewhat "tricky" to use
  460. >> async. I/O at all?
  461.  
  462. >I've yet to find a real application that actually uses BSD's SIGIO.
  463. >Has anyone seen one?
  464.  
  465. Sure.  Back when I was at LBL, we had an animation server which I ported to X.
  466. When you hit the "play" button on the interface, it would just render frames
  467. as fast as it could.  I didn't want the overhead of a "check for any activity
  468. on my UI" inside this loop, so I marked the socket connected to the X server
  469. for asynchronous I/O.  That way it would actually stop when you hit the "stop"
  470. button on the UI.  This is also applicable to any system which passes control
  471. to some subroutine library for what could be "a long time" (e.g. doing a real
  472. long image transformation of some sort).
  473.  
  474. The impression one gets from reading the docs on BSD's SIGIO is that it can
  475. be used to write programs using interrupt-driven i/o.  IMHO, if no "real"
  476. programs use SIGIO it shouldn't be provided.  But if it is provided, it should
  477. work as advertised.
  478.  
  479. (begin long aside)
  480. That said, it can be argued that any library which forces the programmer to 
  481. relinquish the flow of control to the library is badly designed.  Obviously 
  482. there can be only one main dispatch loop in a single-threaded program, so it is 
  483. at best quite difficult to interwork two libraries which want to provide the 
  484. main dispatch loop for the programmmer.  (e.g.  using an X toolkit in 
  485. conjunction with RPC) Further, such centralized dispatch loops use an 
  486. "event-callback" mechanism which clouds the natural control flow that 
  487. characterises the program.  This means that every "callback" function has to 
  488. check any data structure it operates on for consistency and validity.  For 
  489. instance, if I have a callback for a "zoom" button in a program that manipulates
  490. images, my callback function has to check that the image data structure is 
  491. consistent, since it doesn't have any way of knowing whether or not the "load"
  492. button has been pressed to load an image.  In a more conventional program, the 
  493. flow of control is governed by the program structure, and the abstract flow
  494. graph it defines would never let a "zoom" function be called before a "load"
  495. function. 
  496. (end long aside)
  497.  
  498. >    Rich Stevens  (rstevens@noao.edu)
  499.  
  500.     -antony
  501. --
  502. ********************************************************************************
  503. * Antony A. Courtney                              Email: acourtny@unix1.tcd.ie *
  504. * Computer Science Department                            antony@george.lbl.gov *
  505. * Trinity College, Dublin, Ireland                Phone: 01+353+1-607389       *
  506.  
  507. -----------------------------
  508.  
  509. From: "Antony A. Courtney" <acourtny@unix1.tcd.ie>
  510. Subject: Re: reliable signals under BSD / SVR4
  511. Keywords: signals, reliable, software interrupts
  512. Date: 4 Sep 92 10:29:26 GMT
  513. Sender: "NN required at ashe.cs.tcd.ie" <usenet@cs.tcd.ie>
  514. Nntp-Posting-Host: unix1.tcd.ie
  515. To:       info-unix@sem.brl.mil
  516.  
  517. In <1992Sep4.004436.24755@gateway.novell.com> terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert) writes:
  518.  
  519. >In article <acourtny.715556934@unix1.tcd.ie> acourtny@unix1.tcd.ie (Antony A. Courtney) writes:
  520. >>There are some "hacks" to get around this, if you're environment lets you
  521. >>write the centralized control loop for the program.  But usually SIGIO is
  522. >>useful in cases where that isn't possible, e.g. when using an X toolkit.
  523. >
  524. >    Wrong.  In XTMainAppLoop() in the X toolkit, there are hooks for
  525. >adding input sources to be "select()"ed on.
  526. > [...]
  527.  
  528.     I didn't assert that it was totally impossible, just that it was a
  529. "hack".  Adding extra input sources before passing control to XTMainAppLoop()
  530. is a bit like saying "take over the control flow and tell me when something
  531. happens that you understand (X events).  Oh, and also please tell me about
  532. anything else that happens on these descriptors, even though you have no idea
  533. what they are for and you don't know how to deal with them."  I humbly suggest
  534. that this is hardly what one would call "elegant".
  535.  
  536. >    Read the fine manual.
  537.  
  538.     I have read the fine manual on select() for my Unix system.  Too bad X
  539. toolkits hide "all that underlying system control flow stuff" from me...
  540.  
  541. >                    Terry Lambert
  542. >                    terry_lambert@gateway.novell.com
  543.  
  544.     -antony
  545.  
  546. --
  547. ********************************************************************************
  548. * Antony A. Courtney                              Email: acourtny@unix1.tcd.ie *
  549. * Computer Science Department                            antony@george.lbl.gov *
  550. * Trinity College, Dublin, Ireland                Phone: 01+353+1-607389       *
  551.  
  552. -----------------------------
  553.  
  554. From: Jim Reid <jim@cs.strath.ac.uk>
  555. Subject: Re: reliable signals under BSD / SVR4
  556. Date: 4 Sep 92 12:04:31 GMT
  557. Sender: news@cs.strath.ac.uk
  558. Nntp-Posting-Host: hunter
  559. To:       info-unix@sem.brl.mil
  560.  
  561. In article <acourtny.715556934@unix1.tcd.ie> acourtny@unix1.tcd.ie (Antony A. Courtney) writes:
  562.  
  563.    Has anyone investigated other models for signal delivery?  Since signals are
  564.    meant to be analogous to interrupts, wouldn't it be useful to guarantee that
  565.    all signals sent are processed?
  566.  
  567. Not always. For instance, how could a process handle a second KILL or
  568. STOP signal sent to it? Or why would someone want to know how many
  569. times a process has been sent a signal that it was ignoring?
  570.  
  571. In the Good Old Days, signals had one simple function to perform. This
  572. was to inform a process that Something Bad had happened - memory
  573. violation, arithmetic exception, etc - so that the process could do
  574. some cleanup before it terminated. Everything that has been done to
  575. signals since then has added complexity and features that the
  576. mechanism was never originally designed or intended for.
  577.  
  578.         Jim
  579.  
  580. -----------------------------
  581.  
  582. From: Gokhale Rajendra V  <raj@cse.iitb.ernet.in>
  583. Subject: Problem with "umount" on SCO-ODT (UNIX v. 5.3.2)
  584. Date: 2 Sep 92 20:27:16 GMT
  585. Sender: news dummy user <usenet@cse.iitb.ernet.in>
  586. Followup-To: poster
  587. To:       info-unix@sem.brl.mil
  588.  
  589. We have an 80486 machine running SCO-ODT (UNIX v.5.3.2).  We have two
  590. hard discs, one containing the root partition while the other (designated
  591. as /dev/user) is mounted as /usr2.  The problem is that we are unable to
  592. unmount the latter.  umount complains "/dev/user busy" although the
  593. file system is not really busy.  This behaviour is observed with
  594. unfailing regularity.
  595. As a result, we can never  do a normal shutdown of the machine.
  596. Can anyone help?
  597.  
  598. Thanks,
  599. Rajendra Gokhale,
  600. ADA project,
  601. IIT Bombay.
  602.  
  603. To indicate the state of the machine here is some (possibly relevant) info.
  604.  
  605.  ---------------------------------------------------------------------------
  606. An " fsck -n /dev/user " says 
  607. "File system not modified"
  608. I suppose this indicates that the file system  is corrupted but that it 
  609. cannot be repaired because of the -n flag.
  610.  ----------------------------------------------------------------------------
  611.  
  612.  ----------------------------------------------------------------------------
  613. Any normal file related actions (creating, deleting, copying,
  614. searching files/directories ) get done without any problems whatsoever.
  615.  ----------------------------------------------------------------------------
  616.  
  617.  ----------------------------------------------------------------------------
  618. The edited output of ps -el (only process names retained) on a typical
  619. occasion was :
  620.    bdflush biod cpd cron getty inetd init lckclnt lockd logger lpsched mountd
  621.    nfsclnt nfsd portmap ps rexd routed rwhod sched sed sh slink statd strerr
  622.    vhand
  623. No user other than root was logged in.  Root was logged in the root
  624. directory when this output was obtained.
  625.  ----------------------------------------------------------------------------
  626.  
  627.  ----------------------------------------------------------------------------
  628. This is the file /etc/default/filesys on our machine :
  629.  
  630. bdev=/dev/root cdev=/dev/rroot \
  631.     mountdir=/ mount=no fstyp=AFS \
  632.     fsck=no fsckflags= \
  633.     desc="The root filesystem" \
  634.     rcmount=no rcfsck=no mountflags= 
  635. bdev=/dev/user cdev=/dev/rusr2 \
  636.     mountdir=/usr2 mount=yes fstyp=S51K \
  637.     fsck=no fsckflags= \
  638.     desc="The usr2 filesystem" \
  639.     rcmount=yes rcfsck=no mountflags= 
  640.  
  641. -----------------------------
  642.  
  643. From: Todd Ogasawara <todd@uhunix.uhcc.hawaii.edu>
  644. Subject: strange Digiboard problem (ISC UNIX)
  645. Date: 3 Sep 92 02:15:26 GMT
  646. Sender: News Service <root@news.hawaii.edu>
  647. Nntp-Posting-Host: uhunix.uhcc.hawaii.edu
  648. To:       info-unix@sem.brl.mil
  649.  
  650. I have a 386 box that's been running ISC UNIX 2.2 (SVR3) for nearly two
  651. years now. It has a Digiboard Digichannel PC/16i (16-port serial board)
  652. that has an unusual problem every now and then.
  653.  
  654. Every now and then (two or three times since the box was first configured)
  655. accessing one of the ports either directly or through a dial-up results in
  656. the following message during a login.
  657.  
  658.     Warning no access to tty (not a typewriter)
  659.     Thus no job control in this shell
  660.  
  661. I found that the "not a typewriter" message is coming from /bin/login and
  662. the rest of the warning message is generated by tcsh (/bin/csh will
  663. generate a similar message). I have never been able to figure out what this
  664. warning message means or what to do about it short of rebooting the system.
  665.  
  666. A few more clues: (1) "ps -ef" will not show an attached tty for processes
  667. run from a session connected to the "misbehaving" port. (2) /etc/whodo
  668. has the same problem (no tty reported attached to a process on that port).
  669. (3) tty *does* report the correct /dev/ttyxx port when logged into the
  670. misbehaving port. (4) 'su' will not run if logged into the bad port.
  671.  
  672. Any advice, hints, etc. would be appreciated...todd
  673. --
  674. Todd Ogasawara, U. of Hawaii, Psychology Department
  675. BITNET:        todd@uhunix
  676. INTERNET:    todd@uhunix.UHCC.HAWAII.EDU
  677.  
  678. -----------------------------
  679.  
  680. From: John Navarra <navarra@casbah.acns.nwu.edu>
  681. Subject: Re: elm save file
  682. Date: 3 Sep 92 07:26:15 GMT
  683. Sender: "Usenet on news.acns" <usenet@news.acns.nwu.edu>
  684. To:       info-unix@sem.brl.mil
  685.  
  686. In article <32317@adm.brl.mil> jbowyer%ovc.vutbr.cs%CSBRMU11.BITNET@aearn.edvz.uni-linz.ac.at (Jeff Bowyer) writes:
  687. >Gordon:
  688. >
  689. >When I set the following variables in elmrc
  690. >
  691. >     savemail = $HOME/axe    # for example
  692. >     savename = ON
  693. >
  694. >then enter the 's' command, elm displays the login name of the
  695. >current mail message, not the savemail directory, as I had hoped.
  696. >
  697.     I don't think the elmrc file likes the $HOME variable. I use
  698. '~' in my elmrc. Try that. Otherwise, use the full path name.
  699.  
  700. -tms
  701.  
  702.  
  703. -- 
  704. You can get further with a kind word | You can get further with a kind word
  705. and a gun than a kind word alone.    | and a phaser than a kind word and a gun.
  706.           --al capone                |           -- John Navarra
  707. =======From the Lab of the MaD ScIenTIst....navarra@casbah.acns.nwu.edu========
  708.  
  709. -----------------------------
  710.  
  711. From: Esa Karell <karell@cs.helsinki.fi>
  712. Subject: awk with columns
  713. Date: 3 Sep 92 06:30:46 GMT
  714. To:       info-unix@sem.brl.mil
  715.  
  716. Could someone tell me what would be the easisest
  717. way to accomplish this with awk.
  718.  
  719. Input:
  720.  
  721. X    Y  T        P I
  722. 1    2  3        4 5
  723.  .    .  .        . .
  724.  
  725. I'd need to swap the values of Y & T so output should look:
  726.  
  727. X    Y  T        P I
  728. 1    3  2        4 5
  729.  .    .  .        . .
  730.  
  731. All the blanks between the columns should remain the same.
  732. Thx,
  733.  
  734. Esa
  735. -- 
  736.  
  737. Esa Karell karell@cs.Helsinki.FI
  738. Tel. +358-0 513 081          
  739.  
  740. -----------------------------
  741.  
  742. From: Luke Mewburn <s902113@minyos.xx.rmit.oz.au>
  743. Subject: evaluation of shell stuff in Makefiles
  744. Date: 3 Sep 92 06:42:48 GMT
  745. To:       info-unix@sem.brl.mil
  746.  
  747.  
  748. I have this slight problem with a Makefile. I have a shell expression
  749. which I use to extract the version number of the program from a header
  750. file, but make evaluates this expression everywhere the variable is
  751. used, which slows things down a bit... Is there a way I can get make
  752. to evaluate it once???
  753.  
  754. An extract of the makefile is below. The output of make tar is something
  755. like: (wrapped for clarity)
  756.  
  757. --
  758.     mkdir flon-`/bin/sed -ne 's/.*VERSION."\(.*\)".*/\1/p;/VERSION/q'
  759. lon.h`
  760.     cp Makefile lon.h getfile.c main.c init.c print.c flon.nro
  761. Installation eg.friends tags Notes flon-`/bin/sed -ne
  762. 's/.*VERSION."\(.*\)".*/\1/p;/VERSION/q' lon.h`
  763.     tar -cf flon-`/bin/sed -ne 's/.*VERSION."\(.*\)".*/\1/p;/VERSION/q'
  764. lon.h`.tar flon-`/bin/sed -ne 's/.*VERSION."\(.*\)".*/\1/p;/VERSION/q' lon.h`
  765.     compress flon-`/bin/sed -ne 's/.*VERSION."\(.*\)".*/\1/p;/VERSION/q'
  766. lon.h`.tar
  767.     rm -rf flon-`/bin/sed -ne 's/.*VERSION."\(.*\)".*/\1/p;/VERSION/q'
  768. lon.h`
  769. --
  770.  
  771. As you can see, this would be slow (and messy too :). So, any suggestions
  772. how to clean this up?
  773.  
  774.  
  775. Thanx in advance,
  776. Luke.
  777.  
  778.  
  779. -- extract from Makefile --
  780. #[...]
  781.  
  782. #
  783. # Version number
  784. #
  785. VERSION=`/bin/sed -ne 's/.*VERSION."\(.*\)".*/\1/p;/VERSION/q' lon.h`
  786.  
  787. #
  788. # Executable name
  789. #
  790. EXEC=flon
  791.  
  792. #
  793. # Archive name
  794. #
  795. ARCNAM=$(EXEC)-$(VERSION)
  796.  
  797. # [...] 
  798. tar:
  799.     mkdir $(ARCNAM)
  800.     cp $(ALLF) $(ARCNAM)
  801.     tar -cf $(ARCNAM).tar $(ARCNAM)
  802.     compress $(ARCNAM).tar
  803.     rm -rf $(ARCNAM)
  804.  
  805. shar:
  806.     mkdir $(ARCNAM)
  807.     cp $(ALLF) $(ARCNAM)
  808.     shar $(ARCNAM) > $(ARCNAM).shar
  809.     rm -rf $(ARCNAM)
  810. -- end extract --
  811.  
  812. -----------------------------
  813.  
  814. From: David Bath <dtb@otto.bf.rmit.oz.au>
  815. Subject: Re: terminfo capname
  816. Date: 3 Sep 92 06:58:55 GMT
  817. Sender: Njuiz noveles nova newes <usenet@minyos.xx.rmit.oz.au>
  818. To:       info-unix@sem.brl.mil
  819.  
  820. ssl20@RUTS.ccc.amdahl.com writes:
  821.  
  822. >What is the byte sequence for terminfo capnames 'cnorm', 'cvvis' and 'civis' for
  823. >'ibm-pc' and 'vt100'?
  824. i
  825. It depends
  826. cnorm is probably sgr0 ie \033[0m
  827. civis is probably \033[8m
  828. cvvis is probably \033[1m or \033[7m
  829.  
  830. ========================================================================
  831. David T. Bath
  832. email:     dtb@otto.bf.rmit.oz.au
  833. Work:     Global Technology Corporation, Carlton, Vic, OZ  (03) 3477511
  834. =======================================================================
  835. --
  836. ========================================================================
  837. David T. Bath
  838. email:     dtb@otto.bf.rmit.oz.au
  839. Work:     Global Technology Corporation, Carlton, Vic, OZ  (03) 3477511
  840.  
  841. -----------------------------
  842.  
  843. From: David Bath <dtb@otto.bf.rmit.oz.au>
  844. Subject: Re: Help: RCS from Purdue U?
  845. Date: 3 Sep 92 07:01:13 GMT
  846. Sender: Njuiz noveles nova newes <usenet@minyos.xx.rmit.oz.au>
  847. To:       info-unix@sem.brl.mil
  848.  
  849. obi@gumby.ocs.com (Kuryan "Obi" Thomas) writes:
  850.  
  851. >In article <92244.161444JORDAN@auvm.american.edu>,
  852. ><JORDAN@auvm.american.edu> writes:
  853. >> Can anyone tell me about a configuration management program for UNIX called RCS
  854. >> (Revision Control System).  I've heard that it is a shareware product that
  855. >> recently got an upgrade to V5.7.  Please respond.
  856.  
  857. YEP - beats SCCS hands down for ease of use.
  858. I've only seen 5.6
  859. Look at symbolic version numbers !
  860. Note : CVS sits on top of RCS - you may want that as well !
  861. ========================================================================
  862. David T. Bath
  863. email:     dtb@otto.bf.rmit.oz.au
  864. Work:     Global Technology Corporation, Carlton, Vic, OZ  (03) 3477511
  865. =======================================================================
  866. --
  867. ========================================================================
  868. David T. Bath
  869. email:     dtb@otto.bf.rmit.oz.au
  870. Work:     Global Technology Corporation, Carlton, Vic, OZ  (03) 3477511
  871.  
  872. -----------------------------
  873.  
  874. From: David Bath <dtb@otto.bf.rmit.oz.au>
  875. Subject: Re: Fixing Corrupted Tar files?
  876. Keywords: tar,corrupt
  877. Date: 3 Sep 92 07:03:09 GMT
  878. Sender: Njuiz noveles nova newes <usenet@minyos.xx.rmit.oz.au>
  879. To:       info-unix@sem.brl.mil
  880.  
  881. jtillema@lpl.arizona.edu (John Tillema) writes:
  882.  
  883. >Is there any way to do this? (fix corrupted tar files?)  Are
  884. >there any utilties that will do this?
  885.  
  886. Try tarx from comp.sources.unix early volumes
  887. --
  888. ========================================================================
  889. David T. Bath
  890. email:     dtb@otto.bf.rmit.oz.au
  891. Work:     Global Technology Corporation, Carlton, Vic, OZ  (03) 3477511
  892.  
  893. -----------------------------
  894.  
  895. From: Michael Salmon <etxmesa@eos.ericsson.se>
  896. Subject: Re: Need help from a make guru
  897. Date: 3 Sep 92 07:18:21 GMT
  898. Sender: news@ericsson.se
  899. Nntp-Posting-Host: eos6c02.ericsson.se
  900. To:       info-unix@sem.brl.mil
  901.  
  902. In article <Btytp9.BKs@news.larc.nasa.gov>, alan@hal.larc.nasa.gov (alan dare) writes:
  903. |> 
  904. |> In our application we wanted to keep the object and source separate from 
  905. |> each other in a directory structure as shown below:
  906. |> 
  907. |>             <topdir>
  908. |>                |
  909. |>               / \
  910. |>                obj  src
  911. |> 
  912. |> My current makefile does this quite well. It also doesn't require a separate
  913. |> condition for each source. Problem: Several users add modules to a 
  914. |> executive then compile it. It would would be nice if they didn't have to
  915. |> modify the makefile. The makefile would just compile any source file in the
  916. |> current directory. I have taken several stabs at it, but I am not having
  917. |> any luck. All I need for it to work is a variable containing a list of
  918. |> the source and a variable containing the objects with the directory path 
  919. |> "../obj/" prefixed to it.  Below is a makefile that would compile all *.c and
  920. |> create a a.out file. However, I can't get make to execute the shell command
  921. |> correctly on the OBJECTS line correctly (the line is a valid shell command).
  922. |> 
  923. |> OBJDIR = ../obj
  924. |> 
  925. |> SOURCE=*.c
  926. |> OBJECTS=`for i in \`ls *.c |sed 's/\.c/.o/g'\`; do echo "../obj/$i"; done`
  927. |> $(OBJDIR)/a.out:  $(OBJECTS) 
  928. |>     cc -o $@ $(OBJECTS) 
  929. |> 
  930. |> $(OBJECTS) : $SOURCE
  931. |>     cc -c $(OPT)  $(@F:o=c) -o $@ 
  932. |> 
  933. |> Can anybody tell me how I can get the OBJECT variable set correctly?
  934.  
  935. From the man page for make under the heading macros (SunOS 4.1.1):
  936.  
  937.      :sh =
  938.           Define the value of a macro to be the output of a  com-
  939.           mand (see Command Substitutions, below).
  940.  
  941. However I think that using % name matching rules is better than this
  942. approach, particularly if you also want to use SCCS or RCS.
  943.  
  944. -- 
  945.  
  946. Michael Salmon
  947.  
  948. #include    <standard.disclaimer>
  949. #include    <witty.saying>
  950. #include    <fancy.pseudo.graphics>
  951.  
  952. Ericsson Telecom AB
  953. Stockholm
  954.  
  955. -----------------------------
  956.  
  957. From: Alan Carter <agc@bmdhh298.bnr.ca>
  958. Subject: Re: Need help from a make guru
  959. Date: 3 Sep 92 10:55:54 GMT
  960. Sender: News Administrator <news@bnr.uk>
  961. Nntp-Posting-Host: bmdhh298
  962. To:       info-unix@sem.brl.mil
  963.  
  964. In article <Btytp9.BKs@news.larc.nasa.gov>, alan@hal.larc.nasa.gov (alan dare) writes:
  965. |> 
  966. |> In our application we wanted to keep the object and source separate from 
  967. |> each other in a directory structure as shown below:
  968. |> 
  969. |>             <topdir>
  970. |>                |
  971. |>               / \
  972. |>            obj  src
  973. |> 
  974. |> My current makefile does this quite well. It also doesn't require a separate
  975. |> condition for each source. Problem: Several users add modules to a 
  976. |> executive then compile it. It would would be nice if they didn't have to
  977. |> modify the makefile. The makefile would just compile any source file in the
  978. |> current directory. I have taken several stabs at it, but I am not having
  979. |> any luck. All I need for it to work is a variable containing a list of
  980. |> the source and a variable containing the objects with the directory path 
  981. |> "../obj/" prefixed to it.  Below is a makefile that would compile all *.c and
  982. |> create a a.out file. However, I can't get make to execute the shell command
  983. |> correctly on the OBJECTS line correctly (the line is a valid shell command).
  984. |> 
  985. |> OBJDIR = ../obj
  986. |> 
  987. |> SOURCE=*.c
  988. |> OBJECTS=`for i in \`ls *.c |sed 's/\.c/.o/g'\`; do echo "../obj/$i"; done`
  989. |> $(OBJDIR)/a.out:  $(OBJECTS) 
  990. |>     cc -o $@ $(OBJECTS) 
  991. |> 
  992. |> $(OBJECTS) : $SOURCE
  993. |>     cc -c $(OPT)  $(@F:o=c) -o $@ 
  994. |> 
  995. |> Can anybody tell me how I can get the OBJECT variable set correctly?
  996.  
  997. Your problem is that you are trying to nest the stuff in `` command line
  998. substitution braces. This is not allowed. Do it in two steps:
  999.  
  1000. TEMP=`ls *.c |sed 's/\.c/.o/g'\`
  1001. OBJECTS=`for i in $TEMP; do echo "../obj/$i"; done`
  1002.  
  1003.    Alan
  1004.  
  1005. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1006.    Maidenhead itself is too snobby to be pleasant. It is the haunt of the
  1007.    river swell and his overdressed female companion. It is the town of showy
  1008.    hotels, patronized chiefly by dudes and ballet girls. 
  1009.  
  1010.    Three Men In A Boat, Jerome K. Jerome, 1889
  1011. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1012.  
  1013. -----------------------------
  1014.  
  1015. From: Benjamin B Thomas <benjy@athena.mit.edu>
  1016. Subject: Re: need script to rename uppercase filenames
  1017. Date: 3 Sep 92 08:31:07 GMT
  1018. Sender: News system <news@athena.mit.edu>
  1019. Nntp-Posting-Host: e40-008-4.mit.edu
  1020. To:       info-unix@sem.brl.mil
  1021.  
  1022. In article <699@svcs1.UUCP> slix@svcs1.UUCP (Bill Miller) writes:
  1023. >I have some source code in DOS (many separate files) that I tarred under
  1024. >DOS and untarred under 386BSD.  The big problem is that all the files
  1025. >came through in UPPERCASE and I need a script to mv (rename) them all
  1026. >to lowercase quickly.
  1027.  
  1028. Try:
  1029.  
  1030. #!/bin/csh 
  1031. foreach i ($argv)
  1032. setenv file $i
  1033. cat $file | tr -d '\015' > `echo foo | nawk '{print tolower(ENVIRON["file"])}'`
  1034. rm $file
  1035. end
  1036.  
  1037.  
  1038.      Now just type the script name and the filenames (or partial filenames 
  1039. with wildcards) and you should be set. 
  1040.  
  1041.                     -Benjy
  1042.  
  1043. -----------------------------
  1044.  
  1045. From: Rouben Rostamian <rouben@math13.math.umbc.edu>
  1046. Subject: Re: need script to rename uppercase filenames
  1047. Date: 3 Sep 92 12:06:07 GMT
  1048. Sender: News posting account <newspost@umbc3.umbc.edu>
  1049. To:       info-unix@sem.brl.mil
  1050.  
  1051. In article <1992Sep3.083107.11920@athena.mit.edu> benjy@athena.mit.edu (Benjamin B Thomas) writes:
  1052. >In article <699@svcs1.UUCP> slix@svcs1.UUCP (Bill Miller) writes:
  1053. >> 
  1054. >>I have some source code in DOS (many separate files) that I tarred under
  1055. >>DOS and untarred under 386BSD.  The big problem is that all the files
  1056. >>came through in UPPERCASE and I need a script to mv (rename) them all
  1057. >>to lowercase quickly.
  1058. >
  1059. >Try:
  1060. >
  1061. >#!/bin/csh 
  1062. >foreach i ($argv)
  1063. >setenv file $i
  1064. >cat $file | tr -d '\015' > `echo foo | nawk '{print tolower(ENVIRON["file"])}'`
  1065. >rm $file
  1066. >end
  1067.  
  1068. I would suggest the quicker script:
  1069.  
  1070. #!/bin/sh
  1071. for file in *[A-Z]*
  1072. do
  1073. mv $file `echo $file | tr '[A-Z]' '[a-z]'`
  1074. done
  1075.  
  1076. This script changes all files names containing an uppercase letter 
  1077. in the current directory to lowercase.  I would not strip the \015s
  1078. so casually without knowing the contents of the files.
  1079.  
  1080. --RR
  1081.  
  1082. -----------------------------
  1083.  
  1084. From: Samuel Kamens <snk@fork.bae.bellcore.com>
  1085. Subject: Re: need script to rename uppercase filenames
  1086. Keywords: script,tar,msdos
  1087. Date: 3 Sep 92 13:50:42 GMT
  1088. Sender: news@walter.bellcore.com
  1089. Nntp-Posting-Host: fork.bae.bellcore.com
  1090. To:       info-unix@sem.brl.mil
  1091.  
  1092. In article <699@svcs1.UUCP>, slix@svcs1.UUCP (Bill Miller) writes:
  1093. > Hi, everyone.
  1094. > I'm fairly new to unix, and I need a script or procedure to do the following:
  1095. >  
  1096. > I have some source code in DOS (many separate files) that I tarred under
  1097. > DOS and untarred under 386BSD.  The big problem is that all the files
  1098. > came through in UPPERCASE and I need a script to mv (rename) them all
  1099. > to lowercase quickly.
  1100. >  
  1101. > Since they're in DOS text format, I realize I also need to strip the 
  1102. > extra carriage returns on each line.  I've been successful in doing this
  1103. > with:
  1104. >  
  1105. >   cat (file) | tr -d '\015' > (newfile)
  1106. >  
  1107. > It would be nice to combine both of these so that I could rename the
  1108. > files to uppercase and strip the extra newlines all in one fell swoop
  1109. > instead of doing it one file at a time.
  1110.  
  1111.  
  1112. Try this:
  1113.  
  1114.  -------------------- CUT HERE ----------------------
  1115. #!/bin/ksh
  1116. # Script to rename a list of files to its lowercase equivalent while 
  1117. # stripping extra carriage returns
  1118. #
  1119.  
  1120. USAGE: $0 FILE1 FILE2 FILE3 ...
  1121.  
  1122. for i in $*
  1123. do
  1124.     lowfile=`echo $i | tr [A-Z] [a-z]`
  1125.     
  1126.     cat ${i} | tr -d '\015' > ${lowfile}
  1127.     # you could do rm $i here if you want
  1128. done
  1129.  -------------------- CUT HERE ----------------------
  1130.  
  1131. You could also do this with a one-liner:
  1132.  
  1133.     cat $1 | tr -d '\015' > `echo $1 | tr [A-Z] [a-z]`
  1134.  
  1135. Sam
  1136.  
  1137. -- 
  1138. Sam Kamens                    Bell Communications Research
  1139. snk@bae.bellcore.com                Phone: (908) 699-7509
  1140. 444 Hoes Lane  Room RRC 1D-210
  1141. Piscataway, NJ 08854
  1142.  
  1143. -----------------------------
  1144.  
  1145. From: Bill Campbell <bill@celestial.com>
  1146. Subject: Re: need script to rename uppercase filenames
  1147. Keywords: script,tar,msdos
  1148. Date: 3 Sep 92 15:12:45 GMT
  1149. To:       info-unix@sem.brl.mil
  1150.  
  1151. In <699@svcs1.UUCP> slix@svcs1.UUCP (Bill Miller) writes:
  1152.  
  1153. >Hi, everyone.
  1154.  
  1155. >I'm fairly new to unix, and I need a script or procedure to do the following:
  1156. >I have some source code in DOS (many separate files) that I tarred under
  1157. >DOS and untarred under 386BSD.  The big problem is that all the files
  1158. >came through in UPPERCASE and I need a script to mv (rename) them all
  1159. >to lowercase quickly.
  1160. >Since they're in DOS text format, I realize I also need to strip the 
  1161. >extra carriage returns on each line.  I've been successful in doing this
  1162. >with:
  1163. >  cat (file) | tr -d '\015' > (newfile)
  1164. >It would be nice to combine both of these so that I could rename the
  1165. >files to uppercase and strip the extra newlines all in one fell swoop
  1166. >instead of doing it one file at a time.
  1167.  
  1168. A simple perl solution (needs more error checking):
  1169.  
  1170. for $dos ( @ARGV ) {
  1171.     ( $unix = $dos ) =~ tr/A-Z/a-z/;    # convert to lower case
  1172.     if ( -f $unix ) {
  1173.         print STDERR "Cannot convert $dos -- $unix exists\n";
  1174.         next;
  1175.     }
  1176.     open(DOS, $dos);
  1177.     open(UNIX, "> $unix");
  1178.     while (<DOS>) {
  1179.         s/\s+$//;   # strip all trailing whitespace including ^M
  1180.         print UNIX;
  1181.     }
  1182.     close(DOS);
  1183.     unlink($dos); # remove old dos file
  1184.     close(UNIX);
  1185. }
  1186. -- 
  1187. INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Software
  1188. UUCP:   ...!thebes!camco!bill   6641 East Mercer Way
  1189.              uunet!camco!bill   Mercer Island, WA 98040; (206) 947-5591
  1190. SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
  1191.  
  1192. -----------------------------
  1193.  
  1194. From: Michael Salmon <etxmesa@eos.ericsson.se>
  1195. Subject: Re: need script to rename uppercase filenames
  1196. Keywords: script,tar,msdos
  1197. Date: 4 Sep 92 06:46:13 GMT
  1198. Sender: news@ericsson.se
  1199. Nntp-Posting-Host: eos6c02.ericsson.se
  1200. To:       info-unix@sem.brl.mil
  1201.  
  1202. In article <699@svcs1.UUCP>, slix@svcs1.UUCP (Bill Miller) writes:
  1203. |> Hi, everyone.
  1204. |> 
  1205. |> I'm fairly new to unix, and I need a script or procedure to do the following:
  1206. |>  
  1207. |> I have some source code in DOS (many separate files) that I tarred under
  1208. |> DOS and untarred under 386BSD.  The big problem is that all the files
  1209. |> came through in UPPERCASE and I need a script to mv (rename) them all
  1210. |> to lowercase quickly.
  1211. |>  
  1212. |> Since they're in DOS text format, I realize I also need to strip the 
  1213. |> extra carriage returns on each line.  I've been successful in doing this
  1214. |> with:
  1215. |>  
  1216. |>   cat (file) | tr -d '\015' > (newfile)
  1217. |>  
  1218. |> It would be nice to combine both of these so that I could rename the
  1219. |> files to uppercase and strip the extra newlines all in one fell swoop
  1220. |> instead of doing it one file at a time.
  1221. |> 
  1222.  
  1223. A little plug for tcsh:
  1224.  
  1225. foreach fn ([A-Z]*)
  1226.     tr -d '\015' <$fn >$fn:al
  1227. end
  1228.  
  1229. Of course the original file name specification is a little simplistic.
  1230.  
  1231. -- 
  1232.  
  1233. Michael Salmon
  1234.  
  1235. #include    <standard.disclaimer>
  1236. #include    <witty.saying>
  1237. #include    <fancy.pseudo.graphics>
  1238.  
  1239. Ericsson Telecom AB
  1240. Stockholm
  1241.  
  1242. -----------------------------
  1243.  
  1244. From: Larry Wall <lwall@netlabs.com>
  1245. Subject: Re: need script to rename uppercase filenames
  1246. Keywords: script,tar,msdos
  1247. Date: 4 Sep 92 16:20:44 GMT
  1248. Sender: news@netlabs.com
  1249. Nntp-Posting-Host: scalpel.netlabs.com
  1250. To:       info-unix@sem.brl.mil
  1251.  
  1252. In article <1992Sep03.151245.11128@Celestial.COM> bill@Celestial.COM (Bill Campbell) writes:
  1253. :         s/\s+$//;   # strip all trailing whitespace including ^M
  1254.  
  1255. Unfortunately, that also deletes the ^J.  Since the script unlinks the
  1256. DOS file, you've just thrown away information that's not easily
  1257. reconstructable.  (In fact, the files won't even be editable unless you
  1258. use GNU emacs.)  It would be safer to move the DOS file to a temporary
  1259. subdirectory until you're sure the translation works right.
  1260.  
  1261. I don't want to discourage anyone from helping people, but help is not
  1262. what booby traps are generally construed as...  :-)
  1263.  
  1264. Larry Wall
  1265. lwall@netlabs.com
  1266.  
  1267. -----------------------------
  1268.  
  1269. From: Benjamin B Thomas <benjy@athena.mit.edu>
  1270. Subject: Problems using inittab
  1271. Date: 3 Sep 92 08:49:41 GMT
  1272. Sender: News system <news@athena.mit.edu>
  1273. Nntp-Posting-Host: e40-008-4.mit.edu
  1274. To:       info-unix@sem.brl.mil
  1275.  
  1276.  
  1277.     I was wondering if someone could help me clear something up?  The
  1278. documentation I have leads me to believe that if I want to run a script from
  1279. /etc/inittab at run level 3 and insure that it remains alive, I need to add
  1280. this to /etc/inittab:
  1281.  
  1282. foo :3:respawn:/bin/sh -c 'exec /usr/local/bin/my_script'
  1283.  
  1284. The script gets executed (ps gives:  ...../usr/local/bin/my_script /usr/local/)
  1285. but doesn't work right.
  1286.  
  1287. The script writes to a tmp file, sleeps, checks some stuff, and then writes
  1288. over the tmp file (ls -t > /tmp/foo) This works fine when I execute from the 
  1289. command line, but won't write anything when started from inittab.However, it
  1290. will write a blank /tmp/foo if I place anything in the file while the process
  1291. is sleeping.
  1292.  
  1293. Any ideas?   BTW It's a csh script.
  1294.  
  1295.                     -Benjy
  1296.  
  1297. -----------------------------
  1298.  
  1299. From: Scott Barnhart <sbarnhar@ncratl.atlantaga.ncr.com>
  1300. Subject: Extended chars in Unix
  1301. Date: 3 Sep 92 11:28:36 GMT
  1302. To:       info-unix@sem.brl.mil
  1303.  
  1304.  
  1305.  
  1306. I am using Unix SystemVR4, and want to find a way to generate the
  1307. extended ASCII chars from the keyboard.  The reason for this is
  1308. to generate the appropriate foreign characters (such as the vowels 
  1309. with the accents, etc) needed in the various different languages 
  1310. (specifically French, German and other European languages).
  1311.  
  1312. I first thought it could be done somehow with the LOCALE stuff
  1313. in Unix, setlocale(), chrtbl(), etc.  But the man pages don't go
  1314. into how to generate or translate these characters.
  1315.  
  1316. If anyone has any idea how to do this sort of thing, please
  1317. e-mail me at sbarnhar@ncratl.AtlantaGA.NCR.COM, or post a reply.
  1318. I would really appreciate any help in this area.
  1319.  
  1320. -----------------------------
  1321.  
  1322. From: David Pape <pape@plato.chemietechnik.uni-dortmund.de>
  1323. Subject: makefile with multiple dirs
  1324. Keywords: make,makefile
  1325. Date: 3 Sep 92 13:59:02 GMT
  1326. Sender: news@unidoct.chemietechnik.uni-dortmund.de
  1327. To:       info-unix@sem.brl.mil
  1328.  
  1329.  
  1330.         Heres my (highly simplified) project directory setup:
  1331.  
  1332. proto:  makefile, resultant executable
  1333.  
  1334. proto/x:        x.c, x.h, x.o
  1335. proto/y:        y.c, y.h, y.o
  1336.  
  1337. How can I run "make" in the "proto" dir, and have it put "x.o" and
  1338. "y.o" in the correct directories? I also want to be able to run
  1339. "makedepend" from the makefile in "proto" so that it creates the
  1340. dependencies correctly, i.e:
  1341.  
  1342. # DO NOT DELETE THIS LINE -- make depend depends on it.
  1343.  
  1344. proto/x/x.o: proto/x/x.h
  1345. proto/y/y.o: proto/y/y.h
  1346.  
  1347. Even when I have
  1348.  ---------------------------------
  1349. X_PATH = proto/x
  1350.  
  1351. depend:
  1352.         makedepend $(X_PATH)/x.c
  1353.  ---------------------------------
  1354. in my makefile, I always get
  1355.  
  1356. x.o: proto/x/x.h        #notice missing path
  1357.  
  1358. Any helpful hints out there??
  1359.  
  1360. --
  1361. David Pape                 | "Justice is inci- |            ///
  1362. pape@plato.Chemietechnik.Uni-Dortmund.DE |  dental to law    |     \\\ UNI_DO
  1363. Dortmund, Germany             |  and order"       |      \\\///
  1364. tel: 49 231 7552682             | - J. Edgar Hoover |       \\//
  1365.  
  1366. -----------------------------
  1367.  
  1368. From: Jack versloot <versloot@rwzl01.zld.rws.nl>
  1369. Subject: Help wanted on hpterm problem
  1370. Keywords: X, hpterm
  1371. Date: 3 Sep 92 14:58:22 GMT
  1372. Followup-To: poster
  1373. To:       info-unix@sem.brl.mil
  1374.  
  1375.  
  1376. Help wanted on the following problem.
  1377.  
  1378. First some information:
  1379. Language: FORTRAN
  1380. Machine : HP9000
  1381. Terminal: hp
  1382.  
  1383. I have a program doing the following:
  1384.    - set up protected fields on the terminal
  1385.    - let the user enter some data in these fields
  1386.    - reading lines from the terminal (with the entered information) with:
  1387.         READ (*, '(A)') line
  1388.  
  1389. To read lines ESCd is sent to the terminal. The character*512 variable
  1390. line is searched for ESC[ (begin protected field) and ESC] (end
  1391. protected field). All information between these two codes will be the
  1392. information entered by the user.
  1393.  
  1394. This works FINE for a real hp-terminal. On a X-window with hpterm it
  1395. doesn't work however! The last field on each line is misformed: the
  1396. code for 'end protected field' is missing.
  1397.  
  1398. My question: 
  1399.    Why?
  1400. and more important:
  1401.    What can I do about it?
  1402.  
  1403. Is hpterm not completely compatible with a hp-terminal or should I (maybe)
  1404. give hpterm some options or what?
  1405.  
  1406. If you have the answer please send it by E-mail to the
  1407. following address:
  1408.  
  1409.              ingen@rwzl01.zld.rws.nl
  1410.  
  1411. -----------------------------
  1412.  
  1413. From: Taed Nelson <nelson@desktop.nsc.com>
  1414. Subject: @ Re: Technical dictionary
  1415. Date: 3 Sep 92 15:55:51 GMT
  1416. Sender: UseNet News account <news@berlioz.nsc.com>
  1417. To:       info-unix@sem.brl.mil
  1418.  
  1419. In article <BtyEnK.LsL@wpi.WPI.EDU>, mugsy@winton.uucp (Michael G. Bruce) writes:
  1420. > Does anyone know of a quality CS dictionary?  While I have a working knowledge
  1421. > of terms such as MIPS, FLOPS, IPC, etc,  I have occasion to need a proper,
  1422. > concise definition.
  1423.  
  1424. Although not "concise", I would highly recommend _The Encyclopedia of Computer
  1425.   Science_.  It's about 2000 pages, and has 1/2 - 4 page articles on
  1426.   everything about CS that you would ever want to know.  Particularly
  1427.   interesting is the history and details of the "classic" machines.  I don't
  1428.   know who publishes/ed it, but it goes for about $50 used.
  1429.  
  1430. -----------------------------
  1431.  
  1432. From: scott williams <scott.williams@canrem.com>
  1433. Subject: a question on ls
  1434. Date: 3 Sep 92 17:50:42 GMT
  1435. To:       info-unix@sem.brl.mil
  1436.  
  1437.  
  1438. In article <6786#tekig7.PEN.TEK.COM> naren@tekig5.pen.tek.com (Naren Bala)
  1439. writes:
  1440.  
  1441. | >What command would I type to display all files that do not have a .Z
  1442. | >extension ?
  1443.  
  1444. In sh, my preference would be to combine ls with grep, as in:
  1445.  
  1446.    ls | grep -v '\.Z$'
  1447. ---
  1448.  ~ DeLuxe} 1.12 #8626 ~ Scott Williams, Editor, Open Systems Letter
  1449. --
  1450. Canada Remote Systems  - Toronto, Ontario/Detroit, MI
  1451. World's Largest PCBOARD System - 416-629-7000/629-7044
  1452.  
  1453. -----------------------------
  1454.  
  1455. From: "Subramanian Venkataraman (TV" <venkatar@doowop.jpl.nasa.gov>
  1456. MMDF-Warning:  Parse error in original version of preceding line at BRL.MIL
  1457. Subject: Dumb Question
  1458. Date: 3 Sep 92 18:56:42 GMT
  1459. Sender: Usenet <news@elroy.jpl.nasa.gov>
  1460. Nntp-Posting-Host: doowop.jpl.nasa.gov
  1461. To:       info-unix@sem.brl.mil
  1462.  
  1463. Hello.
  1464.  
  1465. I have two dumb questions.
  1466.  
  1467. (i) I am given to understand that there exists a public domain
  1468. version of the BSD386 system (net2?). How do I get hold of the
  1469. source code?
  1470.  
  1471. (ii) Is there a SUN version of net2?
  1472.  
  1473. Please note that I am note a system guru, or even a system expert!
  1474. Just a novice trying to get hold of info that may be useful for a
  1475. project I am involved in.
  1476.  
  1477. Thanks a lot.
  1478.  
  1479. S.T. Venkataraman.
  1480. Jet Propulsion Laboratory
  1481. venkatar@robotics.jpl.nasa.gov
  1482.  
  1483. -----------------------------
  1484.  
  1485. From: Afsar Husain <ahusain@ad-22.naitc.com>
  1486. Subject: Re: Dear vi guru,
  1487. Date: 3 Sep 92 21:48:12 GMT
  1488. Sender: Usenet News <news@firewall.nielsen.com>
  1489. Nntp-Posting-Host: ad-22.naitc.com
  1490. To:       info-unix@sem.brl.mil
  1491.  
  1492. In article <1992Sep2.224136.24163@nsisrv.gsfc.nasa.gov> schieb@shark.gsfc.nasa.gov (Brian D. Schieber) writes:
  1493. >Dear vi guru,
  1494. > I like to use tabs alot in just about every session of vi I
  1495. >work with, It would be great if I had a macro or whatever that
  1496. >could replace the tabs with the appropriate number of spaces
  1497. >in a file WHILE in vi. Do you have such a macro?
  1498. >
  1499. >Most graciously,
  1500. > Brian
  1501. >
  1502. >p.s. please send all suggestions to switch to EMACS to /dev/null
  1503.  
  1504. What I have done is to map a free key such as a "w" or a "q"
  1505. with a macro. This macro will replace all the tabs with 4 spaces 
  1506. and then writes the file and quits the editor. You can include
  1507. such a mapped macro in the ".exrc" file
  1508.  
  1509.     map w :1,$s/     /    /g
  1510.  
  1511. The above map can be accomplished in a "vi" session by the following series of key
  1512. strokes. Ofcourse you have to substitute the "tab" character and the
  1513. "spaces" with the desired number of spaces.
  1514.  
  1515.     :map w :1,$s/tab/spaces/g^V^M:wq^V^M
  1516.  
  1517. The control M sequence can be generated by preceding it with
  1518. a control V i.e. ^V^M.
  1519.  
  1520.  
  1521. Hope this helps.
  1522.  
  1523. -- 
  1524. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1525. #include    <standard.disclaimer>
  1526. email: ahusain@nis.naitc.com
  1527.  
  1528. -----------------------------
  1529.  
  1530. From: Anthony P Scott <aps583@huxley.anu.edu.au>
  1531. Subject: AWK and arrays
  1532. Date: 4 Sep 92 03:07:33 GMT
  1533. Sender: news@manuel.anu.edu.au
  1534. Originator: aps583@huxley
  1535. To:       info-unix@sem.brl.mil
  1536.  
  1537. Suppose I want to read a bunch of letters one to a line
  1538. and output the position in the alphabet that they occupy.
  1539.  
  1540. ie
  1541.  
  1542. a
  1543. b
  1544. c
  1545. d
  1546. e
  1547.  
  1548. would be output as
  1549.  
  1550. 1
  1551. 2
  1552. 3
  1553. 4
  1554. 5
  1555.  
  1556. etc.
  1557.  
  1558. One way I visualized doing this is to write an array called alph[letter]
  1559. such as:
  1560.  
  1561. alph[a] =1
  1562. alph[b] = 2
  1563. alph[c] = 3
  1564.  ...
  1565.  
  1566.  ...
  1567. alph[z] = 26
  1568.  
  1569. and then read the lines of text as another array called charact[NR]
  1570.  
  1571. ie
  1572.  
  1573. {
  1574. charact[NR] = $1
  1575. }
  1576.  
  1577. and the use the charact array to subscript the alph array ie
  1578.  
  1579. { for (i=1; i<=NR; i++) {
  1580. char_num[i] = alph[charact[i]] }
  1581. }
  1582.  
  1583. This doesn't work. Can anyone point me in the right direction
  1584.  
  1585. Another way I thought of doing the job was to get the subscript number of
  1586. an array item.
  1587.  Something like:
  1588.  
  1589. for (charact[i] in alph) {
  1590.     print alph[i]
  1591. }
  1592.  
  1593. This doesn't work either.
  1594.  
  1595. I hope this is not a silly question.
  1596.  
  1597. Regards 
  1598.  
  1599. Tony Scott
  1600.  
  1601. -----------------------------
  1602.  
  1603. From: "M. P. Capistrano" <capistra@andromeda.rutgers.edu>
  1604. Subject: Question on WAKE UP call...
  1605. Date: 4 Sep 92 04:34:52 GMT
  1606. To:       info-unix@sem.brl.mil
  1607.  
  1608.  
  1609. What should happen if the kernel attempts to wake up all processes sleeping
  1610. on an event, but no processes are asleep on the event at the time of the
  1611. wakeup?
  1612.  
  1613. Thanks.
  1614.  
  1615. -MPC-
  1616.  
  1617. -----------------------------
  1618.  
  1619. From: "M. P. Capistrano" <capistra@andromeda.rutgers.edu>
  1620. Subject: What happens when all the inodes are exhausted?
  1621. Date: 4 Sep 92 04:39:25 GMT
  1622. To:       info-unix@sem.brl.mil
  1623.  
  1624.  
  1625. When a filesystem is created, a fixed number of inodes are allocated
  1626. for the inode list.  So, what happens when all the inodes are
  1627. exhausted then?
  1628.  
  1629. Thanks.
  1630. -MPC-
  1631.  
  1632. -----------------------------
  1633.  
  1634. From: "S.Ramakrishnan" <ramakris@csgrad.cs.vt.edu>
  1635. Subject: Distinguish between numeic & nonumeric char strings in shell ?
  1636. Date: 4 Sep 92 07:03:57 GMT
  1637. Sender: daemon@ucbvax.berkeley.edu
  1638. To:       info-unix@sem.brl.mil
  1639.  
  1640.  
  1641.  How does one distinguish between a number and a nonnumeric
  1642.  character using shelltools (sh/csh, awk, sed, expr, etc) ? 
  1643.  I am trying to validate the IP address typed in by the user. 
  1644.  I isolate the four components and check each one to see if lies 
  1645.  within the legal range (0..255). In the event the user types, say, 
  1646.  tom.jack.joe.jim, I want to be able to flag an error. However the 
  1647.  IF statement, marked (+) in the fragment below, fails even if a 4 
  1648.  component string such as "tom.jack.joe.jim"  is entered. 
  1649.  Any suggestions ?
  1650.  
  1651.  Encl:
  1652.     #!/bin/sh
  1653.         ...
  1654.     while test "$ip" = ""
  1655.     do
  1656.           echo "    IP Address = "
  1657.       read ip
  1658.           if [ "$ip" != "" ]
  1659.       then
  1660.               cnt=`echo $ip | awk -F'.' '{ print NF }'`
  1661.               one=`echo $ip | awk -F'.' '{ print $1}'`
  1662.               two=`echo $ip | awk -F'.' '{ print $2}'`
  1663.               thr=`echo $ip | awk -F'.' '{ print $3}'`
  1664.               fou=`echo $ip | awk -F'.' '{ print $4}'`
  1665. #(+)
  1666.               if [ $cnt -ne 4 -o $one -gt 255 -o $two -gt 255 -o $thr -gt 255 -o $fou -gt 255 ]
  1667.               then
  1668.             echo ""
  1669.                 echo "*** Invalid IP Address Format: Please Retype"
  1670.             echo ""
  1671.             ip=""
  1672.               fi
  1673.       fi
  1674.         done
  1675.     ...
  1676.  
  1677. ---
  1678. S Ramakrishnan, CS Dept, McBryde Hall, VaTech, Virg.
  1679.  
  1680. -----------------------------
  1681.  
  1682. From: Michael Salmon <etxmesa@eos.ericsson.se>
  1683. Subject: Re: Awk: Beginner needs help!
  1684. Keywords: awk unix
  1685. Date: 4 Sep 92 07:32:13 GMT
  1686. Sender: news@ericsson.se
  1687. Nntp-Posting-Host: eos6c02.ericsson.se
  1688. To:       info-unix@sem.brl.mil
  1689.  
  1690. In article <5608@ucsbcsl.ucsb.edu>, 
  1691. 6500scv1@ucsbuxa.ucsb.edu (Steven C. Velasco) writes:
  1692. |> 
  1693. |> HI,
  1694. |> I am new to unix, and really new to awk, so hopefully somebody can
  1695. |> answer this question real easily.  I have hundreds of SAS program
  1696. |> files written for MVS, that we now need to run on UNIX.  
  1697. |> The files from MVS look like this :
  1698. |> 
  1699. |> COMMAND? list unnumbered
  1700. |> //MVS JCL statements
  1701. |> //MVS JCL statements
  1702. |> //MVS JCL statements
  1703. |> DATA _NULL_ ;
  1704. |>    SET SASLIB.DATASET ;
  1705. |> MORE SAS STATEMENTS
  1706. |> RUN ;
  1707. |> 
  1708. |> I can get awk to print out the lines that don't contain the string  "//"
  1709. |> or "COMMAND?" in $1, but I would like to have
  1710. |> something that replaces the entire line  "COMMAND? list unnumbered"
  1711. |> (this is always the first line, and occurs just once) 
  1712. |> with the string: "libname saslib /usr2/username/datasets"  or, to 
  1713. |> somehow put the "libname" string in the first line of each file.
  1714. |> So the resulting file would look like this:
  1715. |> 
  1716. |> libname saslib '/usr2/username/datasets' ;
  1717. |> DATA _NULL_ ;
  1718. |>    SET SASLIB.DATASET ;
  1719. |> MORE SAS STATEMENTS ;
  1720. |> RUN ;
  1721. |> 
  1722. |> below is my feeble attempt to do this.  When I run this program, I
  1723. |> get a message saying something like 'awk: cant set $0 at record 1':
  1724. |> 
  1725. |> $1 !~ /\/\// { if ( $0 ~ /COMMAND? list unnumbered/ ) 
  1726. |> $0 = "libname saslib /usr2/username/datasets ;" 
  1727. |> print >FILENAME }  
  1728. |> 
  1729. |> What am I doing wrong?  I would appreciate any help or suggestions.
  1730.  
  1731. I would solve this in this way:
  1732.  
  1733. #!/usr/bin/awk
  1734. BEGIN { print "libname saslib /usr2/username/datasets ;" }
  1735.  
  1736. /^\/\// { next }
  1737. /^COMMAND?/ { next }
  1738. { print }
  1739.  
  1740. The first line is only useful if you system supports this. I would also
  1741. guess that the COMMAND? line could be used for something useful but I
  1742. don't know anything about SAS other than that it is Sweden's
  1743. international airline ;^)
  1744.  
  1745. -- 
  1746.  
  1747. Michael Salmon
  1748.  
  1749. #include    <standard.disclaimer>
  1750. #include    <witty.saying>
  1751. #include    <fancy.pseudo.graphics>
  1752.  
  1753. Ericsson Telecom AB
  1754. Stockholm
  1755.  
  1756. -----------------------------
  1757.  
  1758. From: Andre Hoekstra <ahoekstr@cs.utwente.nl>
  1759. Subject: Re: How can I allow access to a subdirectory without risking other files?
  1760. Date: 4 Sep 92 12:58:22 GMT
  1761. Sender: ahoekstr@cs.utwente.nl
  1762. Nntp-Posting-Host: waal
  1763. To:       info-unix@sem.brl.mil
  1764.  
  1765. In article <Btq39I.1on@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
  1766. >In article <92Aug26.165308.27634@acs.ucalgary.ca> barker@enel.ucalgary.ca writes:
  1767. >>I know how to give group/other access to a subdirectory without risking my
  1768. >>other files, however, I want people to be able to read/write to ANY file in
  1769. >>the subdirectory. That includes files put there by other people.  The only way
  1770. >>I know of to do this is to make sure that everyone has their umask set to 000
  1771. >>when they are working in that subdirectory.
  1772. >
  1773. >It sounds fairly dangerous to do this without any arbitration to keep
  1774. >several people from writing to the same file at once.  Why don't you
  1775. >just insist that each person copy a file before making changes?  Or
  1776. >write a suid root program that does nothing but change the modes on
  1777. >the files in that directory and make the users run that before writing
  1778. >to any files.  Better yet, make the program also perform some kind of
  1779. >file locking while each person is writing.
  1780.  
  1781. SCCS(1) ?
  1782. >
  1783. >Les Mikesell
  1784. >  les@chinet.chi.il.us
  1785.  
  1786. Andre Hoekstra
  1787.  
  1788. -----------------------------
  1789.  
  1790. From: Mark Fugazzotto <mfugazzo@resdgs1.er.usgs.gov>
  1791. Subject: help with script
  1792. Date: 4 Sep 92 14:03:11 GMT
  1793. Sender: news@rsg1.er.usgs.gov
  1794. Originator: mfugazzo@resdgs1.er.usgs.gov
  1795. To:       info-unix@sem.brl.mil
  1796.  
  1797.  
  1798.  A while ago I had asked for help with posting the
  1799. motd on the server to all remote workstations. I got
  1800. a big response back. Thanks to everyone that responded.
  1801.  Some suggetions were to use rdist(unsupported on this
  1802. version of Unix), use rcp (would have worked but a
  1803. security hazard to make root equivilent on from the 
  1804. server to all workstations). The one I went with was
  1805. a script on the server to ftp  via anonymous the motd 
  1806. to all workstations. then have a cron job on each
  1807. workstation copy the motd into the etc directory. 
  1808.  This works well except for one flaw with cron I can't
  1809. seem to overcome. Cron simply executes a script on each
  1810. workstation at the specified times, and it does. Only it
  1811. does not echo to the screen the line in the script which
  1812. tells the user that an updated motd has arrived. Where is
  1813. this output being sent to? If I execute the script manually
  1814. it works fine. What can I do to get cron to echo the line to
  1815. the screen? 
  1816.  Also while I'm here, Is there something I can put into my 
  1817. script that will check first for a logon, if one is found then
  1818. echo to the screen, if one is not found, do nothing??
  1819.  
  1820.                           thanks in advance
  1821.  
  1822.                                              Mark...
  1823.  
  1824. -----------------------------
  1825.  
  1826. From: Michael Gleibman <c0408982@techst02.technion.ac.il>
  1827. Subject: Modem number access from UNIX system
  1828. Date: 4 Sep 92 15:15:49 GMT
  1829. Sender: news@wang.com
  1830. To:       info-unix@sem.brl.mil
  1831.  
  1832. Hello! 
  1833. Does anybody here knows how can I access the modem number from VAX (BSD4.3)
  1834. Thanx in advance. Any help is appreciated.
  1835.  
  1836. -- 
  1837.                         Michael Gleibman,
  1838. Dept. of Mathematics, Technion, Haifa, Israel,
  1839. e-mail: c0408982@techst02.technion.ac.il
  1840. Phone: (0972)(8)543820
  1841.  
  1842. -----------------------------
  1843.  
  1844. From: Brian Fitzgerald <fitzgb@mml0.meche.rpi.edu>
  1845. Subject: Re: changing name of core file
  1846. Date: 4 Sep 92 15:26:09 GMT
  1847. Nntp-Posting-Host: mml0.meche.rpi.edu
  1848. To:       info-unix@sem.brl.mil
  1849.  
  1850. Dan Stanger writes:
  1851. >does anyone know how to change the name of the core file that will be
  1852. >created if a program fails.  we have several programs running in the
  1853.  
  1854. Not without kernel sources.
  1855.  
  1856. >same directory so if more than one of them fails the core file from
  1857. >one overwrites the other.  we would like to change the name to
  1858. >program.core or somthing like that.
  1859.  
  1860. Run the program as:
  1861.  
  1862. program ; mv core program.core
  1863.  
  1864. When "program" exits, then if "core" exists, it is renamed.
  1865.  
  1866. This is the idea, anyway.  You want a fancier shell script.
  1867.  
  1868. #!/bin/sh
  1869. program || test -f core && mv core program.core
  1870.  
  1871. is a little better, but there's no assurance that you are renaming
  1872. the right core file.
  1873.  
  1874. Brian
  1875.  
  1876. -----------------------------
  1877.  
  1878. From: Upkar Singh Kohli <upkar@trace.eng.wayne.edu>
  1879. Subject: two questions
  1880. Date: 4 Sep 92 15:38:13 GMT
  1881. Sender: Usenet News <usenet@cs.wayne.edu>
  1882. To:       info-unix@sem.brl.mil
  1883.  
  1884.  
  1885. 1. What is the best way to disable echo from within a C program?
  1886.    The purpose is read a password.
  1887.  
  1888. 2. What is the best unique identifier for machines to use for
  1889.    software licensing? I have heard that even the "effective"
  1890.    ethernet address can be changed. I know the hostids can easily
  1891.    be changed on certain architectures like DEC and SGI.
  1892.  
  1893. Thanks!
  1894. Upkar
  1895.  
  1896. (if possible please email upkar@eng.wayne.edu... followup over
  1897.  news will be ok too, except I read it less)
  1898.  
  1899. -----------------------------
  1900.  
  1901. From: Mitch Wagner <wagner@utoday.com>
  1902. Subject: net.views -- USL/BSDI lawsuit -- responses
  1903. Date: 4 Sep 92 19:24:41 GMT
  1904. Followup-To: comp.unix.questions
  1905. To:       info-unix@sem.brl.mil
  1906.  
  1907. Here we go with the responses to the latest net.views. Thanks to all
  1908. who responded to my recent plea for help; and my apologies to those
  1909. who replied the first time and whose responses I lost because of my
  1910. foolish lack of backups of the net.views file. You can certainly rest
  1911. assured that I have a good backup policy in place now.
  1912.  
  1913. Thanks also to those who ignored my invitation to flame me for not
  1914. making backups. 
  1915.  
  1916.  =-=-=-=-=-=-=-=-=-=-
  1917.  
  1918. On another topic, if anyone would like to suggest a question for us to
  1919. use for net.views, I'd love to hear it. You can find information on
  1920. how to reach me in my sig, below.
  1921.  
  1922.  =-=-=-=-=-=-=-=-=-=-
  1923.  
  1924. And now, net.views.
  1925.  
  1926. The question was:
  1927.  
  1928.      Unix Systems Laboratories recently sued software company
  1929.      BSDI and the Regents of the University of California at
  1930.      Berkeley, charging that BSDI's commercial Unix workalike
  1931.      and UCB's free software violated USL's intellectual property
  1932.      rights. Was USL justified in filing the suit?
  1933.  
  1934. The responses are attached, below.
  1935.  
  1936. Thanks again to all---participants and readers---and apologies again
  1937. for the administrative snafu, earlier.
  1938.  
  1939.                          -- mitch w.
  1940. --
  1941. Mitch Wagner, senior editor, Open Systems Today
  1942. 2353 Massachusetts Ave. Suite 47, Cambridge, MA 02140
  1943. wagner@utoday.com  (617)547-8485  CIS:70212,51  GEnie:MITCH.WAGNER  
  1944. For subscription information, please call 516/562-5882
  1945.  
  1946.  
  1947.  
  1948.  
  1949.  
  1950. From: Berk Walker <elroy.jpl.nasa.gov!techsys!berk@uunet.UUCP>
  1951.  
  1952. I am a manager for Hamada of America, I speak only for myself.
  1953.  
  1954. Whereas I believe in our justice system (in general), and it's not fair 
  1955. to try someone in the press, or in this case, usenet, if USL does not 
  1956. come forth with /specific/ allegations, I feel I need to act.
  1957.  
  1958. I have 3 phone lines, and minor influence over several others, in this 
  1959. and other states.  I will be forced to remove AT&T as my LD supplier, 
  1960. with written notice as to why. (this includes changing cellular handler). 
  1961.  APPLE never should have won, and XEROX should have sued apple.  Of 
  1962. course, if UC Regents are considered a co-conspirator, and do have the 
  1963. funding to do war with USL, and I feel that BSDI isn't seriously 
  1964. threatened, I will just sit and watch....... but USL will probably file 
  1965. for an injunction against BSDI shipping or offering for sale product.
  1966.  
  1967. And if BSDI /did/ do a direct port of (C) code?.... well they deserve to 
  1968. be hanged.  Unfortunately, I will probably make the decision to protest 
  1969. or not long before substantial proof is shown.  Then I will have struck 
  1970. against the righteous..... maybe.  I use AT&T in thanks for everything 
  1971. Bell Labs had done.
  1972.  
  1973. lots of words - sorry the meaning is so thin.
  1974.  
  1975. Berk Walker
  1976.  
  1977. From: Bob Pendelton <hal.com!bobp@uunet.UUCP>
  1978.  
  1979.  
  1980.  
  1981. Bob Pendleton
  1982. Senior Staff Engineer
  1983. HAL Computer Systems
  1984.  
  1985. Tough question. 
  1986.  
  1987. The answer is that I really don't know. But I care very much. I've had
  1988. access to USL sources, even if I haven't looked at them. Does this
  1989. mean that USL can claim ownership on anything I write that has a
  1990. function similiar to anything in the USL UNIX distribution?  Maybe it
  1991. does. 
  1992.  
  1993. The thought that I can't claim (or at least can't prove) ownership of
  1994. my own ideas is chilling.
  1995.  
  1996.             Bob P.
  1997.  
  1998. From: CJ Canon <arp.anu.edu.au!Clement.J.Canon@uunet.UUCP>
  1999.  
  2000.  
  2001.  
  2002.  
  2003. RESPONSE:    No - I don't believe that AT&T/USL is justified in filing
  2004. against UCB Regents (CSRG) and BSDI. After reading the views of many people, 
  2005. some for, and others against, I find it completely petty and underhand that 
  2006. USL should, in effect, snap at the hand which gave it so many features (UCB) to
  2007. put into it's own UNIX (whose TM?). On the BSDI front, I find it reasonable
  2008. for USL to request BSDI to remove the 1-800-ITS-UNIX phone number, but only
  2009. because that number could actually be misleading advertising. Maybe the number
  2010. 1-800-ITS-BSD would have been a better choice.
  2011.  
  2012.     However, the request that anyone who has seen AT&T source should
  2013. be barred from working in the field for a competitor is absolutely ludicrous.
  2014. I am reminded by the flavour of this request of the suit that broke up Ma Bell
  2015. and also of the suit launched against IBM - both anti-trust cases. It makes
  2016. one wonder whether or not any of USL's lawyers have thought about the 
  2017. implications for them if this case succeeds - would success not leave them 
  2018. open to an anti-trust suit?
  2019.     
  2020.     And then on the matter of intellectual property, if USL is so 
  2021. concerned about their rights, why did they not sue UC Berkeley earlier in
  2022. their (USL's) existence? 
  2023.  
  2024.     To sum up: I hope that whoever presides over the suit dismisses 
  2025. USL's case, and that complete costs are awarded to BSDI and UC Berkeley.
  2026. It might be a purely selfish motive on my part, but I certainly don't want
  2027. to be forced out of a preferred career path merely because I've seen AT&T
  2028. source and might possibly at some later date remember that code and base
  2029. further work on what I remember.
  2030.  
  2031.  
  2032. CJ Canon
  2033.  
  2034.    Internet: clement@arp.anu.edu.au
  2035.  
  2036.    Australian EST Daytime phone: +61 6 281 5626  (also fax)
  2037.    Student, (2nd year Maths --> B.Sc), ANU
  2038.  
  2039.   I read my email every day, if further comment/whatever is needed.
  2040.  
  2041.  
  2042.  
  2043.  
  2044. From: CJ Canon <arp.anu.edu.au!Clement.J.Canon@uunet.UUCP>
  2045.  
  2046.  
  2047. C. James Canon, and the ANU is the Australian National University, located in
  2048. Canberra, the Australian Capital Territory (A.C.T.)
  2049.  
  2050. CJ
  2051.  
  2052. From: Chaitanya Nagappa <menudo.uh.edu!nagappa@uunet.UUCP>
  2053. Organization: University of Houston
  2054.  
  2055. Hi,
  2056. Posting this from a friend's account because of some strong feelings (about
  2057. the subj.). I have had my share of DOS and VMS, and even though each (seriously!)
  2058. had its share of good points the whole idea of it being controlled be one
  2059. single entity with its limited vision (mo' money, mo' money) as the only
  2060. impetus, I finally found myself liking Unix. Inspite of all its idiosyncracies
  2061. and difficulties, Unix (NO *TM*) has moved ahead offering its benefits to
  2062. the outside world not because the brilliant minds at AT&T found new ways of
  2063. doing things (and not releasing it / or releasing it with undocumentation),
  2064. but because the good folks at BSD released it gratis. I recently went to a
  2065. talk by the local USL manager, about SVR4.2. The feeling I got was that
  2066. this is a pure business minded enterprise now; if possible they'll put a
  2067. charge on each character that you type into the machine. The talk itself was
  2068. that Unix belongs to AT&T, and that it did not matter whose version that you
  2069. use. It seems that USL has become a larger version of Microsoft, a bigger
  2070. bully. If USL manages to place a leash on outside enhancements of Unix,
  2071. I can guarantee that this is the last major version of Unix that we will
  2072. see. Having extensively used software from people such as GNU, kermit, etc.
  2073. I wish we could move to an Operating System with the same amount of ties.
  2074.  
  2075. About myself - I work as a System Analyst doing programming on X.25 &
  2076. Unix, and some system administration among other things. The company
  2077. I work for is US Videotel which is in the electronic information field
  2078. (a la Prodigy, Compuserve, etc.). If you need to send email to me, you
  2079. can either to this address, with the first line addressing it to "Ravi"
  2080. or send to "ravi@usv.com". Phone # is (713)-877-4272.
  2081.  
  2082. Thanks,
  2083. --Ravi.
  2084. (Ravindran Ramachandran)
  2085.  
  2086. From: Contr Karl Vogel <c-17igp.wpafb.af.mil!vogel@uunet.UUCP>
  2087. Organization: Control Data Systems Inc.
  2088.  
  2089. wrote:
  2090.  
  2091. Mitch> Unix System Laboratories recently sued software company BSDI and the
  2092. Mitch> University of California at Berkeley, charging that BSDI's commercial
  2093. Mitch> Unix workalike and UCB's free software violated USL's intellectual
  2094. Mitch> property rights. Was USL justified in filing the suit?
  2095.  
  2096.        The first thing that came to mind when I learned about the lawsuit was
  2097.        "We're the phone company.  We don't care.  We don't have to."  I've
  2098.        followed the BSDI efforts in "Dr. Dobbs", and applaud them for their
  2099.        ingenuity and generosity.
  2100.  
  2101.        [ I know, I know; USL is not exactly the same as AT&T, but they've
  2102.        inherited some of AT&T's poor attitude.]
  2103.  
  2104.        If USL can prove beyond a shadow of a doubt that BSDI ripped them off
  2105.        by pointing to a piece of code and saying "THIS came from us, and we
  2106.        can demonstrate that to be true", I'll listen.  I have no respect for
  2107.        a thief.  However, I haven't heard about any such evidence being
  2108.        introduced, and until I do, USL is guilty of mis-using the legal
  2109.        system by trying to kill BSDI through the "chilling effect" of a
  2110.        lawsuit.  Innocent until proven guilty.
  2111.  
  2112.        I can't do anything to USL to persuade them to come up with a clear
  2113.        rights violation before they start suing someone, but I was thinking
  2114.        about writing a letter to AT&T and telling them I was switching
  2115.        long-distance carriers because of what USL is doing.  I have a
  2116.        question for the net:  would this hurt USL, or are they totally
  2117.        separate corporate entities?  How much influence does AT&T have over
  2118.        USL?
  2119.  
  2120. ---
  2121. Karl Vogel              Internet:   vogel@c-17igp.wpafb.af.mil  [129.48.19.253]
  2122. Analyst/Programmer          UUCP:   ...!uunet!c-17igp.wpafb.af.mil!vogel
  2123. Control Data Sys. Inc.              vogel%c-17igp.wpafb.af.mil@uunet.uu.net
  2124.  
  2125. Sometimes, you're the windshield .... sometimes, you're the bug.
  2126.                             --Mark Knopfler
  2127.  
  2128. From: "Daryl V. McDaniel" <illian.mnet.com!darylm@uunet.UUCP>
  2129.  
  2130.  
  2131.  
  2132. Mitch,
  2133.  
  2134. Briefly, here are my views on the USL/BSDI suit.  I have read a summary of
  2135. the complaint, ftpd from uunet, and base my comments partly on that.  This
  2136. year, our company decided to go with SVR4 to replace our aging BSD4.2 and
  2137. BSD4.3 systems.  I also base part of my response upon my experiences
  2138. bringing up SVR4.
  2139.  
  2140. USL claims that the NET2 release discloses USL and AT&T trade secrets.  The
  2141. strongest argument against this is that every aspect of the Unix operating
  2142. system is taught in schools today.  This was partly the original intent
  2143. when Unix was licensed to Universities.  One can not maintain a trade
  2144. secret while facilitating the wide disclosure of its details.
  2145.  
  2146. USL also claims that Bostic, et al, engaged in a conspiracy for the last
  2147. several years to force the regents to release USL proprietary source code.
  2148. It is difficult to prove or disprove a persons intent.  Experience leads me
  2149. to believe that this scenario is highly unlikely.  Where I have seen this
  2150. type of argument used before has always been a case of "grasping for
  2151. straws."
  2152.  
  2153. For the last several years, AT&T and USL have been promoting Unix as an
  2154. operating system for business use.  My experiences with their product span
  2155. from V6 in the early seventies, to SVR4 today.  I have watched the quality
  2156. of AT&T/USL Unix rise and fall over the years.  Product quality has been in
  2157. steady decline since SVR3.  It appears that AT&T/USL believes that the
  2158. addition of features is what makes an operating system "business ready."
  2159. During this same period, I have seen the Berkeley variant rise steadily in
  2160. quality and robustness.  From the earliest I can remember, a goal of the
  2161. group at Berkeley has been to produce an AT&T free version of Unix.
  2162.  
  2163. When our company decided that it was necessary to upgrade our old
  2164. (1985-1987 vintage) machines running BSD4.2 and BSD4.3 Unix, we decided
  2165. that we should switch to USL's SVR4 for the commercial support, robustness,
  2166. and modern-ness of a mainstream product.  It took two months to get SVR4
  2167. running to a point we could begin commercial operations using it.  Within
  2168. these two months, we identified and reported 163 different bugs of which 14
  2169. were fatal and 3 were the fault of the software vendor (not USL).  The 14
  2170. fatal bugs and remaining 146 non-fatal ones are directly attributable to
  2171. flaws in USL's product.
  2172.  
  2173. It is my belief that USL saw the availability of a low-cost product such as
  2174. BSDI's as a serious threat to their market.  With a large community of
  2175. users with access to source code, a natural maturation of the product will
  2176. take place.  The result will be a Unix product from BSDI that is robust,
  2177. performs as claimed, is well supported, and universally accepted.  Witness
  2178. the success of the GNU offerings.  The GNU C compiler is now accepted as
  2179. the "compiler of choice" on many platforms.
  2180.  
  2181. Due to the deficiencies of the USL product, only a large software
  2182. organization can afford to generate and maintain bug fixes and merge them
  2183. into subsequent USL releases.  At some point, the amount of code fixes
  2184. will exceed the size of original code.  Then we will see companies thinking
  2185. about replacing all of the USL code and having a product which they
  2186. completely control.
  2187.  
  2188. If USL wins, the world will be much worse off.  Universities and research
  2189. labs will be afraid to accept "Educational" and "Research" licenses for
  2190. companies technologies.  We will end up with many companies duplicating
  2191. effort and using valuable resources fixing and maintaining other companies
  2192. products instead of developing and maintaining their own products.  In
  2193. fact, it will significantly inhibit innovation, since the majority of new
  2194. developments are "derived" from previous developments, and USL claims that
  2195. new ideas derived from old ideas are the property of the owner of the
  2196. original idea.
  2197.  
  2198. Unfortunately, it is the opinion of our corporate lawyer that USL will win.
  2199. Not because of technical or legal merit, but because they have the money.
  2200.  
  2201. Daryl V. McDaniel        darylm@mnet.com
  2202. Principal Engineer        darylm@illian.mnet.com
  2203. Micronetics
  2204. Aloha Research Group        
  2205. 10700 SW B-H Hwy.  #420        
  2206. Beaverton, OR 97005
  2207.  
  2208. From: "David B. Teague" <wcuvax1.wcu.edu!TEAGUE@uunet.UUCP>
  2209.  
  2210.  
  2211. I am David Teague, Associate Professor of Computer Science at
  2212. Western Carolina University. I feel strongly that AT&T has
  2213. overstepped the bounds of decency in suing BSDI and others.
  2214.  
  2215. U Cal Berkeley submitted the NET 2 tape to AT&T for their perusal
  2216. and comment. They declined to do so, and ignored the NET 2 tapes
  2217. until someone actually began to develop an operating system by
  2218. filling in the gaps in that software. Then they sue, damaging
  2219. CMU's Mach effort, the FSF's Hurd effort, Jolitz's effort, and the
  2220. one commercial effort, BSDI.
  2221.  
  2222. All responsible people should boycott AT&T, changing any computer
  2223. support to another company, changing the long distance phone
  2224. service from AT&T to MCI, or Sprint, and at least writing to them
  2225. of their displeasure. (that's my opinion) 
  2226.  
  2227.  
  2228.   
  2229.   David B Teague   teague@wcuvax1.wcu.edu 
  2230.   
  2231.   Boycott AT&T. Evil be to the Evil Empire in same measure as they
  2232.   meet out to users of NET-2.
  2233.   
  2234.   Western Carolina University     BAN USER INTERFACE COPYRIGHTS & 
  2235.   Room 308 Stillwell Building     SOFTWARE PATENTS. For info email
  2236.   Computer Science Dept           the League for Programming Freedom
  2237.   Cullowhee, NC 28723                   league.@prep.ai.mit.edu.
  2238.   
  2239.   Justice William O. Douglas wrote: "As the night fall does not come
  2240.   at once, neither does oppression. It is in such twilight that we
  2241.   must all be aware of change in the air - however slight - lest we
  2242.   become unwitting victims of the darkness.
  2243.   
  2244.   
  2245. From: David Muir Sharnoff <tfs.com!muir@uunet.UUCP>
  2246.  
  2247.  
  2248. Sigh, when will people learn to do backups.
  2249.  
  2250. (Answer: it takes about five years on the average
  2251. I think, because you have to loose a few things
  2252. before the message gets through.)
  2253.  
  2254. I have no idea what I sent to you the first time.
  2255. I now keep copies of my outgoing mail. 
  2256.  
  2257. Anyway...
  2258.  
  2259.      Unix Systems Laboratories recently sued software company BSDI and the
  2260.      Regents of the University of California at Berkeley, charging that BSDI's
  2261.      commercial Unix workalike and UCB's free software violated USL's
  2262.      intellectual property rights. Was USL justified in filing the suit?
  2263.  
  2264. At one time, AT&T ran an office that you could submit your source code
  2265. to for evaluation.  They would tell you if they thought that it 
  2266. infringed on their intellectual property.  The decision was made by
  2267. computer scientists rather than lawyers.  One can only theorize about 
  2268. why they shut down the office, but my guess is that they felt that they
  2269. could keep ownership of more code if the decisions were made by 
  2270. the courts.
  2271.  
  2272. USL's actions are reprehensible because they are using legal tactics
  2273. desiged solely to expend the limited resources of the much smaller
  2274. company that they are fighting.  If they were interested in resolving 
  2275. fairly the real issues in the case they would be pursuing it differently.
  2276.  
  2277. Technically, they are light-years behind if you ignore the 
  2278. 75% of sysVR4 is derrived from BSD.  Their approach shows them to be 
  2279. operating under the "if you can't innovate, litigate" creed.  
  2280.  
  2281. Assuming that BSDI does not suffocate in the legal slime and that
  2282. UC Berkeley actually fights, the suit will probably resolve around
  2283. creating a new legal definition for derivative work.  If USL/AT&T 
  2284. wins completly then they may gain retroactive ownership of most of 
  2285. the operating systems research done in the last seventeen years.  This 
  2286. will be an indirect death-blow to UNIX and possibly the US software
  2287. industry.  The suit has already caused projects that would have
  2288. benefitted many to be cancelled or delayed.
  2289.  
  2290. To protest AT&T's attemted enforcement of their backing-store patent,
  2291. I switched to MCI.  To protest this suit, I've dropped my AT&T Universal
  2292. Card.  Please join my boycott.
  2293.  
  2294.  
  2295.  
  2296. David Muir Sharnoff
  2297. Systems Engineer
  2298. TRW Financial Systems
  2299.  
  2300. Organization: eklektix - Boulder, Colorado
  2301. From: Dick Dunn <raven.eklektix.com!rcd@uunet.UUCP>
  2302.  
  2303.  
  2304. Well, just consider it this way:  I sent a response and kept a copy.  After
  2305. a few days, I got an acknowledgment, at which point I deleted my copy.  If
  2306. you think I'm going to write another one, think again.
  2307.  
  2308. I expect you've lost the more thoughtful responses.  The folks who will
  2309. write again, except for those who actually kept copies of their mail all
  2310. this time, are more likely to be the rabid ones.  I don't know how you can
  2311. patch around this one; I don't think you can.  It's not like starting over
  2312. from scratch on the question.
  2313.  
  2314. It's OK for me...other trade rags (and a newspaper) have phone-interviewed
  2315. me about the suit, so my opinions will show up here and there.
  2316. ---
  2317. Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
  2318.                 Cats!
  2319.     by duke.cs.duke.edu (5.65/2.22G/4.1.1)
  2320.  
  2321. From: "Gregory G. Woodbury" <wolves.durham.nc.us!ggw@uunet.UUCP>
  2322.  
  2323.  
  2324. Gregory G. Woodbury
  2325. Duke University Center for Demographic Studies
  2326. Systems Programmer
  2327.  
  2328.     I find myself vary confused about this issue.  Based on the
  2329. discussions on the net, and the readings that I have done on the event
  2330. in various places, it seems to me that there is some sort of violation
  2331. of the spirit of the intellectual property rights that AT&T/USL hold in
  2332. the Unix brand Operating System, but (IMO) not a technical violation of
  2333. the letter of the licenses and laws.
  2334.     The filings by USL in the case (as published) are so vague and
  2335. unclear as to which parts of the code they are claiming infringement on,
  2336. and the possibilities that they may be attempting to compare a modern
  2337. UNIX source code version against the BSD source code where there may be
  2338. large swaths of the BSD enhancements integrated into the USL code, make
  2339. me very uncomfortable with USL's intentions in the case.
  2340.     The "politics" of the suit, also, cannot be ignored.  There are
  2341. a number of "Edition 7" derived "unix-like" products out there on the
  2342. market, that AT&T and USL could potentially go after, but they decide to
  2343. pick on BSDI and UCB-CSRG (while ignoring the "volunteer effort" OS also
  2344. derived from the Net-2 sources.)  This certainly appears to be intended
  2345. to have a "chilling" effect on developing systems based on the BSD Net-2
  2346. sources.
  2347. -- 
  2348. Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
  2349. UUCP: ...dukcds!wolves!ggw   ...duke!wolves!ggw           [use the maps!]
  2350. Domain: ggw@wolves.Durham.NC.US  ggw@cds.duke.edu  ggw%wolves@duke.cs.duke.edu
  2351. [The line eater is a boojum snark! ]           <standard disclaimers apply>
  2352.  
  2353.  
  2354.  
  2355. From: John Hensley <usenix!clinicom.com!john@uunet.UUCP>
  2356. Organization: CliniCom Incorporated, Boulder, CO
  2357.  
  2358.  
  2359. Justified or not, it's the absolute wrong thing to do when trying to sell
  2360. an infant UNIX product to users who have been enjoying CSRG's work in one
  2361. form or another for years. Destiny/UNIXware/whatever was looking like a strong
  2362. competitor to Windows NT, Solaris, Next Step and crew, but now I hope this
  2363. will be the last we hear of USL.
  2364.  
  2365.  -------------------------------------------------------------------------------
  2366.  
  2367. John Hensley
  2368. Systems Administrator
  2369. CliniCom, Incorporated
  2370. john@clinicom.com
  2371.  
  2372. (P.S. Thanks for screwing up -- I missed the original request!)
  2373.  
  2374. --
  2375. John Hensley           |
  2376. john@clinicom.com      | "You think slower when you graze." -- Holling
  2377. jhensley@nyx.cs.du.edu |
  2378.  
  2379. From: Jon Peatfield <cus.cam.ac.uk!jp107@uunet.UUCP>
  2380.  
  2381. Well I was just about to delete my copy of that mail...
  2382.  
  2383. I wrote:
  2384. --include-the-text--
  2385.  
  2386. Well, I've read the initial complaint, but havn't had a chance to look
  2387. at the extended suit yet, and this is the big one since it names UCB
  2388. and all the Regents of UC for claiming that NET/2 is free of any AT&T
  2389. code... so this is entirely based on the first complaint and what I've
  2390. read on the net.
  2391.  
  2392. It would appear that USL are attempting to force a small startup
  2393. company into failing, by making them fight a legal battle which
  2394. appears to be totally without cause.  In particulat the NET/1 and
  2395. NET/2 releases have been made avaialable by the UCB for several years
  2396. without complaint by USL.  Indeed in neither of the complaints have
  2397. USL explained what they believe to be proprietary to USL in the NET/2
  2398. release.  They are now demanding some form of comparison between
  2399. versions of code -- and here I'll assume they want a comparison
  2400. between the last version AT&T shipped to UCB many years ago and the
  2401. NET/2 -- yet they have had access to NET/2 since it's release by UCB,
  2402. and can't point to the offending bits...
  2403.  
  2404. While I would not want to deny a company the right to pursue it's
  2405. rights to prevent unauthorised use of proprietary material, this does
  2406. not seem to be the case here.  Perhaps USL are just worried about how
  2407. Destiny will fair against the much cheaper offerings made possible by
  2408. the release of the BSD NET/2 code.  Unix and Destiny are trademarks of
  2409. AT&T and USL (I think.)
  2410.  
  2411.  
  2412. My name:    Jon Peatfield
  2413. My job:        Computer Officer
  2414. My university:    Cambridge University (Department of Applied Maths and
  2415.         Theoritical Physics) U.K.
  2416. My phone number: +44 223 338752 (work) +44 223 845229 (home)
  2417. (answering machine at home, since this is GMT +1 (BST actually), my
  2418. home number is probably more useful for leaving messages in your
  2419. daytime.  I assume you know how to dial international calls...)
  2420. --end-of-include--
  2421.  
  2422. Since then I've read the second complaint too, and I can't see any
  2423. reasonable interpretation which should stand up in a court of law.
  2424. However, courts being what they are once can never tell, since the
  2425. court can be easily pursuaded by good lawyers, rather than on the
  2426. technical issues.  I'm hoping for it to get thrown out, but I've heard
  2427. of worse things getting accepted by the courts.
  2428.  
  2429. -- Jon Peatfield
  2430.  
  2431. From: Jonathan Eunice <cs.pitt.edu!jonathan@uunet.UUCP>
  2432.  
  2433.  
  2434.     Unix Systems Laboratories recently sued software company BSDI and the
  2435.     Regents of the University of California at Berkeley, charging that 
  2436.     BSDI's commercial Unix workalike and UCB's free software violated USL's
  2437.     intellectual property rights. Was USL justified in filing the suit?
  2438.  
  2439. Of course USL is justified in taking any and all legal actions its
  2440. management deems necessary to protect its property and its rights.
  2441. Whether our laws properly define property and intellectual rights
  2442. relative to software is a completely different question, as is whether
  2443. attacking BSDI or UCB will best serve USL's ends and interests.  But
  2444. the law gives "the rules," and everyone (including USL) has a right to
  2445. play as agressively as possible within those rules.
  2446.  
  2447. Where USL is clearly unjustified is its continual hyping of the
  2448. "openness" of its key product, UNIX System V Release 4.  The recent
  2449. legal action simply confirms an oft-hidden message delivered several
  2450. years ago with the AT&T-internal slogan, "UNIX(r) is a five-letter
  2451. word"--ie, that UNIX System V is proprietary and USL has a selfish
  2452. interest in it no weaker than IBM's interest in MVS, or DEC's in VAX/VMS.
  2453.  
  2454. We are deluded if we believe that UNIX System V (and its companion
  2455. "standard," SVID) is magically "open," and that USL cares primarily
  2456. about advancing peace, goodwill, and good operating systems among
  2457. humanity.  USL is a business, with a bottom line.  SRV4 and SVID are
  2458. only slightly less proprietary than SAA or the Macintosh, and equal on
  2459. the proprietary/open continuum to AIX, A/UX, Coherent, DG/UX, DYNIX,
  2460. ES/IX, HP-UX, ODT, Solaris, ULTRIX or any of the other
  2461. standards-oriented systems based on what began as "Unix" two decades
  2462. ago inside BTL. 
  2463.  
  2464. Jonathan Eunice
  2465. Research Manager/Software
  2466. D.H. Brown Associates
  2467.  
  2468. From: Karl Lehenbauer <sugar.neosoft.com!karl@uunet.UUCP>
  2469. Organization: NeoSoft Communications Services -- 
  2470.  
  2471. I think that as long as USL saw the NET-2 release as nothing more than a
  2472. grab bag of software technology, they didn't have a problem with it.
  2473. When they discovered that talented hackers had been able to cobble together
  2474. the missing pieces and produce a credible 4.3 BSD system (allegedly) free of 
  2475. their copyrights, they totally freaked.
  2476.  
  2477. Ironically, many of the similarities between the two systems came from
  2478. AT&T/USL adopting code from Berkeley.  For a GUI, both systems run X-windows, 
  2479. which of course originated at MIT.
  2480.  
  2481. Karl Lehenbauer
  2482. Member of Technical Staff
  2483. NeoSoft
  2484. -- 
  2485. -- Email info@NeoSoft.com for info on getting interactive Internet access.
  2486. You will now awaken feeling relaxed and refreshed, remembering everything 
  2487. you've read except the details of the Omega contingency plan.
  2488. ---
  2489. -- Email info@NeoSoft.com for info on getting interactive Internet access.
  2490. You will now awaken feeling relaxed and refreshed, remembering everything 
  2491. you've read except the details of the Omega contingency plan.
  2492. From: Karl Lehenbauer <sugar.neosoft.com!karl@uunet.UUCP>
  2493.  
  2494.  
  2495.  
  2496. Forgive me.  We are located in Houston, Texas.
  2497.  
  2498. -- 
  2499. -- Email info@NeoSoft.com for info on getting interactive Internet access.
  2500. You will now awaken feeling relaxed and refreshed, remembering everything 
  2501. you've read except the details of the Omega contingency plan.
  2502.  
  2503.  
  2504. From: Michael Bentley <nuchat.sccsi.com!michael@uunet.UUCP>
  2505. Organization: /etc/organization
  2506.  
  2507.  
  2508. I am no lawyer.  As a non-lawyer, I feel confident in saying that USL
  2509. is doing the Wrong Thing.  I read through all the documents (from uunet)
  2510. related to the matter, and have concluded that the AT&T/USL position is
  2511. one of random flameage (and wholly content free).
  2512.  
  2513. If USL insists on trying to keep the world from using the Unix name (the
  2514. only specific complaint that I saw in the aforementioned documentation), I
  2515. think we can all learn to say GNU!
  2516.  
  2517. Michael Bentley
  2518. no company (unemployed)
  2519. no title (usually programmer)
  2520.  
  2521. -- 
  2522. +============================================================+
  2523. |  Michael S. Bentley (Looking for a way back to California) |
  2524. |  VoiceNet :                                                |
  2525. |  E-mail   : michael@nuchat.sccsi.com                       |
  2526. +============================================================+
  2527.  
  2528. From: Multics <acm.rpi.edu!multics@uunet.UUCP>
  2529. Organization: The Voice of Fate
  2530.  
  2531. Since UNIX is based so strongly on Multics, shouldn't Honeywell consider
  2532. sueing AT&T for the same reasons AT&T is sueing BSDI and UCB?
  2533.  
  2534. I've heard that the older UNIX manuals even acknowledge Multics as the
  2535. parent of UNIX.
  2536.  
  2537. Richard Shetron, John Grady Inc.
  2538. I'm not availibe by phone during the day, though I will be home this
  2539. monday packing for my vacation.  (518) 271-6005.  I'll be in and out
  2540. most of the day.
  2541. -- 
  2542. Richard Shetron  multics%acm.rpi.edu@rpi.edu  multics@hermes.acm.rpi.edu
  2543. What is the Meaning of Life?      There is no meaning,
  2544. It's just a consequence of complex carbon based chemistry; don't worry about it
  2545. The Super 76, "Free Aspirin and Tender Sympathy", Las Vegas Strip.
  2546. From: Multics <acm.rpi.edu!multics@uunet.UUCP>
  2547.  
  2548. Richard Shetron, John Grady Inc., 358 Broadway suite 402,
  2549. Saratoga Springs, NY 12180.
  2550.  
  2551. NOTE:we do not use unix at work, I only have access at work.  My employer
  2552. knows nothing about anything except Bluebird SuperDos and Wang 2200.
  2553.  
  2554. -- 
  2555. Richard Shetron  multics%acm.rpi.edu@rpi.edu  multics@hermes.acm.rpi.edu
  2556. What is the Meaning of Life?      There is no meaning,
  2557. It's just a consequence of complex carbon based chemistry; don't worry about it
  2558. The Super 76, "Free Aspirin and Tender Sympathy", Las Vegas Strip.
  2559. From: Multics <acm.rpi.edu!multics@uunet.UUCP>
  2560.  
  2561. It was written originally to run Data General Business basic on a pc in
  2562. multi-user mode.  It also runs Niakwa Basic-2C a wang 2200 emulator,
  2563. HIGH-C, and I believe a DEC DIBOL compiler of some sort.
  2564.  
  2565. There are no directories, instead there are 64 user groups per disk.
  2566.  
  2567. -- 
  2568. Richard Shetron  multics%acm.rpi.edu@rpi.edu  multics@hermes.acm.rpi.edu
  2569. What is the Meaning of Life?      There is no meaning,
  2570. It's just a consequence of complex carbon based chemistry; don't worry about it
  2571. The Super 76, "Free Aspirin and Tender Sympathy", Las Vegas Strip.
  2572. From: Multics <acm.rpi.edu!multics@uunet.UUCP>
  2573.  
  2574. Its neither DOS compatable or better the DOS.  MS-DOS 2.0 and maybe even
  2575. 1.0 are better, except SuperDos is multiuser.  It uses technology that I
  2576. always thought was proven obsolete by IBM when they invented the methods.
  2577. All users get 1 fixed size partition allocated when the system boots.
  2578. The older versions designed to run on the PC limits the partition size to
  2579. remaining memory in the base partitioin or 64K in expanded memory.  the
  2580. newer version allows use of expanded memory on 386+ machines and partition
  2581. size is limited to memory size, which I think is limited to 16MB total.
  2582.  
  2583. There is no command processor, i/o redirection, etc.
  2584.  
  2585. Whatever I want, JGI is a small software firm, John is the president and
  2586. holds all officer's positions and I'm the programming staff.  Thee is a
  2587. part time secretary.  We are listed in D&B's business credit ratings listings.
  2588. When John wants me to sound important, my title is sometime listed as
  2589. Manager of software R&D or similier types of titles.  I just tend to call
  2590. myself a programmer/analyst/software engineer.
  2591.  
  2592. -- 
  2593. Richard Shetron  multics%acm.rpi.edu@rpi.edu  multics@hermes.acm.rpi.edu
  2594. What is the Meaning of Life?      There is no meaning,
  2595. It's just a consequence of complex carbon based chemistry; don't worry about it
  2596. The Super 76, "Free Aspirin and Tender Sympathy", Las Vegas Strip.
  2597.     by himnariki.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88)
  2598.  
  2599.  
  2600. From: 'Olafur Gudmundsson <cs.umd.edu!ogud@uunet.UUCP>
  2601.  
  2602.  
  2603. Forwarded old message (slightly edited), with an addition 
  2604.  ------- Forwarded Message
  2605.  
  2606. From: ogud (Olafur Gudmundsson)
  2607.  
  2608.  
  2609. You asked about my oppinion on the USL suit. 
  2610.  
  2611. It stinks!!
  2612. After reading the brief filed with the court, my reaction one of shock.
  2613. These USL people are out of sync with the real world. 
  2614. BSD has contributed a lot to the evolution of UNIX while the
  2615. contributions by USL are marginal (at best). V32 is a 14 year old system
  2616. that was outdated by BSD 4.1 and AT&T own Release 7. All the ideas of 
  2617. UNIX have been well documented in books and articles over the last decade
  2618. so what is the fuzz about.  The fuzz is about control USL wants to become
  2619. single source of UNIX (impossible dream given who works there), they must 
  2620. think that they can run BSDI out of business and that is a prerequisite 
  2621. for gaining monopoly on UNIX, and guarantees them and their lawyers 
  2622. lifetime employment!
  2623.  
  2624. Or their goal is to gain 100% controll of where people like me,
  2625. that have seen UNIX source code, work. If they want to dictate to me and
  2626. othere where we can work and what we are permitted to do. They will end their
  2627. life the same way as the pigs in "Animal farm".
  2628.  
  2629. - -    -    -    -    -    -    -    -    -
  2630. Olafur Gudmundsson  Dept. of Computer Science University of Maryland
  2631. Internet: ogud@cs.umd.edu               UUCP: {...!}uunet!mimsy!ogud
  2632. UPS: College Park MD. 20742                                         
  2633. Research Faculty 
  2634.  ------- End of Forwarded Message
  2635.  
  2636. From: Paul Nash <frcs.alt.za!paul@uunet.UUCP>
  2637.  
  2638.  
  2639.  
  2640. For a number of reasons, most of which other have stated on the net, I
  2641. feel that USL are _not_ justified.  They certainly give the impression
  2642. of being yet another monolith that is getting upset at seeing someone
  2643. else trying to introduce competition.  Can you say "phone company"?
  2644. They are acting just like IBM :-(.
  2645.  
  2646. Paul Nash, M.Eng
  2647. Network Development Consultant, CSIR
  2648. PO Box 395, Pretoria, 0001 South Africa
  2649.  
  2650.  ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---
  2651.  Paul Nash                                         paul@frcs.Alt.ZA
  2652.  Box 12475, Onderstepoort, 0110 South Africa         +27-12-5611879
  2653.  
  2654.       "You don't want to get locked into open systems" -- IBM
  2655. From: Paul Nash <frcs.alt.za!paul@uunet.UUCP>
  2656.  
  2657.  
  2658. CSIR == Council for Scientific and Industrial Research (sort-of NSF
  2659. clone [-ish]).  I am a "Network Consultant" == resident guru.
  2660.  
  2661.     paul
  2662.  
  2663.  ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---
  2664.  Paul Nash                                         paul@frcs.Alt.ZA
  2665.  Box 12475, Onderstepoort, 0110 South Africa                       
  2666.  
  2667.       "You don't want to get locked into open systems" -- IBM
  2668.           Thu,  3 Sep 92 14:34:20 PST
  2669. From: ssd0.laafb.af.mil!PaussaVC@uunet.UUCP
  2670.  
  2671. Oh, sorry
  2672. Los Angeles AirForce Base  Space & Missle Center / Something or other I've 
  2673. never been able to figure out the rest of it.
  2674.  
  2675. Chuck
  2676.  ------------------------------------------------------------------------------
  2677.  
  2678. Organization: Taronga Park BBS
  2679. From: Peter da Silva <taronga.com!peter@uunet.UUCP>
  2680.  
  2681.  
  2682. Smooth. Let's see if I can recall...
  2683.  
  2684.                                                          ^^^^^^^^^ filing?
  2685.  
  2686. No.
  2687.  
  2688. If they'd done so three years ago when Berkeley started shipping large
  2689. subsets of "freed" code, before they'd established an expectation that
  2690. this code was indeed free, maybe. As it is, they've encouraged a lot of
  2691. people to invest a lot of resources in this code, and are clearly trying
  2692. to use FUD to hurt a potential competitor rather than simply protect
  2693. their legitimate rights. The fact that they waited until the 11th hour
  2694. to include the Net/2 release in the suit bears this out... if their
  2695. trade secrets were what they were worrying about they'd have hit THAT
  2696. first, and hit Net/1 as well.
  2697.  
  2698. Peter da Silva
  2699. Lead Software Engineer
  2700. Ferranti International Controls Corporation
  2701. ---
  2702.                                                                 `-_-'
  2703.                          Have you hugged your wolf today?        'U`
  2704.  
  2705. Peter da Silva, Taronga Park BBS, Houston, TX  
  2706.  
  2707.  
  2708. From: Phil Nelson <henson.cc.wwu.edu!phil@uunet.UUCP>
  2709.  
  2710.  
  2711. This is a hard question to answer.  My "reaction" is no.  If they are
  2712. claiming actual copyright violation, they I can see it as "justified."
  2713. On the other hand, if they are claiming a "look-and-feel" type
  2714. violation, then I think they are not justified in filing suit.
  2715.  
  2716. From what I have heard (not know), USL is not claiming that BSDI or UCB
  2717. is distributing AT&T (or USL) copyrighted materials, just that it looks
  2718. similar.  IF this really is the case, then I think that USL is wrong,
  2719. and if USL does not withdraw their suit, then the entire UN*X community
  2720. should join a boycott against AT&T long distance service.  Such a
  2721. boycott should be publicized.
  2722.  
  2723.  
  2724. Phil Nelson
  2725. Assistant Professor of Computer Science
  2726. Western Washington University
  2727. Bellingham, WA 89226-9062
  2728.  
  2729. Member of the League for Programming Freedom
  2730.  
  2731.  
  2732. From: Russell Nelson <crynwr.com!nelson@uunet.UUCP>
  2733. Organization: Crynwr Software
  2734.  
  2735.  
  2736.  
  2737. Moreover, was it wise?  With NT nipping at Unix's heels, should the
  2738. "real" Unix vendors be arguing with each other?  Better 10% of a size
  2739. N^2 market than 90% of a size N market...
  2740.  
  2741. -- 
  2742. -russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
  2743. Crynwr Software            Crynwr Software sells packet driver support.
  2744. 11 Grant St.                                 
  2745. Potsdam, NY 13676                          
  2746.  
  2747. From: Russell Nelson <crynwr.com!nelson@uunet.UUCP>
  2748. Organization: Crynwr Software
  2749.  
  2750.  
  2751.  
  2752. Oh, why, President, of course.  Unless you want me to be Head of R&D,
  2753. or maybe, Clerk, or perhaps just Head Janitor.  :)
  2754.  
  2755. -- 
  2756. -russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
  2757. Crynwr Software            Crynwr Software sells packet driver support.
  2758. 11 Grant St.
  2759. Potsdam, NY 13676
  2760.  
  2761. From: Ted Lemon <lupine!mellon@uunet.UUCP>
  2762.  
  2763.  
  2764. It is clear from reading the two USL complaints (which I obtained from
  2765. uunet) that at least one motivation of this lawsuit is to drive BSDI out
  2766. of business by exposing them to a long and involved legal process.    My
  2767. reason for believing this is that the suit makes a very large number of
  2768. very broad, vague claims, and also proposes a rather bizarre conspiracy
  2769. theory that makes no sense based on my knowledge of the people involved.
  2770. Barristry of this kind is a shameful misuse of our legal system.
  2771.  
  2772. It is possible that there may be some code in the Net2 release which is
  2773. derived from the AT&T Unix 32V sources that Berkeley received from AT&T
  2774. many years ago, and if that is the case, Berkeley should certainly be
  2775. required to remove that code from any public BSD distribution.   However,
  2776. at this late date it's hard to imagine what that code might be, and it's
  2777. even harder to imagine how the release of that code could cause significant
  2778. harm to USL.
  2779.  
  2780. Of course, it's quite obvious how the use of Net2 to produce a UNIX-like
  2781. system without requiring a UNIX license could harm USL, but removing any
  2782. remaining 32V code from the Net2 distribution probably wouldn't significantly
  2783. impede the implementation of a UNIX-like system from Net2.   USL's claims
  2784. regarding trade secrets are clearly nonsense - very little about UNIX as
  2785. it is today is in any way based on UNIX as it was at the time of 32V, and
  2786. that part of the interface that is the same is well-known to the computing
  2787. community and cannot be covered by any sort of trade secret protection.
  2788.  
  2789. I am a senior software engineer at NCD, and the opinions expressed above
  2790. are my own and have no known (by me) relationship to the opinions of NCD.
  2791.  
  2792.                 _MelloN_
  2793.  
  2794. From: George W Herbert <lurnix.com!gwh@uunet.UUCP>
  2795.  
  2796.  
  2797.     As anyone who's been reading the Usenet
  2798. discussions can attest, the biggest problem with
  2799. the USL/BSDI/UCB suit is confusion over exactly
  2800. what it is.
  2801.     Is it a claim that there is AT&T code
  2802. left in the Berkeley Net/2 release?
  2803.     Is it an attempt to claim that anything
  2804. that walks, talks, and swaps like UNIX is USL
  2805. property?
  2806.     Or is it a fishing expedition by USL
  2807. trying to harrass BSDI and Berkeley?
  2808.     We can't tell.  While the suit makes some
  2809. explicit claims (that Net/2 infringes on USL's
  2810. trade secrets, as does BSDI's work) it doesn't
  2811. tell us wether they refer to bits of code or the
  2812. functionality or the concept.  USL hasn't
  2813. come clean and explained exactly what they're
  2814. referring to, and Berkeley and BSDI apparently
  2815. don't know.
  2816.     Personally, I dislike the suit.  It seems,
  2817. and I admit this is just a feeling, like USL
  2818. is trying to claim that anything that works
  2819. like USL Unix and looks sort of like AT&T Unix
  2820. is theirs.  It seems like a nasty turnabout from
  2821. the previous AT&T position of letting unencumbered
  2822. sections of BSD releases be freely released
  2823. to the world.  But, like just about everyone else
  2824. I don't really know.  And that's what worries me
  2825. the most, right now.
  2826.  
  2827. -George William Herbert
  2828. Analyst
  2829. Lurnix
  2830. Berkeley, CA
  2831.  
  2832. From: Doug Carter <htbawd.rain.com!dougc@uunet.UUCP>
  2833.  
  2834.  
  2835.  
  2836. As in the past, AT&T seems only to care about UNIX after someone
  2837. does something meaningful with it. The fine efforts of the people
  2838. at Berkeley turned a bunch of development tools into a useful 
  2839. operating system. It was that same effort that got AT&T seeing 
  2840. enough dollar signs for them to produce System V. Now that Berkeley
  2841. has finished the job, the only way AT&T can figure to get a cut is
  2842. through litigation. AT&T is to be commended for the concepts and 
  2843. methods that UNIX has brought to all computing environments. They
  2844. are to be criticized for their continued mindless manangement of
  2845. UNIX, a global success, despite their folly.
  2846.  
  2847.  
  2848.     Doug Carter
  2849.     A satisfied BDSI customer
  2850.     Beaverton, Oregon.
  2851.  
  2852.  
  2853. From: ssd0.laafb.af.mil!PaussaVC@uunet.UUCP
  2854.  
  2855. Gosh, I would love to have a free (UCB), or low cost (BSDI), full blown Unix 
  2856. on my desktop.  Then I wouldn't need OS/2.  Unfortunately, since USL owns the 
  2857. Unix name and source code, and both UCB and BSDI had access to that source 
  2858. code, it is likely the code in the UCB and BSDI products infringes on the USL 
  2859. copyright.  It's not nice to build a house with stolen lumber.  And though I 
  2860. hate lawyers, it is nice to have snakes in the grass when the gophers are 
  2861. nibbling at your garden.
  2862.  
  2863. Chuck Paussa
  2864. Sr Systems Engineer
  2865. LAAFB SMC/SCTMA
  2866. Los Angeles, CA
  2867.  
  2868.  
  2869. From: watson.ibm.com!uri@uunet.UUCP
  2870.  
  2871. Hello,
  2872.     To answer your question - USL had absolutely no
  2873.     moral or technical rights to file their
  2874.     completely unjustified lawsuit
  2875.     against BSDI.
  2876.  
  2877.     This opinion is mine and has nothing to do with
  2878.     my employer.
  2879.  
  2880.     Uri Blumenthal
  2881.     Research Staff Member.
  2882.  
  2883.  
  2884. From: Dave Stokes <ucsd.edu!comtec!stokes@uunet.UUCP>
  2885.  
  2886.  
  2887. I glad that when the wheel was invented that nobody claimed
  2888. intellectual 'property' or we would all still be walking or
  2889. riding horses!  I guess U$L is now free to go after MINIX
  2890. since that also is a work alike.  It seems like U$L is picking
  2891. off the 'commerical easy targets' and maybe they'll go after
  2892. the CP/M folk next!
  2893.  
  2894. David Stokes
  2895. ORINCON Corp
  2896.  
  2897.  
  2898. From: merlin <usc.edu!merlin%neuro.usc.edu@uunet.UUCP>
  2899.  
  2900.  
  2901. The copyright law is intended to protect the right to profit from one's
  2902. writings by forbidding plagiarism and/or wholesale duplication without
  2903. just compensation to the author.  In the present case, USL is claiming
  2904. a property interest in software designed and written by a large number
  2905. of contributors working in government laboratories, public universities, 
  2906. and private organizations throughout the world.  The 4.3BSD-NET2 source 
  2907. code is a copyrighted collection of programs owned by the U. C. Regents,
  2908. publically certified as containing no source code belonging to AT&T/USL,
  2909. and licensed for use, modification, and redistribution for any purpose.
  2910. U. C. Regents carefully screened all contributions to the 4.3BSD-NET2 in
  2911. order to avoid any possible infringement of code derived from AT&T UNIX.
  2912. As a consequence, USL appears to have no legitimate legal basis for the
  2913. present lawsuit against U. C. Regents and Berkeley Software Design, Inc.
  2914.  
  2915.  ------------------------------------------------------------------------------
  2916. Alexander-James Annala
  2917. Principal Investigator
  2918. Neuroscience Image Analysis Network
  2919. HEDCO Neuroscience Building, Fifth Floor
  2920. University of Southern California
  2921. University Park
  2922. Los Angeles, CA 90089-2520
  2923.  
  2924.  
  2925.  
  2926. From: pjw@math30.sma.usna.navy.mil
  2927.  
  2928. The current legal situation (patents, copyrights) re software is a mess.
  2929. This is an area the US is the world leader in. It won't be if we keep
  2930. extracting money from businesses to have lawyers debate things in court,
  2931. particularly since no-one seems to have the wit or grace to admit that
  2932. *anything* is obviously right or wrong today (example: politicians).
  2933. Nor will the US succeed if small software businesses are excluded by forcing 
  2934. legal costs (e.g. patent searches) up them.
  2935.  
  2936. ATT vs BSDI is not a clear-cut issue either way, but is certainly part of
  2937. this obnoxious trend towards litigation as the basis for business competition.
  2938. Whatever happened to making a better product or doing a better job of
  2939. marketing?
  2940.  ----------------------------------------------------------------------
  2941.   Dr. Peter J. Welcher            EMAIL: pjw@math30.sma.usna.navy.MIL
  2942.   Mathematics Department, M/S 9E
  2943.   572 Holloway Road
  2944.   U.S. Naval Academy              
  2945.   Annapolis, MD  21402-5002
  2946.  ----------------------------------------------------------------------
  2947.  
  2948.  
  2949. From: pjw@math30.sma.usna.navy.mil
  2950.  
  2951.  
  2952. Professor. Didn't my signature have it ?
  2953. I do/did s/w consulting, which my have some influence on why I think
  2954. the current s/w patent situation is beyond absurd. It 
  2955. in principle puts small guys
  2956. out of business writing new software!
  2957.  ----------------------------------------------------------------------
  2958.   Dr. Peter J. Welcher            EMAIL: pjw@math30.sma.usna.navy.MIL
  2959.   Mathematics Department, M/S 9E 
  2960.   572 Holloway Road
  2961.   U.S. Naval Academy              
  2962.   Annapolis, MD  21402-5002
  2963.  ----------------------------------------------------------------------
  2964.  
  2965.  
  2966. From: apollo.hp.com!sommerfeld@uunet.UUCP
  2967.  
  2968. Take two.
  2969.  
  2970. And do better backups in the future!
  2971.  
  2972.  ------- Forwarded Message
  2973.  
  2974. From: sommerfeld@apollo.hp.com
  2975.  
  2976. My name is Bill Sommerfeld; I'm a software engineer employed by, but
  2977. by no means speaking for, Hewlett Packard. I can be reached at
  2978. 1-508-436-4352 or 1-617-396-5661.
  2979.  
  2980.        Unix System Laboratories recently sued software company BSDI
  2981.        and the University of California at Berkeley, charging that 
  2982.        BSDI's commercial Unix workalike and UCB's free software 
  2983.        violated USL's intellectual property rights. Was USL justified
  2984.        in filing the suit?
  2985.  
  2986. No.  USL and/or AT&T once ran a service by which universities could
  2987. determine whether or not source code was "contaminated" with source
  2988. from UNIX; however, they stopped doing this several years ago. 
  2989.  
  2990. As a result, persons connected with CSRG made a good faith effort to
  2991. separate out the code in BSD not derived from AT&T code, and made it
  2992. freely available.  Now, this is an eminently tricky process, so it's
  2993. entirely likely that a few files of AT&T code may have slipped through
  2994. the cracks and made it into NET/2 (just as AT&T code is occasionally
  2995. posted to USENET by accident).  However, instead of filing a lawsuit,
  2996. USL should have made specific complaints about specific infringements,
  2997. and UCB would most likely have taken prompt, reasonable action to
  2998. correct the problems.
  2999.  
  3000.  ------- End Forwarded Message
  3001.  
  3002.  
  3003. From: warren.mentorg.com!tom_limoncelli@uunet.UUCP
  3004.  
  3005.  
  3006. I'd be surprized if every vendor in the world selling a backup scheme 
  3007. doesn't call you to ask if you want to buy the product. :-)
  3008.  
  3009.  
  3010.  
  3011. We really can't know until USL reveals more details.  For example,
  3012. which lines of source are they talking about?  Until then, everything
  3013. is just hype.  Including this.
  3014.  
  3015. Tom Limoncelli
  3016. Mentor Graphics Corp -- IC Group
  3017. System Admin.
  3018. (not speaking for my company)
  3019. -- 
  3020. Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
  3021. "Oh! I thought it was one of those useless demos of everything that
  3022.     a GUI builder could do." -Anonymous person watching demo of
  3023.          Solaris 2.0's graphical tool for managing NIS+
  3024.  
  3025. -----------------------------
  3026.  
  3027. From: Barry Margolin <barmar@think.com>
  3028. Subject: Re: Question: which is faster 'find -exec' or 'find | xargs' ??
  3029. Date: 4 Sep 92 21:49:11 GMT
  3030. NNTP-Posting-Host: telecaster.think.com
  3031. To:       info-unix@sem.brl.mil
  3032.  
  3033. In article <1992Sep4.041033.23158@news.acns.nwu.edu> navarra@casbah.acns.nwu.edu (John Navarra) writes:
  3034. >I was experimenting with find and xargs. I issued the command
  3035. >  find . -exec ls -ld {} \;
  3036. >and the command
  3037. >  find . -print | xargs ls -ld
  3038.  
  3039. >Question: why is the xargs command MUCH faster?
  3040.  
  3041. The -exec version executes a separate ls command for each file that is
  3042. found.  The xargs version accumulates a bunch of arguments and then
  3043. executes one ls command with all of them.  The difference is all the time
  3044. spent starting up new shell and ls processes.  It's the difference between:
  3045.  
  3046.     sh -c "ls file1"
  3047.     sh -c "ls file2"
  3048.     sh -c "ls file3"
  3049.     sh -c "ls file4"
  3050.     sh -c "ls file5"
  3051.  
  3052. and
  3053.  
  3054.     sh -c "ls file1 file2 file3 file4 file5"
  3055. -- 
  3056. Barry Margolin
  3057. System Manager, Thinking Machines Corp.
  3058.  
  3059. barmar@think.com          {uunet,harvard}!think!barmar
  3060.  
  3061. -----------------------------
  3062.  
  3063. From: Mitch Wagner <wagner@utoday.com>
  3064. Subject: net.views -- which vendor is most open?
  3065. Date: 4 Sep 92 22:59:46 GMT
  3066. Followup-To: comp.unix.questions
  3067. To:       info-unix@sem.brl.mil
  3068.  
  3069.  
  3070.        Which computer and/or operating-vendor has the greatest
  3071.        commitment to open systems? Which has the least? Why?
  3072.  
  3073.  
  3074.      This question is being posted to gather responses for a regular
  3075.  opinion column in OPEN SYSTEMS TODAY called "net.views."
  3076.  
  3077.      By posting a response to this topic, you are granting
  3078.  permission for OPEN SYSTEMS TODAY us to publish your response. A
  3079.  compilation of the responses to this post will be posted here about
  3080.  two weeks from today.
  3081.  
  3082.      Please include in your response your name, your employer or
  3083.  university, your job title or class standing (that is to say, if
  3084.  you identify yourself as a student, are you a freshman, sophomore,
  3085.  junior, senior, graduate student?), and a telephone number where
  3086.  you can be reached during the daytime (overseas readers note:
  3087.  that's daytime in North America).
  3088.  
  3089.      Please be brief; try to limit your responses to two screens
  3090.  (24x80) of text, not including headers and other administrivia.
  3091.  
  3092.      Thanks!
  3093.  
  3094.                          -- mitch w.
  3095. --
  3096. Mitch Wagner, senior editor, Open Systems Today
  3097. 2353 Massachusetts Ave. Suite 47, Cambridge, MA 02140
  3098. wagner@utoday.com  (617)547-8485  CIS:70212,51  GEnie:MITCH.WAGNER  
  3099. For subscription information, please call 516/562-5882
  3100.  
  3101. -----------------------------
  3102.  
  3103.  
  3104. End of INFO-UNIX Digest
  3105. ***********************
  3106.