home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / question / 13893 < prev    next >
Encoding:
Internet Message Format  |  1992-11-24  |  69.4 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!lhc!adm!news
  2. From: postmaster@starlab.csc.com (SMTP MAILER)
  3. Newsgroups: comp.unix.questions
  4. Subject: Mail not delivered yet, still trying
  5. Message-ID: <34244@adm.brl.mil>
  6. Date: 23 Nov 92 22:21:11 GMT
  7. Sender: news@adm.brl.mil
  8. Lines: 1968
  9.  
  10.  
  11.  ----Mail status follows----
  12. Have been unable to send your mail to <DGRAY@STARLAB.CSC.COM>,
  13. will keep trying for a total of eight days.
  14. At that time your mail will be returned.
  15.  
  16.  ----Transcript of message follows----
  17. Date: 22 Nov 92 03:26:00 EST
  18. From: INFO-UNIX@BRL.MIL
  19. Subject: INFO-UNIX Digest  V17#009
  20. To: "DGRAY" <DGRAY@STARLAB.CSC.COM>
  21.  
  22. Return-Path: <info-unix-request@sem.brl.mil>
  23. Received: from SEM.BRL.MIL by milo.starlab.csc.com with SMTP ; 
  24.           Sun, 22 Nov 92 03:19:32 EST
  25. Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa25769; 21 Nov 92 7:44 EST
  26. Received: from sem.brl.mil by SEM.BRL.MIL id aa25481; 21 Nov 92 7:26 EST
  27. Date:       Sat, 21 Nov 92 07:25:52 EST
  28. From:       The Moderator (Mike Muuss) <Info-Unix-Request@BRL.MIL>
  29. To:         INFO-UNIX@BRL.MIL
  30. Reply-To:   INFO-UNIX@BRL.MIL
  31. Subject:    INFO-UNIX Digest  V17#009
  32. Message-ID:  <9211210726.aa25481@SEM.BRL.MIL>
  33.  
  34. INFO-UNIX Digest          Sat, 21 Nov 1992              V17#009
  35.  
  36. Today's Topics:
  37.                            Re: IS UNIX DEAD?
  38.                       Re: rz problems at 9600 baud
  39.                        Absurd! (Re: IS UNIX DEAD)
  40.                    Re: Need Phone line configuration
  41.              Re: Unlocking named pipes (solved + question)
  42.                         Re: IS UNIX DEAD? (long)
  43.                         FTP'able Unix tutorials
  44.             Question: How to get comd line arg of processes
  45.                   Re: Changing the owner of a process
  46.                      Re: IS UNIX DEAD? (very long)
  47.                       I/O mapping from /bin/login
  48.                              FTP question.
  49.                            Re: FTP question.
  50.                     Re: what does 8-bit clean mean ?
  51.                         Re: tcsh-like subroutine
  52.                             Milliseconds !!
  53.                   mapping extended keyboard in vi/ksh
  54.                            Re: UNIX Training
  55.                           text search software
  56.                      function calls for awkcc code
  57.                             SIGS in SoftMail
  58.                     Re: Suppressing the 'w' command
  59.                            Internet question
  60.       Can telnetd preserve environment ? Can I get one that does ?
  61.     Re: Can telnetd preserve environment ? Can I get one that does ?
  62.                       Re: Passing args to login(1)
  63.                         Re: IS UNIX DEAD (long)
  64.                     Re: Searching for E-mail package
  65.                             RE: IS UNIX DEAD
  66.                    Any terminfo compilers available?
  67.                  Re: C Source Code for Pattern Matching
  68.                    WHAT IS UNIX? (was IS UNIX DEAD?)
  69.                          Capturing tty output?
  70.                     Shell Programming for Beginners
  71.                It ain't a 24x80 world anymore. Or is it?
  72.                                cnews help
  73.                 How does a mortal become a UNIX WIZARD ?
  74.                       What's wrong with select() ?
  75.                      Re: sudo with hidden password?
  76. -----------------------------------------------------------------
  77.  
  78. From: Dave Ratcliffe <dave@frackit.uucp>
  79. Subject: Re: IS UNIX DEAD?
  80. Date: 14 Nov 92 19:06:09 GMT
  81. To:       info-unix@sem.brl.mil
  82.  
  83.  
  84.  In article <1992Nov4.081914.19741@tokyo07.info.com>, jimmy@tokyo07.info.com (Jim Gottlieb) writes:
  85.  > In article <BwxLBx.4EE@undergrad.math.waterloo.edu> papresco@undergrad.math.waterloo.edu (Paul Prescod) writes:
  86.  > 
  87.  > >Sure, you can trick Unix into being easy, but that's not the point.  The 
  88.  > >point is that it has to be SOLD layered with easy and hard levels.
  89.  > 
  90.  > I agree, and I admit to being a bit of a Unix bigot.
  91.  > 
  92.  > I tell someone how wonderful Unix is, so they go out and buy it and are
  93.  > quite disappointed when they log in for the first time and see:
  94.  > 
  95.  > $
  96.  
  97. Then tell them how to set up their .profile or .cshrc or whatever so
  98. they can get nice warm fuzzy prompts. :)
  99.  
  100.  > (or %).  Now when they tried out Unix on my system, their prompt 
  101.  > showed them what directory they were in.  Why not have a new system
  102.  > come up by default with a mildly interesting prompt (and with a color
  103.  > background on a color screen).  First impressions count for much.
  104.  
  105. Tell that to MicroSoft. After all, the first thing you see there on a
  106. new install is far from the 
  107.  
  108. PROMPT $P$G
  109.  
  110. we all would rather see. 
  111.  
  112. -- 
  113.  ...uunet!wa3wbu!frackit!dave -or-                       |  Dave Ratcliffe  |
  114.  frackit!dave@uunet.UU.NET -or- dave@frackit.uucp -or-   |  Sys. <*> Admin. |
  115.  vogon1!compnect!frackit!dave@psuvax1.psu.edu            | Harrisburg,  Pa. |
  116.  
  117. -----------------------------
  118.  
  119. From: Peter Busser <peter@global.hacktic.nl>
  120. Subject: Re: IS UNIX DEAD?
  121. Date: 18 Nov 92 01:26:59 GMT
  122. To:       info-unix@sem.brl.mil
  123.  
  124. rahardj@ccu.umanitoba.ca (Budi Rahardjo) writes:
  125.  
  126. >You want phone # or mail addres for linux ? Here's an example (taken from 
  127. >comp.os.linux today ):
  128.  
  129. Look, it's very nice of you to let me read comp.os.linux twice ;-) but the
  130. messages only say something about getting the disks, nothing else. That is,
  131. I didn't see the word ``support'' anywhere, did you?
  132.  
  133. Besides, I'm not living in Germany.
  134.  
  135. Greetings,
  136. Peter Busser
  137.  
  138. -----------------------------
  139.  
  140. From: Budi Rahardjo <rahardj@ccu.umanitoba.ca>
  141. Subject: Re: IS UNIX DEAD?
  142. Date: 18 Nov 92 19:38:33 GMT
  143.  
  144. global.hackt
  145. Sender: news@ccu.umanitoba.ca
  146. Nntp-Posting-Host: antares.cc.umanitoba.ca
  147. To:       info-unix@sem.brl.mil
  148.  
  149. peter@global.hacktic.nl (Peter Busser) writes:
  150.  
  151. >rahardj@ccu.umanitoba.ca (Budi Rahardjo) writes:
  152.  
  153. >>You want phone # or mail addres for linux ? Here's an example (taken from 
  154. >>comp.os.linux today ):
  155.  
  156. >Look, it's very nice of you to let me read comp.os.linux twice ;-) but the
  157. >messages only say something about getting the disks, nothing else. That is,
  158. >I didn't see the word ``support'' anywhere, did you?
  159.  
  160. Have you tried phoning them ?
  161.  
  162. >Besides, I'm not living in Germany.
  163.  
  164. Then find one that's in NL. (I took that posting just for an example.
  165. I didn't look carefully for other places).
  166. You're not living in Germany, so what ? You can still phone them right ?
  167. Next time, probably you want to find place one block from your home :-)
  168.  
  169. -- budi
  170. -- 
  171. Budi Rahardjo <Budi_Rahardjo@UManitoba.Ca>
  172. Unix Support - Computer Services - University of Manitoba
  173.  
  174. -----------------------------
  175.  
  176. From: Budi Rahardjo <rahardj@ccu.umanitoba.ca>
  177. Subject: Re: IS UNIX DEAD?
  178. Date: 18 Nov 92 19:51:35 GMT
  179. Sender: news@ccu.umanitoba.ca
  180. Nntp-Posting-Host: antares.cc.umanitoba.ca
  181. To:       info-unix@sem.brl.mil
  182.  
  183. papresco@undergrad.math.waterloo.edu (Paul Prescod) writes:
  184.  
  185. >>>Because that often saves (a lot of) money.
  186. >>
  187. >>I doubt it. If you insist to install the OS yourself then you better
  188. >>start learning how manage it.
  189.  
  190. >No, no, no, no, no....OS/2, Windows, DOS etc. have PROVED that you don't
  191. >have to be a system administrator to install an OS.  
  192.  
  193. Ever heard a user got confused using FDISK and trashed his partition 
  194. and don't know what to do ?
  195. Ever tried to install different mouse driver for windows and make windows
  196. hang ? How do you fix it ?
  197.  
  198. >Why do you insist on
  199. >this dogma "if you aren't computer literate enough to install Unix, you
  200. >should pay someone to do it."  
  201.  
  202. Why not ? I've seen people buying PC with DOS and Windows installed, same
  203. with UNIX. These people don't want to know how to install DOS or Windows.
  204. (I know some people who don't know how to install DOS and Windows, all
  205. they really care is Word Perfect.)
  206. Also some company will sell you the machine with UNIX pre-installed.
  207.  
  208. >Why not make unix easy enough to install
  209. >that you don't have to do either?  
  210.  
  211. Several people have pointed out that installing UNIX was easy.
  212.  
  213. -- budi
  214. -- 
  215. Budi Rahardjo <Budi_Rahardjo@UManitoba.Ca>
  216. Unix Support - Computer Services - University of Manitoba
  217.  
  218. -----------------------------
  219.  
  220. From: Dave Ratcliffe <dave@frackit.uucp>
  221. Subject: Re: rz problems at 9600 baud
  222. Date: 15 Nov 92 22:14:27 GMT
  223. Followup-To: comp.unix.questions
  224. To:       info-unix@sem.brl.mil
  225.  
  226.  
  227.  In article <Bx9EKy.2Jx@iron.hq.aflc.af.mil>, hanrahan@iron.hq.aflc.af.mil (Kevin Hanrahan) writes:
  228.  > jboggs@news.weeg.uiowa.edu (John D. Boggs) writes:
  229.  > 
  230.  > >Has anyone experienced problems using rz/sz at 9600 baud?  I just
  231.  > >bought a 9600 baud modem and am experiencing problems I've never had
  232.  > >before (at 2400).  I give my remote host the sz command, then call rz
  233.  > >using minicom's receive feature, and the computer proceeds to give me
  234.  > >all sorts of error messages one after the other (sometimes getting some
  235.  > 
  236.  > The error messages sound like the same problem we have here, but
  237.  > our setup is somewhat different.  We have PC's connected to our
  238.  > network through serial connections to TRW ACU's.  These run
  239.  > at 9600 bps, but there is no modem involved.  I have also been
  240.  > unable to use sz/rz to my PC at home thru a dialup which also
  241.  > uses a TRW ACU.  A friend of mine has successfully used sz/rz
  242.  > over a 9600 bps modem that does not go thru one of these TRW boxes.
  243.  
  244. The symptoms described by John sounds suspiciously like problems I had
  245. here for quite some time also using sz/rz. Here's what I eventually
  246. found:
  247.  
  248. There was a simple handshaking problem.  I'm using a Trailblazer+ locked
  249. at 19200 to the cpu but had callers at 2400 having blown transfers and
  250. transfer rates (with all the errors counted in) of less than 300 bps.  A
  251. temporary fix was to use the sz -w1024 [filename] command to send files
  252. with a window of 1024 bytes.  This forced the speed a bit slower than a
  253. normallly operating 2400 connection but it at least worked temporarily
  254. by forcing a break every 1024 bytes of transfer to allow an ACK/NAK to
  255. come down.  This blows the streaming capability of Zmodem but DOES work. 
  256. Note that this is with sz on a Unix machine sending to a DOS machine
  257. with a 2400 baud connection.  The same problem is likely if you are
  258. connecting at 9600 to a system with a modem locked to it's host at
  259. 19200.  UPLOADING to such a system (using rz) probably won't cause
  260. problems. 
  261.  
  262. I cured this royal pain by installing FAS drivers and 16550AFN Uarts.
  263. The previously non-existant handshaking now deals with it all and I no
  264. longer need the sz -w1024 command. A simple fix in the end. BTW, I'm
  265. using a Digiboard DigiCHANNEL PC/8 under Microport SYSV/386 here. 
  266.  
  267. As usual, your mileage may vary and this might not even be the problem
  268. you two are having but it's a place to look. 
  269.  
  270. Good luck. 
  271.  
  272. -- 
  273.  ...uunet!wa3wbu!frackit!dave -or-                       |  Dave Ratcliffe  |
  274.  frackit!dave@uunet.UU.NET -or- dave@frackit.uucp -or-   |  Sys. <*> Admin. |
  275.  vogon1!compnect!frackit!dave@psuvax1.psu.edu            | Harrisburg,  Pa. |
  276.  
  277. -----------------------------
  278.  
  279. From: Luke Kendall <luke@research.canon.oz.au>
  280. Subject: Absurd! (Re: IS UNIX DEAD)
  281. Date: 17 Nov 92 22:48:31 GMT
  282. Sender: news@research.canon.oz.au
  283. To:       info-unix@sem.brl.mil
  284.  
  285. This `is Unix dead' is one of the most stupid subjects I have ever seen
  286. discussed.
  287.   1) Some people seem to be confusing operating systems with the
  288.      applications that run under the OS.
  289.   2) Unix is the only OS that will run on (effectively) every computer ever
  290.      manufactured.  Nothing else offers this - there _is no alternative_.
  291.      (Even ignoring the fact that the Mac and PC operating systems only
  292.      run on one hardware platform each, they still often have difficulty
  293.      operating with add-on hardware even though it is intended to be
  294.      used for them specifically!
  295. Prediction:
  296.   Now that Unix can be run on PCs, and the price barrier of all its
  297.   benefits has fallen, and we are seeing many more user-friendly
  298.   programs being developed for it, it will become the underlying
  299.   operating system of choice.
  300.  
  301. It has its drawbacks, but nothing like those of its `competitors'. Sure,
  302. Windows etc. will probably still be popular in 20 years time.  But what
  303. do you expect? Some people still program in Cobol, for heaven's sake!
  304. -- 
  305. Luke Kendall, Senior Software Engineer.      | Net:   luke@research.canon.oz.au
  306. Canon Information Systems Research Australia | Phone: +61 2 805 2911
  307. P.O. Box 313 North Ryde, NSW, Australia 2113 | Fax:   +61 2 805 2929
  308.  
  309. -----------------------------
  310.  
  311. From: David Breneman <dcb@kopachuk.uucp>
  312. Subject: Re: Need Phone line configuration
  313. Date: 17 Nov 92 23:55:38 GMT
  314. To:       info-unix@sem.brl.mil
  315.  
  316. In article <34034@adm.brl.mil> maschepe@thama1.apgea.army.mil (Michael A. Schepers) writes:
  317. >Hi,
  318. >
  319. >     Does anyone know what the standard phone line PIN configuration is?
  320. >     What I need to do is create a male RS-232 connector (25 pin) from a
  321. >     standard phone line (6 wires; Blue, Yel, Red, Grn, Blk, Wht).  I
  322. >     believe the phone line is a rj45, but I would not bet on it.
  323. >     Thanks for the help!!!
  324.  
  325. TIP is green, RING is red.  This is the wire pair in the middle of
  326. the modular plug.  Wire pairs start with the two wires in the middle
  327. of the plug and go out towards the edge, so on a 6-wire mudular
  328. plug, the pairs would be 3-4, 2-5 and 1-6.  On a standard residential
  329. installation, yellow is ground and black is transformer +.  The trans-
  330. former was used to light the dials of Trimline and Princess phones.
  331. Newer lighted-dial phones use a low-current LED which draws its
  332. power directly from the phone lines.  Blue and white depends on your
  333. application.  Is this the information you wanted?
  334.  
  335.  
  336. -- 
  337. David Breneman     Sys Admin, Tacoma Screw Products, Inc. |  ____  ____  ____
  338. dcb@tacoma.uucp           |   SCREWIE the TSP CLOWN sez-  |   /   /___  /___/ 
  339.  ..!uunet!tacoma!dcb      | "Zinc & cadmium plating stops |  /   ____/ / 
  340. CompuServe: 75760,1232    |  rust & acts as a lubricant!" |
  341.  
  342. -----------------------------
  343.  
  344. From: "frederick.d.true" <ft@cbnewsi.cb.att.com>
  345. Subject: Re: Unlocking named pipes (solved + question)
  346. Keywords: named pipe FIFO
  347. Date: 18 Nov 92 00:06:43 GMT
  348. Followup-To: comp.unix.questions
  349. To:       info-unix@sem.brl.mil
  350.  
  351.  
  352. Well, after receiving very few responses to my problem, I did a little 
  353. poking around in the SunOS kernel config files to try and find an
  354. answer.
  355.  
  356. Basically, my problem was this: I was using several named pipes to
  357. receive the output of several 'zcat file...' commands, and was then
  358. using 'sort <ops> -m pipe1 pipe2...' to merge the named pipes
  359. together. The result was that I could merge several large compressed
  360. sorted files, without having to decompress them to disk.
  361.  
  362. The problem was that after running for a while, the process would
  363. freeze and all processes would go into IW. I thought it was strange
  364. that this would happen all by itself, and indeed it didn't. At the
  365. same time, I was testing this process on several smaller files, using
  366. named pipes (different pipes, of course). 
  367.  
  368. I then noticed in the kernel configuration file, the option "options
  369. FIFOCNT=10' was being set. Sure enough, in the "Sun System and Network
  370. Administration" manual, I stumbled across the following, under "Tuning
  371. IPC System Parameters":
  372.  
  373.     FIFOCNT determines the makimum number of FIFOs that may be in
  374.     use in the system an any given time. Attempts to write more
  375.     than FIFOCNT simultaneous FIFOs will block until some FIFOs
  376.     are closed, releasing system resources. In the current 
  377.     implementation, FIFO buffers are allocated in non-paging
  378.     memory, and can lead to system lockup if indiscriminantly
  379.     allocated. This restriction make be removed in a future
  380.     release.
  381.  
  382. Well, that was the problem. The job would run fine as long as I was
  383. using <= 10 pipes. When I fiddled around while the job was running, I
  384. caused several of the pipes to block, and sort would stop, and all
  385. other processes would eventually stop since none of the pipes would
  386. clear until sort was done.
  387.  
  388. I've rebuilt the kernel with FIFOCNT=16 to help me out temporarily,
  389. but my question is this: is it really true that only this many named
  390. pipes can be used at once *in the entire system*? What if 2 users try
  391. to do this at the same time? Or 2 jobs for that matter?
  392.  
  393. It seems very unfriendly, for such a nice feature.
  394.  
  395. --
  396. Fred True
  397. AT&T
  398.  
  399. -----------------------------
  400.  
  401. From: Peter Busser <peter@global.hacktic.nl>
  402. Subject: Re: IS UNIX DEAD? (long)
  403. Date: 18 Nov 92 00:11:48 GMT
  404.  
  405. al.hacktic.n
  406. To:       info-unix@sem.brl.mil
  407.  
  408. rahardj@ccu.umanitoba.ca (Budi Rahardjo) writes:
  409.  
  410. >>  - how much is the difference between a DOS/Windows app and a comparable
  411. >>    UNIX app? (Ok, let the flames come in! :)))
  412. >I am not sure what you mean by that ?
  413.  
  414. Sorry that I was very unclear. I ment the price.
  415.  
  416. >>If I for instance don't like the
  417. >>Motif window manager and I switch to the OPEN LOOK window manager. That makes
  418. >>that makes several things look different on the screen. But everything the
  419. >>application displays remains exactly the same. 
  420.  
  421. >That's what window manager supposed to do. (Like the name says 
  422. >"window manager").
  423.  
  424. Yes and the name says exactly what it does: manage windows. It doesn't handle
  425. buttons, scroll bars, check boxes, pop-up menus, etc., etc. An OPEN LOOK app
  426. is still an OPEN LOOK app when run under Motif. After a few clicks, you have
  427. as many user interfaces as applications, except for the borders.
  428.  
  429. -----------------------------
  430.  
  431. From: Peter Busser <peter@global.hacktic.nl>
  432. Subject: Re: IS UNIX DEAD? (long)
  433. Date: 18 Nov 92 00:46:52 GMT
  434. To:       info-unix@sem.brl.mil
  435.  
  436. ppg@oasis.icl.co.uk (Philippe Goujard) writes:
  437.  
  438. >Anyway I don't think it is very fair to compare vi and winword. One is a 
  439. >text editor created to edit mostly C sources the other is a word processor 
  440. >with graphic capabilities.
  441.  
  442. I agree with that, compare it for instance with OS/2's E.EXE or Windows'
  443. NOTEPAD.EXE. They're very limited, but very easy to use.
  444.  
  445. >I havent come across many terminals with 12 function keys actually. I'm not 
  446. >sure you can count the keybord of the IBM AT (the XT had only 10 fkeys) 
  447. >since it is not really a terminal, it's a computer which can emulate 
  448. >(sometimes well and sometimes not so well) terminals.
  449.  
  450. Well, I've seen several terminals with a PC kind of keyboard (Philips and NCR).
  451. I wouldn't be surprised when they are in fact PC keyboards.
  452.  
  453. >First you must remember that the "F1=Help" convention was really introduced 
  454. >with IBM CUA standard (and therefore Windows and Presentation Manager. 
  455.  
  456. Ah, I didn't know that.
  457.  
  458. >Before that text applications implemented help the way they wanted (and some 
  459. >still do).
  460.  
  461. Yep.
  462.  
  463. >Under Unix, X-window itself is just the windows server but I'm 
  464. >don't know if the GUI (openlook & motif) implement it. (maybe motif, can 
  465. >someone confirm?).
  466.  
  467. Well, Open Look specifies a helpkey, it's a standard Open Look feature. Don't
  468. know about Motif though.
  469.  
  470. >Another problem to overcome is that many terminal emulators don't work too 
  471. >well : they treat certain keys locally. When you press F1 on some terminal 
  472. >emulators it doesnt send F1 to the remote machine and calls the local help 
  473. >menu.
  474.  
  475. That's not the case for the PC terminal emulators I know. Most use some kind of
  476. ALT combination.
  477.  
  478. >Wasn't vi written at first to test your terminal speaker?
  479.  
  480. Hahaha! Well, I've also seen 'flashy' but silent vi-s...
  481.  
  482. >Where did you get the idea that vi had a "wordprocessor mode"? (and wordwrap 
  483. >is not enough for me to be a wordprocessor mode!). It definitely hasn't. Vi 
  484. >is an editor for editing C sources.
  485.  
  486. You forgot the LISP mode! ;-)
  487.  
  488. >It does it very good (at least that's 
  489. >the opinion of people like me who have been using it for a long time) but it 
  490. >is definitely not an all purpose editor. And if you don't like it in the 
  491. >first place, don't use it.
  492.  
  493.  
  494.  
  495. >    - The real well known competitor is emacs which has the problems of
  496. >        - Being nearly as cryptic as vi
  497. >        - Being "copylefted" so you can't include it in commercial unixes
  498. >        (although Dell includes it I think).
  499.  
  500. <sigh> Copylefted means that you can't change the code without giving away
  501. the source. It doesn't mean that you can't *sell* the code (and/or derived
  502. binary). RTFC (Read The Fucking Copyleft) or RTFGM (Read The Fucking GNU
  503. Manifesto)!!! The copyleft explicitly permits commercial purposes. The only
  504. but is: don't change the sources without giving them away.
  505.  
  506. >>If the cursor keys are illogical that is a flaw.
  507. >I suppose you are mistaking 'logical' and 'intuitive'. For me the intuitive 
  508. >cursor keys on my terminal are those with the arrows on. And those don't 
  509. >work intuitively under vi.
  510.  
  511. Well, newer implementations of vi are happy with cursor keys. Elvis even has
  512. a menu (Wow! Look what I get when I press \ twice! :).
  513.  
  514. >On all the implementations of vi I've seen typing :
  515. >"a hello <CRSR UP> world" works where "i hello <CSRS UP> world" does not!
  516.  
  517. Well, this version of Elvis does both (and more)...
  518.  
  519. -----------------------------
  520.  
  521. From: Peter Busser <peter@global.hacktic.nl>
  522. Subject: Re: IS UNIX DEAD? (long)
  523. Date: 18 Nov 92 01:06:34 GMT
  524. To:       info-unix@sem.brl.mil
  525.  
  526. dansmith@Autodesk.COM (Daniel Smith) writes:
  527.  
  528. >Hey, I hope NT kicks the Unix vendors into a sudden spirit of mass
  529. >cooperation.
  530.  
  531. And I hope that the above happens before NT really hits the market!
  532.  
  533. >were so hard to use.  He was implying that there shouldn't be User Groups;
  534. >saying that "you don't see Washing Machine User Groups".
  535.  
  536. That's nonsense. But, IMHO, you shouldn't make computers harder to use than
  537. necessary.
  538.  
  539. >    Anyways, I'll get off my "stop expecting them to be toasters
  540. >anytime soon" soapbox.  I think Unix gets singled out quite a bit
  541. >on this one.  A lot of it comes from its sheer power and flexibilty.
  542. >It overwhelms the "learn barely enough to get by" mentality.
  543.  
  544. Good point. No system can satisfy the "learn barely enough to get by"
  545. mentality. But, it doesn't need to be harder than necessary.
  546.  
  547. -----------------------------
  548.  
  549. From: Apostolos Lytras <lytras@avalon.physik.unizh.ch>
  550. Subject: Re: IS UNIX DEAD? (long)
  551. Date: 18 Nov 92 13:34:33 GMT
  552. Sender: USENET News Admin <news@ifi.unizh.ch>
  553. Nntp-Posting-Host: avalon
  554. To:       info-unix@sem.brl.mil
  555.  
  556. In article <1992Nov18.001148.2448@global.hacktic.nl> peter@global.hacktic.nl (Peter Busser) writes:
  557. >rahardj@ccu.umanitoba.ca (Budi Rahardjo) writes:
  558. >>>  - how much is the difference between a DOS/Windows app and a comparable
  559. >>>    UNIX app? (Ok, let the flames come in! :)))
  560. >>I am not sure what you mean by that ?
  561. >Sorry that I was very unclear. I ment the price.
  562.  
  563. Well, let's see:
  564.  
  565. (let's take book editing software for an example)
  566.  
  567. FrameMaker:  about $3000 (if I convert the swiss price to US$, might be
  568.                           less in the US, however)
  569.  
  570. You get almost the same under UNIX from
  571.  
  572. Emacs & TeX:       $0 (maybe you'll have to add media cost)
  573.  
  574. Or take some table editing programs (spreadsheets), that offer macros:
  575.  
  576. Excel:  well.... $500?
  577. Perl:              $0
  578.  
  579. Maybe you start to understand now why I just *love* UNIX... it just
  580. compares favorably with DOS, and I don't give a **** about
  581. "user-friendly" interfaces which seem to be in the way all the time (to
  582. the experienced user, at least). 
  583.  
  584. Did you ever look at what the cost is for adding your DOS/Windows-PC to
  585. a network? What a bunch of different hard- and software you need to get
  586. this to work? Well... it was all built into my UNIX box, and it worked.
  587. This is what I call user-friendliness.
  588.  
  589. Cheers
  590. - A.
  591. -- 
  592.      lytras@ifi.unizh.ch           |   Apostolos Lytras
  593.      lytras@avalon.physik.unizh.ch    |   Informatik Club der Uni
  594.      lytras@amiga.physik.unizh.ch      |   Zuerich, SysAdmin
  595.  
  596. -----------------------------
  597.  
  598. From: Fergason <zklf0b@gs144.uucp>
  599. Subject: Re: IS UNIX DEAD? (long)
  600. Keywords: nn
  601. Date: 18 Nov 92 17:47:08 GMT
  602. Sender: news@hou.amoco.com
  603. To:       info-unix@sem.brl.mil
  604.  
  605.  
  606. In article <Bxw1Lp.CwH@undergrad.math.waterloo.edu> papresco@undergrad.math.waterloo.edu (Paul Prescod) writes:
  607. >>and will probably miss the end:
  608. >>
  609. >>I disagree.  Not having used too many OS's, I can only recall 2 
  610. >>that the help command did something.  Vax VMS, and Microsoft Dos 5.
  611. >>I take that back, i just thought of Wylbur/MVSX, and VM/CMS.  I believe
  612. >>help does something on those systems.  
  613. >
  614. >Add in OS/2 and (I believe) AmigaDOS.  Plus many, many, many, command 
  615. >line oriented programs that are not operating systems like symbolic
  616. >math packages and graphing packages.  Plus every text mode adventure
  617. >game.    
  618.  
  619. I believe the subject was operating systems.  There are lots of programs
  620. that help is a command.
  621.  
  622. >>
  623. >>Why should help do something at the command prompt?  I would much, much
  624. >>rather have the hardcopy manual in my hand.  While online help might
  625. >>be nice, I really just do not see its absence as an inherent flaw.
  626. >
  627. >You think the average university should issue everyone textual manuals?
  628. >Especially for the huge mass of files that come with Unix???
  629. >And what about when those files change?
  630.  
  631.  
  632. no, the university should not issue manuals.  I studied and worked at a 
  633. university for the past 10 years, so i feel I have a grasp on how that
  634. situation works.  the manuals were available, which is all I need.  I
  635. could get the manual for anything, because there was one copy at the
  636. help desks sprinkled around the campus.  If i buy software, i expect to
  637. get manuals. 
  638.  
  639. i consider manuals and online help to be two different things.
  640.  
  641. Kelly
  642.  
  643. -----------------------------
  644.  
  645. From: Budi Rahardjo <rahardj@ccu.umanitoba.ca>
  646. Subject: Re: IS UNIX DEAD? (long)
  647. Date: 18 Nov 92 19:58:29 GMT
  648.  
  649. al.hacktic.n
  650. Sender: news@ccu.umanitoba.ca
  651. Nntp-Posting-Host: antares.cc.umanitoba.ca
  652. To:       info-unix@sem.brl.mil
  653.  
  654. peter@global.hacktic.nl (Peter Busser) writes:
  655.  
  656. >rahardj@ccu.umanitoba.ca (Budi Rahardjo) writes:
  657.  
  658. >>>  - how much is the difference between a DOS/Windows app and a comparable
  659. >>>    UNIX app? (Ok, let the flames come in! :)))
  660. >>I am not sure what you mean by that ?
  661.  
  662. >Sorry that I was very unclear. I ment the price.
  663.  
  664. Yes, UNIX apps cost more, but that's because most of them are designed for
  665. multi users. If you buy a multi user version of DOS/Windows app it would
  666. cost the same. How much is Brief text editor (for example)?
  667. I've some programs that have competitive (same) price as UNIX apps.
  668.  
  669. >>>If I for instance don't like the
  670. >>>Motif window manager and I switch to the OPEN LOOK window manager. That makes
  671. >>>that makes several things look different on the screen. But everything the
  672. >>>application displays remains exactly the same. 
  673.  
  674. >>That's what window manager supposed to do. (Like the name says 
  675. >>"window manager").
  676.  
  677. >Yes and the name says exactly what it does: manage windows. It doesn't handle
  678. >buttons, scroll bars, check boxes, pop-up menus, etc., etc. An OPEN LOOK app
  679. >is still an OPEN LOOK app when run under Motif. After a few clicks, you have
  680. >as many user interfaces as applications, except for the borders.
  681.  
  682. That's not UNIX problem, it's the stupidity (cleverness) of app developers.
  683. FrameMaker on UNIX would have the same interface as the Windows version.
  684. If you run a DOS (or windows) application under Windows or OS/2, it would 
  685. still have the same user interface right ?
  686.  
  687. -- budi
  688.  
  689. -- 
  690. Budi Rahardjo <Budi_Rahardjo@UManitoba.Ca>
  691. Unix Support - Computer Services - University of Manitoba
  692.  
  693. -----------------------------
  694.  
  695. From: Budi Rahardjo <rahardj@ccu.umanitoba.ca>
  696. Subject: Re: IS UNIX DEAD? (long)
  697. Date: 18 Nov 92 20:03:48 GMT
  698. Sender: news@ccu.umanitoba.ca
  699. Nntp-Posting-Host: antares.cc.umanitoba.ca
  700. To:       info-unix@sem.brl.mil
  701.  
  702. peter@global.hacktic.nl (Peter Busser) writes:
  703.  
  704. >ppg@oasis.icl.co.uk (Philippe Goujard) writes:
  705.  
  706. >>Anyway I don't think it is very fair to compare vi and winword. One is a 
  707. >>text editor created to edit mostly C sources the other is a word processor 
  708. >>with graphic capabilities.
  709.  
  710. >I agree with that, compare it for instance with OS/2's E.EXE or Windows'
  711. >NOTEPAD.EXE. They're very limited, but very easy to use.
  712.  
  713. That's not fair either. Compare it with "textedit" (or crisp) under Openwindows.
  714.  
  715. >>Another problem to overcome is that many terminal emulators don't work too 
  716. >>well : they treat certain keys locally. When you press F1 on some terminal 
  717. >>emulators it doesnt send F1 to the remote machine and calls the local help 
  718. >>menu.
  719.  
  720. >That's not the case for the PC terminal emulators I know. Most use some kind of
  721. >ALT combination.
  722.  
  723. I thought F1 is supposed to be a standard HELP key for Dos/Windows programs :-)
  724.  
  725. -- budi
  726. -- 
  727. Budi Rahardjo <Budi_Rahardjo@UManitoba.Ca>
  728. Unix Support - Computer Services - University of Manitoba
  729.  
  730. -----------------------------
  731.  
  732. From: Budi Rahardjo <rahardj@ccu.umanitoba.ca>
  733. Subject: Re: IS UNIX DEAD? (long)
  734. Date: 18 Nov 92 20:06:10 GMT
  735. Sender: news@ccu.umanitoba.ca
  736. Nntp-Posting-Host: antares.cc.umanitoba.ca
  737. To:       info-unix@sem.brl.mil
  738.  
  739. lytras@avalon.physik.unizh.ch (Apostolos Lytras) writes:
  740.  
  741.  ...
  742. >Or take some table editing programs (spreadsheets), that offer macros:
  743.  
  744. >Excel:  well.... $500?
  745. >Perl:              $0
  746.  
  747. add
  748. sc (or xspread)    $0
  749.  
  750. -- budi
  751. -- 
  752. Budi Rahardjo <Budi_Rahardjo@UManitoba.Ca>
  753. Unix Support - Computer Services - University of Manitoba
  754.  
  755. -----------------------------
  756.  
  757. From: LineNoise <linnoise@bigboy>
  758. Subject: FTP'able Unix tutorials
  759. Date: 18 Nov 92 02:06:11 GMT
  760. Sender: "NetWork News (readnews" <news@cronkite.ocis.temple.edu>
  761. MMDF-Warning:  Parse error in original version of preceding line at BRL.MIL
  762. To:       info-unix@sem.brl.mil
  763.  
  764. I'm looking for Unix tutorial files that I can get through anonymous FTP.
  765. Any information or list of sites would be greatly appreciated.
  766.  
  767. ---Linenoise
  768.  
  769. -----------------------------
  770.  
  771. From: SW International <swispl@solomon.technet.sg>
  772. Subject: Question: How to get comd line arg of processes
  773. Date: 18 Nov 92 04:04:29 GMT
  774. Sender: news@lincoln.technet.sg
  775. Nntp-Posting-Host: solomon.technet.sg
  776. X-Newsreader: TIN [version 1.1 PL6]
  777. To:       info-unix@sem.brl.mil
  778.  
  779.  
  780.  
  781. I'm writing a C program which needs to obtain the command line
  782. arguments of other running processes. Actually, 'ps -af' does
  783. the job quite nicely, but due to other constraints, I need to
  784. incorporate that function within my program.
  785.  
  786. I've not done much system programming before. Please advise if
  787. you know how it can be achieved and the pitfalls I need to watch
  788. out.
  789.  
  790. Thanks.
  791. -- 
  792. cheewai                 ---------- __o   
  793. chlai@nyx.cs.du.edu        -------- _`\<,_ 
  794. swispl@solomon.technet.sg    ------- (*)/ (*)
  795.                 ~~~~~~~~~~~~~~~~
  796.  
  797. -----------------------------
  798.  
  799. From: "John F. Haugh II" <jfh@rpp386.lonestar.org>
  800. Subject: Re: Changing the owner of a process
  801. Date: 18 Nov 92 05:38:32 GMT
  802. To:       info-unix@sem.brl.mil
  803.  
  804. In article <1992Nov17.142837.21252@dale.ksc.nasa.gov> eposnak@dale.ksc.nasa.gov (Ed Posnak) writes:
  805.  
  806. [ This is actually one of the answers he quoted.  Mark Buda is the
  807.   writer ... ]
  808.  
  809. >The uid, in every version of Unix I've seen, is stored in the proc
  810. >structure in the kernel. You should be able to fiddle with this at
  811. >will in a device driver, and since it's in the proc structure and not
  812. >the u area, it'll always be there even if the process is swapped out.
  813. >It *should* be just a matter of searching for the entry and changing
  814. >it.
  815.  
  816. The UIDs are stored in the (struct user).  They are u.u_uid and u.u_ruid.
  817. Without giving away too much, that's where the system looks for things
  818. like access() and so on.  For a really bad time, check out the source
  819. to suser().  It will convince you of this fact.
  820.  
  821. >This technique should also serve to implement something like renice()
  822. >under Xenix, which doesn't have it. (The nice value also being stored
  823. >in the proc structure.)
  824.  
  825. Unfortunately, now that we know the data is in the (struct user),
  826. I won't be getting out my source to a XENIX renice ...  This also
  827. means that the device driver idea won't work since the other processes
  828. u-area may be anywheres.
  829. -- 
  830. John F. Haugh II                  [  TSAKC  ] !'s: ...!cs.utexas.edu!rpp386!jfh
  831. Ma Bell: (512) 251-2151           [ DoF #17 ]        @'s: jfh@rpp386.cactus.org
  832.  
  833. -----------------------------
  834.  
  835. From: Jerry Frain <frain@cis.ksu.edu>
  836. Subject: Re: IS UNIX DEAD? (very long)
  837. Date: 18 Nov 92 06:43:26 GMT
  838. NNTP-Posting-Host: depot.cis.ksu.edu
  839. To:       info-unix@sem.brl.mil
  840.  
  841. papresco@undergrad.math.waterloo.edu (Paul Prescod) writes:
  842.  
  843. > And for me, who can forget and type qw instead of wq, a prompt
  844. > "haven't saved yet" would be nice.  BTW, this is not asking for
  845. > superflurous time wasting prompting.  VI will NOT LET YOU QUIT with
  846. > a Q.  It must be wq or Q!.  So if I type Q, why not ask me if I
  847. > meant WQ?  Easier for the user, easeir for the power user that
  848. > forgets.
  849.  
  850. Friendliness and easiness to use varies from user to user.  So use the
  851. editor you find friendly, and let others use the editor they find
  852. friendly, and quit yer bitchin'.
  853.  
  854. BTW, I use GNU Emacs (on my UNIX box), which beats the snot out
  855. anything that runs on a DOS thing, as well as vi.
  856.  
  857. > That's fine...your keyboard doesn't have an F1 key and you don't
  858. > want help.  My keyboard DOES have an F1 key, and unix doesn't have a
  859. > standard F1 key.
  860.  
  861. Any program that might run on a variety of terminals and relies on the
  862. existence of function keys is inherently crippled.
  863.  
  864. F1 is not an intuitive label, I don't see the need for it AT ALL in
  865. the world of "user friendliness".  Certainly a key labelled "help"
  866. makes much more sense (though not in the context of UNIX).
  867.  
  868. > VI is decaying.
  869.  
  870. Bit-rot?
  871.  
  872. Jerry Frain
  873.  
  874. -----------------------------
  875.  
  876. From: Philip Craig <philip@research.canon.oz.au>
  877. Subject: I/O mapping from /bin/login
  878. Date: 18 Nov 92 07:50:46 GMT
  879. Sender: news@research.canon.oz.au
  880. To:       info-unix@sem.brl.mil
  881.  
  882. Hi. I'm trying to write a program which will call up a remote modem
  883. and let the user login (as a dial back security measure).
  884.  
  885. I have it almost working (thanks for source contributions guys), but now
  886. something *very weird* is happening.
  887.  
  888. The program runs very successfully, calling up my remote modem and
  889. displaying "login:" on the terminal. It then awaits input from the
  890. remote modem and upon getting <cr> prints "Password:" on the remote
  891. modem.
  892.  
  893. All is good up to this point, but now things go strangely. Somehow,
  894. /bin/login changes where it expects its input from at this point. It
  895. awaits input from the starting terminal of the dialout program. If it
  896. is given a bad password, the program will then print "login:" on the
  897. correct remote terminal again, and *again await input* from the correct,
  898. remote, location. This can be repeated for as many bad logins as /bin/login
  899. allows.
  900.  
  901. If a correct password is supplied (from the wrong terminal, of course) then
  902. the user's login shell is started, any .cshrc output appears in the correct,
  903. remote, location, then the shell freezes awaiting input from the starting
  904. terminal of the dial program. Not helpful.
  905.  
  906. The terminal is having /bin/login pointed at it by the following lines:
  907.  
  908.     /*
  909.      * Redirect /bin/login's stdin, stdout and stderr (no error
  910.      * checking here.)
  911.      */
  912.     dup2( fd, 0);
  913.     dup2( fd, 1 );
  914.     dup2( fd, 2 );
  915.     dup2( fd, 3 );
  916.     
  917.     /*
  918.      * Execute /bin/login with the serial line as its stdin, stdout
  919.      * and stderr.
  920.      */
  921.     execl("/usr/etc/getty", "usr/etc/getty", "D2400", "-", (char *) 0);
  922.  
  923. Any problem here. The descriptor in fd is the one that successfully
  924. read and wrote characters to the modem for the dialing command.
  925.  
  926. Please reply by e-mail--I can't keep up with the volume in here.
  927.  
  928. Thanks in advance,
  929. -- 
  930.    _/_/_/ _/  _/ _/ _/     _/ _/_/_/ _p_h_i_l_i_p_@_r_e_s_e_a_r_c_h_._c_a_n_o_n_._o_z_._a_u   _--_|\
  931.   _/  _/ _/  _/ _/ _/     _/ _/  _/  Phone: +61 2 805 2951        /      \
  932.  _/_/_/ _/_/_/ _/ _/     _/ _/_/_/   Fax:   +61 2 805 2929        \_.--._/
  933. _/     _/  _/ _/ _/_/_/ _/ _/     PO Box 313 North Ryde 2113 AUSTRALIA  v
  934.  
  935. -----------------------------
  936.  
  937. From: cvadrayb@vmsb.is.csupomona.edu
  938. Subject: FTP question.
  939. Date: 18 Nov 92 08:31:18 GMT
  940. Nntp-Posting-Host: acvax1
  941. Nntp-Posting-User: cvadrayb
  942. To:       info-unix@sem.brl.mil
  943.  
  944. Well, this is probably a stupid question, but I can't for the life of me
  945. figure out how to read (as in more or page) a remote file while using FTP.
  946.  
  947. Please, can someone spare me my suffering?!?
  948.  
  949. Kevin
  950. CVADRAYB@vmsb.is.csupomona.edu
  951. (Yeah, ok - So I use my VMS account as a mailbox - thats only because my
  952.  UNIX account it full..)
  953.  
  954. -----------------------------
  955.  
  956. From: Tom Parker <tparker@music.scd.ucar.edu>
  957. Subject: Re: FTP question.
  958. Date: 18 Nov 92 16:36:03 GMT
  959. Sender: USENET Maintenance <news@ncar.ucar.edu>
  960. To:       info-unix@sem.brl.mil
  961.  
  962. In article <1992Nov18.003118.1@vmsb.is.csupomona.edu> cvadrayb@vmsb.is.csupomona.edu writes:
  963. >Well, this is probably a stupid question, but I can't for the life of me
  964. >figure out how to read (as in more or page) a remote file while using FTP.
  965. >
  966. >Please, can someone spare me my suffering?!?
  967. >
  968. >Kevin
  969. >CVADRAYB@vmsb.is.csupomona.edu
  970. >(Yeah, ok - So I use my VMS account as a mailbox - thats only because my
  971. > UNIX account it full..)
  972.  
  973. It depends on your particular implementation of FTP, but this works for me:
  974.  
  975.       get remote.file "|more"
  976. --
  977. +--------------------------------------------------------------------+
  978. | Tom Parker             |  National Center for Atmospheric Research |
  979. | tparker@ncar.ucar.edu  |  (303) 497-1227                           |
  980. +--------------------------------------------------------------------+
  981.  
  982. -----------------------------
  983.  
  984. From: Lars Soltau <space@ncc1701.stgt.sub.org>
  985. Subject: Re: what does 8-bit clean mean ?
  986. Date: 18 Nov 92 09:30:01 GMT
  987. NNTP-Posting-Host: ncc1701.stgt.sub.org
  988. Content-Type: text/plain; charset=iso-8859-1
  989. Content-Transfer-Encoding: 8bit
  990. To:       info-unix@sem.brl.mil
  991.  
  992. >>>>> On 16 Nov 1992 14:53:08 -0500,
  993.  ren@function.mps.ohio-state.edu (Liming Ren) said:
  994.  
  995. > Somewhere I read that the C-compiler cc is not 8-bit clean. I am not sure
  996. > what It means?
  997.  
  998. It means that the C compiler can't handle 8bit identifiers, e.g.
  999. Nasenbdr (you might see the d on the left as v or \344, depending on
  1000. your configuration). Most C compilers can handle 8bit characters in
  1001. strings and comments, though.
  1002.  
  1003. > Also from the manpage of lex in UNIX, it says:
  1004.  
  1005. >      The lex command is  not  changed  to  support  8-bit  symbol
  1006. >      names,  as  this  would  produce lex source code that is not
  1007. >      portable between systems.
  1008.  
  1009. > Does this mean that lex can only be used for lexical analysis of text
  1010. > of ascii code 0-127? 
  1011.  
  1012. I don't know about lex, but flex has an option for exactly that, i.e.
  1013. producing an 8bit scanner. The comment above only refers to identifiers,
  1014. not the input text.
  1015. --
  1016. Lars Soltau    bang: <insert ridiculously long path>        BIX: -- no bucks --
  1017.         smart: space@ncc1701.stgt.sub.org
  1018.  
  1019. Will kein Gott auf Erden sein, sind wir selber Goetter.
  1020.  
  1021. -----------------------------
  1022.  
  1023. From: Karl Glazebrook <Karl.Glazebrook@durham.ac.uk>
  1024. Subject: Re: tcsh-like subroutine
  1025. Date: 18 Nov 92 09:45:28 GMT
  1026. Nntp-Posting-Host: dur.dust6
  1027. To:       info-unix@sem.brl.mil
  1028.  
  1029. Well apparently the answer is the GNU readlines package available from
  1030. any good ftp site, e.g. prep.ai.mit.edu.
  1031.  
  1032. I built it and it works a treat!
  1033.  
  1034. Many thanks to all those who replied.
  1035.  
  1036. Karl.
  1037. ---
  1038.  ------------------------------------------------------------------------------
  1039. | Karl Glazebrook,      | INTERNET:   Karl.Glazebrook@durham.ac.uk           |
  1040. | Dept. of Physics,     |    JANET:   KARL.GLAZEBROOK@UK.AC.DURHAM           |
  1041. | Univ. of Durham,      |     SPAN:   19463::DUVAD::KGB                      |
  1042. | United Kingdom.       |      FAX:   091-374-3749                           |
  1043.  ------------------------------------------------------------------------------
  1044.  
  1045. -----------------------------
  1046.  
  1047. From: KGGjerde <singg@alf.uib.no>
  1048. Subject: Milliseconds !!
  1049. Date: 18 Nov 92 13:09:06 GMT
  1050. Sender: Kurt George Gjerde <singg@alf.uib.no>
  1051. To:       info-unix@sem.brl.mil
  1052.  
  1053.  
  1054.    Programming question:
  1055.  
  1056.  
  1057.    Is there a way I can get "flowting" time in milliseconds?
  1058.  
  1059.    I've tried using clock and gettimeofday but they update in
  1060.    variable chunks.
  1061.  
  1062.    I'm writing an animation program and would like having the
  1063.    frames displayed in a steady rate.
  1064.  
  1065.  
  1066. K.
  1067.  
  1068. -----------------------------
  1069.  
  1070. From: Brian Montgomery <brianm@meaddata.com>
  1071. Subject: mapping extended keyboard in vi/ksh
  1072. Date: 18 Nov 92 14:33:05 GMT
  1073. Sender: Usenet Administrator <news@meaddata.com>
  1074. To:       info-unix@sem.brl.mil
  1075.  
  1076. hi netters,
  1077.        I need your expertise in vi to help figure out this problem.
  1078.  
  1079. I want to map the extended keyboard to some macros in vi.  
  1080.  
  1081. Like for example I want to map the 
  1082. pageup key to  
  1083. pagedown key to  
  1084. home   key to :1G
  1085. end    key to :G
  1086.  
  1087.  
  1088. Another problem is mapping of the arrow keys. 
  1089.  
  1090. I use the kornshell and I would like to map the arrow keys to 
  1091. up arrow to k
  1092. down arrow to j
  1093. right arrow to l
  1094. left arrow to h
  1095. home key to ^
  1096. end key to $
  1097.  
  1098.  
  1099.  
  1100. Any help will be greatly appreciated.
  1101. Emailing me your responses would be a good idea
  1102. as I don't frequent the net often. I will summarise and post , if
  1103. I get enough requests (> 10).
  1104.  
  1105. Thanks in advance 
  1106.  
  1107. -----------------------------
  1108.  
  1109. From: Bruce McCullough <rm72@prism.gatech.edu>
  1110. Subject: Re: UNIX Training
  1111. Date: 18 Nov 92 14:35:00 GMT
  1112. To:       info-unix@sem.brl.mil
  1113.  
  1114. >1) are there any companies which teach UNIX topics such as system
  1115. >   management, networking, etc? addresses? prices?
  1116.    Take a peek in Unix world and Unix Review. There are many companies
  1117.    that will send you demo disks and misc. Most of these are somewhat
  1118.    expensive.  
  1119.  
  1120. >2) what are the most popular magazines in the UNIX area?
  1121.     For me the two I mentioned above but I'm sure other netters will
  1122.     give you some more titles.
  1123.  
  1124. Although you did say mail me directly heres my response:
  1125. One reason I like to go ahead and post to the group instead of mailing
  1126. directly is that there is usually someone else with the same question
  1127. although it could also be done in several different ways this reaches
  1128. more people and saves a lot of mailing back and fourth.
  1129. -- 
  1130. Robert B. McCullough-Computer Operations Tech.
  1131. Registrar Data Systems
  1132. Georgia Institute of Technology
  1133. Internet: rm72@prism.gatech.edu
  1134.  
  1135. -----------------------------
  1136.  
  1137. From: Phillip Godwin <cmpsg03@nt.com>
  1138. Subject: text search software
  1139. Date: 18 Nov 92 14:40:12 GMT
  1140. Sender: Usenet News <news@brtph560.bnr.ca>
  1141. X-Xxdate: Wed, 18 Nov 92 09:42:25 GMT
  1142. X-Useragent: Nuntius v1.1.1d9
  1143. To:       info-unix@sem.brl.mil
  1144.  
  1145. I am working on an UNIX-based application (running on HP 400 and 700 
  1146. series workstations) that will among other things allow a user to 
  1147. search a large number of text files for a string.  We had planned
  1148. to parse grep output for the needed search result information, 
  1149. but grep is just too slow.
  1150.  
  1151. What we are looking for is a text search program (commercial or 
  1152. shared) that we can call from within our application.  Does anyone
  1153. out there have any experience with UNIX searching software?  I
  1154. would just like to get an idea of what is out there and then follow
  1155. up on any interesting leads.
  1156.  
  1157. If you can help, please email cmpsg03@nt.com.
  1158.  
  1159. Thanks...Phil
  1160.  -------------------------------------------------
  1161.    Phillip Godwin    ||   Northern Telecom    
  1162.    cmpsg03@nt.com    ||   Product Verification
  1163.    (919) 481-8887    ||   RTP, NC             
  1164.  -------------------------------------------------
  1165.  
  1166. -----------------------------
  1167.  
  1168. From: Murray Spiegel <spiegel@song.bellcore.com>
  1169. Subject: function calls for awkcc code
  1170. Date: 18 Nov 92 16:32:23 GMT
  1171. Sender: news@walter.bellcore.com
  1172. Nntp-Posting-Host: song.bellcore.com
  1173. To:       info-unix@sem.brl.mil
  1174.  
  1175. We have developed an application using (n)awk, and convert to C
  1176. using awkcc when we want to run the program (for purposes of speed up).
  1177.  
  1178. The program takes input from stdin and writes to stdout.
  1179. (When stuff is read into an awk program some other variables
  1180. like $0, NF, etc, are also set.)
  1181.  
  1182. We want to change the input/output mechanism of our program,
  1183. specifically the awkcc generated version, as that is what 
  1184. we will be using in the final product.
  1185.  
  1186. We want our program to be implemented as a _function call_.
  1187.  
  1188. That is, instead of reading stuff from stdin, our C program 
  1189. is passed a parameter which would be the input string, and returns
  1190. an output string (instead of writing to stdio). As our program takes 
  1191. a long time to initialize (it has a very large BEGIN structure), 
  1192. we do not want to do the initialization for every input.
  1193.  
  1194. The awkcc generated code is very obscure, and it seems a non-trivial
  1195. task to implement our awkcc generated program as a function call. 
  1196. We did locate the function which opens the input as a stream of type FILE *. 
  1197. However, it seems trying to change that would in turn entail changing/rewriting 
  1198. a whole bunch of code. We are looking for help to solve this problem.
  1199.  
  1200. One way to get around this problem is to have a parent process which
  1201. connects via pipes in both directions to a child process (our program)
  1202. which is started up once.  We then communicated with the parent C
  1203. program.   But in our case, we DO NOT want to have about 48 different
  1204. child processes running for 48 the different sources which can access
  1205. our program on one machine.
  1206.  
  1207. That's why we are looking into implementing our program as a function call.
  1208.  
  1209. Anyone who can offer some help, please send me email.  Thank you!
  1210.  
  1211. spiegel@bellcore.com
  1212.  
  1213. -----------------------------
  1214.  
  1215. From: Jan Roger Wilkens <jawil@hpx13.aid.no>
  1216. Subject: SIGS in SoftMail
  1217. Date: 18 Nov 92 16:54:29 GMT
  1218. Sender: Mr News <news@ulrik.uio.no>
  1219. Nntp-Posting-Host: hpx13.aid.no
  1220. To:       info-unix@sem.brl.mil
  1221.  
  1222. I've just started to use SoftMail (part of HP's SoftBench package), the package
  1223. looks great, but I can't figure out how to make it automaticall include sigs
  1224. in my mail messages. I can't find anything about in the manual either...
  1225. Can anybody help?
  1226.  
  1227. -- 
  1228.                                Jan Roger Wilkens
  1229.                      Student at Agder Engeeniering School
  1230.                                Computer Technics
  1231.  
  1232.                            EMail: jawil@hpx11.aid.no
  1233.  
  1234. -----------------------------
  1235.  
  1236. From: Eric Luyten <eluyten@rc1.vub.ac.be>
  1237. Subject: Re: Suppressing the 'w' command
  1238. Date: 18 Nov 92 17:26:34 GMT
  1239. Sender: news@rc1.vub.ac.be
  1240. To:       info-unix@sem.brl.mil
  1241.  
  1242. In article <17488@pitt.UUCP>, fahad@cs.pitt.edu (Fahad A Hoymany) writes:
  1243. |> Could someone tell me how to stop other people from checking up on me
  1244. |> with the 'w' command?
  1245.  
  1246. rm /usr/ucb/w
  1247.  
  1248. (And the villains will start using 'ps'...)
  1249.  
  1250. To cut it short : there's no hiding.
  1251.  
  1252.  
  1253. Eric Luyten, BFUCC.
  1254.  
  1255. -----------------------------
  1256.  
  1257. From: Tim Casey <13501TMC@msu>
  1258. Subject: Internet question
  1259. Date: 18 Nov 92 18:58:49 GMT
  1260. Sender: news@msuinfo.cl.msu.edu
  1261. To:       info-unix@sem.brl.mil
  1262.  
  1263.  
  1264.      Does anyone know the cost associated with getting Internet access from
  1265. home (i.e. a direct hookup compared to sharing time on a server)?
  1266.  ------------------------------------------------------------------------------
  1267. Please respond to:
  1268. caseytim@student.msu.edu
  1269.  
  1270. -----------------------------
  1271.  
  1272. From: FEK print <fekoprt@uts.uni-c.dk>
  1273. Subject: Can telnetd preserve environment ? Can I get one that does ?
  1274. Keywords: telnetd, environ
  1275. Date: 18 Nov 92 19:18:31 GMT
  1276. To:       info-unix@sem.brl.mil
  1277.  
  1278. Preamble: The system is SCO unix 3.2.2.
  1279.  
  1280. Can anyone tell me, if I can get telnetd to preserve it's start-up env.
  1281. var.s?  What I'm trying to do is this: /etc/wrapper is small program, that
  1282. will read the peer-address of its input-socket, set an env.var. (say IP) to
  1283. that adress, and then exec its arguments.  Thus when I put:
  1284.  
  1285. telnet stream tcp    nowait  NOLUID /etc/wrapper telnetd
  1286.  
  1287. in inetd.conf, it ought to make the IP available to telnetd and all of its
  1288. children (login, sh).
  1289.  
  1290. But no.  No matter what I try, my IP gets lost somewhere.  I have som kind 
  1291. of hint, that login will destroy most of its env. unless started with a -p
  1292. option, but how can I do that (since telnetd starts login, the way *it* damn
  1293. pleases)?
  1294.  
  1295. Maybe im doing this the wrong way; Can I get the sources for a telnet that
  1296. will report it's IP-adresse. and perhaps make it available for the subsequent
  1297. processes?
  1298.  
  1299. ((Gripe: I don't really understand why telnetd doesn't care *anything* for
  1300. it's peer adress, but takes great pain to report terminal device id.  IMHO
  1301. the latter thing is very maginally useful, but the peer address is handy
  1302. for determining login terminal characteristics a.s.o.  I'm aware, that 
  1303. terminals were once hardwired, but *dammit* that's ages ago.) Sorry about that)
  1304.  
  1305.  
  1306. -----------------------------
  1307.  
  1308. From: Barry Margolin <barmar@think.com>
  1309. Subject: Re: Can telnetd preserve environment ? Can I get one that does ?
  1310. Keywords: telnetd, environ
  1311. Date: 18 Nov 92 22:48:53 GMT
  1312. NNTP-Posting-Host: telecaster.think.com
  1313. To:       info-unix@sem.brl.mil
  1314.  
  1315. In article <1992Nov18.191831.12729@uts.uni-c.dk> fekoprt@uts.uni-c.dk (FEK print) writes:
  1316. >Maybe im doing this the wrong way; Can I get the sources for a telnet that
  1317. >will report it's IP-adresse. and perhaps make it available for the subsequent
  1318. >processes?
  1319.  
  1320. You can get telnetd from ftp.uu.net and any other archive servers that
  1321. contain the free BSD sources.
  1322. -- 
  1323. Barry Margolin
  1324. System Manager, Thinking Machines Corp.
  1325.  
  1326. barmar@think.com          {uunet,harvard}!think!barmar
  1327.  
  1328. -----------------------------
  1329.  
  1330. From: abraham <AASSI@cunyvm.bitnet>
  1331. Subject: Re: Passing args to login(1)
  1332. Date: 18 Nov 92 19:33:04 GMT
  1333. To:       info-unix@sem.brl.mil
  1334.  
  1335. > From: pynq@quads.uchicago.edu (George Jetson)
  1336. > Subject: Passing args to login(1)
  1337. > Date: Wed, 18 Nov 1992 14:58:21 GMT
  1338. >
  1339. > I am pretty sure that under at least some versions of Unix/login, you can
  1340. > pass args in along with your login-id, and that these args would then be
  1341. > available to your .login/.profile.  See below:
  1342. >
  1343. >         login: pynq and green
  1344. >         Password:
  1345. >
  1346. >         Then $1 should be "and" and $2 should be "green".
  1347. >
  1348. > However, this doesn't seem to work under my current version of login
  1349. > (and version of SunOS [4.something])
  1350. >
  1351. > So, my question is: "Am I imagining things, or am I doing it wrong?"
  1352. >
  1353. > I could of course ask questions in the login script and branch
  1354. > accordingly, but it would be cleaner to be able to do it as a command
  1355. > line parameter.
  1356.  
  1357.     if you only want my opinion, then you are "doing it wrong",
  1358. but if you want information you can use then here it goes: You can pass
  1359.  
  1360. environment variables to your process but NOT parmeters
  1361. Under UNIX SVR3.2 (not familiar with prev. rel) login is defined as:
  1362.  
  1363. login [name [env-var ...]]
  1364.  
  1365. login: root    TERM=vt100 NAME="unix guru" OPTIONS="NOMENU,EXPERT"
  1366. password:
  1367.  
  1368. after login is successful, try this:
  1369. echo $TERM $NAME $OPTIONS
  1370. they should be set to the values you assigned to them at login.  These
  1371. variables are governed by the same rules as ordinary environemnt vars
  1372. so you may NOT use 1=first_parm 2=second_parm and then use $1 & $2
  1373. login is smart and will log you out if you use an invalid identifier.
  1374.  
  1375.  
  1376. good luck
  1377.  
  1378. -----------------------------
  1379.  
  1380. From: Paul Prescod <papresco@laplace.uwaterloo.ca>
  1381. Subject: Re: IS UNIX DEAD (long)
  1382. Date: 18 Nov 92 19:44:11 GMT
  1383. Sender: news@undergrad.math.waterloo.edu
  1384. To:       info-unix@sem.brl.mil
  1385.  
  1386. >Define "user friendly". Aren't the people who like vi users too?
  1387.  
  1388. They are users.  And important users.  And they shouldn't be neglected.  I'm
  1389. sure vi is small enough that it can be included with every version of unix
  1390. until time ends, just like dos' EDLIN.  But there should be an alternative,
  1391. and not emacs.  An easy to use, friendly alternative.  That alternative should
  1392. come on every unix system.  It should be powerful and configurable.  
  1393.  
  1394. Let's face it: unix users are users too.  But they are a miniscule subset of 
  1395. the number of people who COULD be using unix.  Not only instead of DOS and
  1396. Windows, but instead of not using computers at all.  A powerful, compatible,
  1397. scalable, layered unix could make more people less afraid of computers then
  1398. the plethora of incompatibilities we have now.
  1399.  
  1400. -----------------------------
  1401.  
  1402. From: Rob Freyder <rob@hp11>
  1403. Subject: Re: Searching for E-mail package
  1404. Date: 18 Nov 92 20:14:58 GMT
  1405. Sender: news@airgun.wg.waii.com
  1406. Followup-To: comp.sys.sun.admin
  1407. Nntp-Posting-Host: hp11.aws.waii.com
  1408. To:       info-unix@sem.brl.mil
  1409.  
  1410. In <tkevans.722019653@eplrx7.es.dupont.com> tkevans@eplrx7.es.duPont.com (Tim Evans) writes:
  1411.  
  1412. >karl@BofA.com (Karl Nicholas) writes:
  1413.  
  1414. >>In article <BxMtso.Ipz@beach.csulb.edu> kumeda@beach.csulb.edu (ANDY KUMEDA) writes:
  1415. >>>
  1416. >>>We are currently searching for E-mail/Office Automation packages that will
  1417. >>>serve several thousand users based on the following criteria:
  1418. >>>
  1419. >>>  1) Must support X-Window (OpenLook or Motif) either through an X-terminal
  1420. >>>     or a PC running an X-server.
  1421.  
  1422. Check out Z-mail
  1423.  
  1424. >>>  2) Must also support PCs running DOS, with a TCP/IP network connection.
  1425.  
  1426. You  might  want to further clarify this requirement. I assume Windows 3.x
  1427. is not in use so you are probably talking about a character based version.
  1428.  
  1429.  
  1430. >>>  3) In addition, a non-X version (character-based -- ASCII terminals) is 
  1431. >>>     preferable, but not required.
  1432.  
  1433. I believe Z-mail has this or is working on it.
  1434.  
  1435. >>>  4) Must be able to 'customize' -- ie original text to be replied or
  1436. >>>     forwarded should not be modifiable.
  1437.  
  1438. This  could  be  difficult  ...  When  I reply I usually do just what I am
  1439. doing  here.  I  embed  my  replies  in  the  original text and frequently
  1440. delete the unnecessary parts.
  1441.  
  1442. >>>  5) Must support SMTP.
  1443.  
  1444. Not a problem.
  1445.  
  1446. >>>  6) Vendor must have good technical support.  
  1447.                          ^^^^
  1448.                                  Hmmmm.   8-)
  1449.  
  1450.                                  
  1451.  
  1452. --
  1453. Rob Freyder                             Atlas Wireline a division of
  1454. ____    ____     ____                   Western Atlas International Inc.
  1455. \   \  /   /\   /   /\                  A Litton / Dresser Company
  1456.  \   \/   /  \ /   /  \                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1457.   \  /   / \  /   /\   \                Internet  :  rob@marley.aws.waii.com
  1458.    \/___/   \/___/  \___\               Voice     :  (713) 972-6678
  1459.  
  1460. -----------------------------
  1461.  
  1462. From: Ioi Kim Lam <ioi@pixmap.seas.upenn.edu>
  1463. Subject: RE: IS UNIX DEAD
  1464. Date: 18 Nov 92 20:17:02 GMT
  1465. Sender: news@NOC2.DCCS.UPENN.EDU
  1466. Nntp-Posting-Host: pixmap.seas.upenn.edu
  1467. To:       info-unix@sem.brl.mil
  1468.  
  1469. In-Reply-To: <9211161252.AA06509@acadia.Kodak.COM>; from "Brian K. Talley" at Nov 16, 92 7:52 am
  1470.  
  1471. Brian K. Talley
  1472. > >> Total B.S.!!    I'd love to have a user friendly application and VI
  1473. > >>is it for me. It grips me to hear DOS users say "VI it's to hard to
  1474. > >>learn". Come on thats why UNIX has got power, DOS doesn't......
  1475. > >
  1476. > >If you think that being hard to use means power, go and write a book about
  1477. > >it. I am sure that would be a best seller. 
  1478. > I believe what Mr. McCullough was saying, although it was poorly worded, is
  1479. > that many Unix applications require a little more effort on the part of the
  1480. > user to learn all the features an application has to offer, as opposed to
  1481. > DOS, which has little to offer in comparison (apples VS. oranges).
  1482.  
  1483.     I see your point. I agree that currently many powerful
  1484. applications are hard to use, but that is due to their poor design. I hope
  1485. you would understand that a lot of "powerful applications" you have
  1486. mentioned (in your previous postings) were made more than a decade ago.
  1487. The user interface technology has developed so much since the beginning of
  1488. the 80's and a lot of the features in the older applications can be and
  1489. have been incorporate into the new GUI. 
  1490.  
  1491.     Of course, I agree that the current GUI technology has its
  1492. downsides. It is still in its infancy. I think what we should do is trying
  1493. to improve it, not clinging to the old methods. 
  1494.  
  1495.     I believe what the programmer should do is to deliver the power of
  1496. the computer to every user, regardless to their knowledge in computing.
  1497. How good is a powerful application that no one can use?
  1498.  
  1499.     Let us look at the impossibility. Our ancestors have conquered
  1500. many impossibilities. They may laugh at us if we now say "it is just
  1501. *impossible* to make a powerful application easy to learn and easy to use".
  1502. I would always acknowledge the difficulty, but not the impossibility.
  1503.  
  1504.     If a user finds an application too difficult to use, that is not
  1505. his fault. That is the designer's fault. And believe me, we can correct
  1506. it.
  1507.  
  1508. Sincerely,
  1509.  
  1510.     Ioi.
  1511.  
  1512. ========================================      ^^^^^^^^^^^^^^^^^^^^^
  1513. IOI LAM ( footnote : the Binary Man )  |      |  ( . )    ( . )   |  
  1514.  ---------------------------------------|     [  #       V          ]
  1515. Box 0157, 3820 Locust Walk             |      |      [+++++]      |
  1516. Philadelphia, PA 19103-6134            |      |___________________|
  1517.  ---------------------------------------|       _|_______________|__
  1518. ioi@eniac.seas.upenn.edu               |  =>--|        101         |--<=
  1519. _______________________________________|      |____________________|
  1520.                                                _|_             _|_ 
  1521.  
  1522. -----------------------------
  1523.  
  1524. From: Boyd Hays <bhays@teal.csn.org>
  1525. Subject: Any terminfo compilers available?
  1526. Date: 18 Nov 92 20:27:30 GMT
  1527. Sender: news <news@csn.org>
  1528. Nntp-Posting-Host: teal.csn.org
  1529. To:       info-unix@sem.brl.mil
  1530.  
  1531. Hello,
  1532.     I need to write a program that parses terminfo source files. There was
  1533.     something available about 5 years ago, a small lex scanner, but I can't
  1534.     find it anywhere.
  1535.  
  1536.     Does anyone know where I might find the source for such a beast?
  1537.  
  1538. Thanks in advance,
  1539.  
  1540. Boyd Hays
  1541. bhays@csn.org
  1542.  
  1543. -----------------------------
  1544.  
  1545. From: Barry Brown <zz1bb@impending.ucsd.edu>
  1546. Subject: Re: C Source Code for Pattern Matching
  1547. Keywords: text pattern matching source
  1548. Date: 18 Nov 92 22:21:01 GMT
  1549. Sender: news@sdcc12.ucsd.edu
  1550. Nntp-Posting-Host: impending.ucsd.edu
  1551. To:       info-unix@sem.brl.mil
  1552.  
  1553. In <1992Nov17.221125.24947@dcc.uchile.cl> erodrigu@dcc.uchile.cl (Eduardo Rodriguez) writes:
  1554.  
  1555.  
  1556. >In article <leb.721935245@edgar>, leb@edgar.Jpl.Nasa.Gov (Larry Bright) writes:
  1557. >> Could anyone tell me where I could find C source code for some
  1558. >> simple text pattern matching s/w, preferably with a syntax and
  1559. >> semantics based on "regular expressions" as in grep, awk, sed, etc.
  1560. >> Anything that implements a non-trivial subset of these functions
  1561. >> would be useful.
  1562.  
  1563. >The agrep package (approximate pattern matching) has many of the grep functions
  1564. >and other stuff besides.  You can pick it up from cs.arizona.edu using
  1565. >anonymous ftp.
  1566.  
  1567. Doing "man regexp" on my Sun turned up a C library for regular expression
  1568. matching.  The routines you need may be right under your nose!
  1569.  
  1570. -- 
  1571. Barry E. Brown        --        \  UCSD Instructional Computing Center
  1572. bebrown@ucsd.{edu,uucp,bitnet}   \   Anime Stuff FTP Server administrator
  1573. Somewhere in San Diego, CA.....   \    (ftp network.ucsd.edu [132.239.254.203])
  1574. "Stimpy, sometimes your wealth of ignorance astounds me." -- Ren
  1575.  
  1576. -----------------------------
  1577.  
  1578. From: Ioi Kim Lam <ioi@pixmap.seas.upenn.edu>
  1579. Subject: WHAT IS UNIX? (was IS UNIX DEAD?)
  1580. Date: 18 Nov 92 22:22:58 GMT
  1581. Sender: news@NOC2.DCCS.UPENN.EDU
  1582. Nntp-Posting-Host: pixmap.seas.upenn.edu
  1583. To:       info-unix@sem.brl.mil
  1584.  
  1585.  
  1586. Lots of discussions have been going on about the topic whether Unix is
  1587. dead. From my (biased) observation, many people have been missing the
  1588. point. Before you posting more irrelevant materials, can you guys think
  1589. twice - " What is Unix? What am I defending / attacking? ".
  1590.  
  1591. I don't know  what Unix is, but I can give a list what Unix is not.
  1592.  
  1593.  
  1594. Unix is not VI, EMACS or C-SHELL
  1595. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  1596.     These stuffs are only the *applications* of Unix. They distinguish
  1597. Unix (somewhat notoriously) from other OS's. Yet they were designed and
  1598. implemented before my grandad was born. They do have their merits. I just
  1599. don't think by arguing about their merits can help the future of Unix.
  1600. What really makes Unix special is its capability in multi-tasking,
  1601. security, portability, distributed processing .... and the list goes on
  1602. and on. But please, exclude VI. 
  1603.     (To please the VI fans - VI is something about personal taste, and
  1604. I suppose all of you love French wine, too. Please post your support of VI
  1605. to soc.culture.????. I would love to read them) 
  1606.  
  1607.  
  1608. Unix is not a toy for the computer scientists
  1609. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  1610.     The reason of the development of computing originated from
  1611. outsides of the field. Now that we have such a splendid OS like Unix, why
  1612. should we restricted its use to the universities and the computer
  1613. literates? Why shouldn't a casual user be able to use it? In a few years
  1614. everyone will be running a 1000 MIPS PC in their home. They need the power
  1615. of Unix. And God (aka Computer Scientists), let these poor soles have it. 
  1616.  
  1617.  
  1618. Unix does not have to appear as a complicated system
  1619. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  1620.     Yes, Unix *is* a complicated system, but it doesn't have to appear
  1621. so. Not every user has to handle this complexity. One system needs only
  1622. ONE sysadmin. As long as I can get my Ferarri fixed by someone, I am
  1623. absolutely eligible of owning and driving it. 
  1624.  
  1625.  
  1626. Unix is not a static object
  1627. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  1628.     Why can't Unix evolve? By stressing how wonderful Unix is now can
  1629. only limit one's vision about the future of computing. OK, I repeat, Unix
  1630. is wonderful, but it still has some problems. Find them out and fix them.
  1631. Most of the supporters of the old features of Unix are, surprisingly, very
  1632. young computer scientists. It is interesting to see many young men/women
  1633. in a young industry talk like their grandparents. Where have they lost
  1634. their vision and creativity?
  1635.  
  1636.  
  1637. Unix is not immortal
  1638. ^^^^^^^^^^^^^^^^^^^^
  1639.     Now there comes the tough part. Unix is not dead, I assure you,
  1640. but it will be. Man is not immortal, nor is his creations. No matter how
  1641. brilliantly designed and how adaptive Unix was, its foundations will
  1642. become its limitations. In a rapidly changing world new products will come
  1643. out and replace the existing ones. The replacement of Unix is a sign of
  1644. progression. I love my old friend Unix but I would be very happy to see it
  1645. die. They day that Unix finally steps down will be an milestone in the
  1646. history of the computer, just as was the day when Unix was born. 
  1647.  
  1648.                        ioi the binary man
  1649.  
  1650. -----------------------------
  1651.  
  1652. From: t9014199@phillip.edu.au
  1653. Subject: Capturing tty output?
  1654. Date: 18 Nov 92 22:32:49 GMT
  1655. To:       info-unix@sem.brl.mil
  1656.  
  1657. Hi there all,
  1658.  
  1659.     I have question about snooping other users. :)
  1660.  
  1661.     Is it possible to capture the output of someones tty screen?
  1662.     
  1663.     ie... a sample list of users from 'w' commmand..
  1664.  
  1665.     brian    ttyp9     4:38pm    50                -csh 
  1666.     brian    ttypa     4:38pm     3                more -s /tmp/man17683 
  1667.     
  1668.     Is it possible to capture to a file the output of the ttypa scrren.
  1669.     Without brian knowing. :)
  1670.  
  1671.     I have Unix on my amiga at home (don't laugh) and wonder if it is
  1672.     possible.
  1673.  
  1674.     Please reply via email...
  1675.  
  1676.     Thanks Darren
  1677.  
  1678. PS Please don't flame me.
  1679.  
  1680. -- 
  1681. --
  1682. Darren Spencer          Comp Sci Student         RMIT Bundoora (RIP PIT)
  1683. ============================================================================
  1684. Email:        dazza@arcadia.mc.phillip.edu.au        t9014199@phillip.edu.au
  1685.  
  1686. -----------------------------
  1687.  
  1688. From: Jason M Ferguson <ferguson@wizard.etsu.edu>
  1689. Subject: Shell Programming for Beginners
  1690. Date: 18 Nov 92 22:38:55 GMT
  1691. Sender: usenet@ra.oc.com
  1692. To:       info-unix@sem.brl.mil
  1693.  
  1694.  
  1695.     Thanks to all the people who helped me with the c language
  1696. problem, with the help I received I got the thing up and running
  1697. pronto.
  1698.     My question this time is this:
  1699.         Is there a source on the net for learning to
  1700.     program a UNIX shell? I'm trying to create a menuing
  1701.     shell, simple enough, but need some sort of reference.
  1702.  
  1703.     'Preciate the help people. Hasta La Vista.
  1704.  
  1705. [------------------------------------------------------------------------]
  1706. [ Jason Ferguson                   |  "No more Mister Nice Guy..."       ]
  1707. [ ferguson@wizard.etsu.edu         |                                     ]
  1708. [------------------------------------------------------------------------]
  1709.  
  1710. -----------------------------
  1711.  
  1712. From: Michael O'Henly <lux@sol.uvic.ca>
  1713. Subject: It ain't a 24x80 world anymore. Or is it?
  1714. Date: 18 Nov 92 23:29:17 GMT
  1715. Sender: news@sol.uvic.ca
  1716. Nntp-Posting-Host: sol.uvic.ca
  1717. To:       info-unix@sem.brl.mil
  1718.  
  1719.  
  1720.     A few days ago I posted a query about how to increase the number
  1721. of rows displayed in a terminal window so that 'full-screen' commands
  1722. like emacs could make use 35 lines instead of the usual 24.
  1723.  
  1724.     I got some responses that suggested "stty rows 35" or "setenv
  1725. LINES 35". I've tried both and, while they do alter the terminal's
  1726. behaviour, they don't give me a 35-line screen. What I'm getting looks
  1727. like this: lines 1-24 after a screen-clear display correctly, but
  1728. lines 25-35 pile up on top of each other on the 24th line.
  1729.  
  1730.     So maybe I didn't ask the right question. What I'm trying to do is
  1731. make the best use of my laptop screen when I dial into my machine
  1732. using a modem and terminal emulator. Does the fact that I'm dialing in
  1733. make a difference? I'm sure there _must_ be a way of working with more
  1734. than a 24x80 display under these circumstances.
  1735.  
  1736.     Any and all suggestions would be appreciated!
  1737.  
  1738.     Michael
  1739.  
  1740.  
  1741. -- 
  1742.            Michael O'Henly |     o   | 604-721-7623 (604-721-8215 fax)
  1743.     Library Systems Office |  --/--  | LUX@UVVM.BITNET
  1744.     University of Victoria |  __\    | lux@sol.UVic.CA
  1745.     Victoria, B.C., Canada |     \   | mohenly@malahat.Library.UVic.CA
  1746.  
  1747. -----------------------------
  1748.  
  1749. From: Vladimir Stavitsky <vlad@dkbfpny.com>
  1750. Subject: cnews help
  1751. Date: 18 Nov 92 23:30:20 GMT
  1752. To:       info-unix@sem.brl.mil
  1753.  
  1754. Hi, netters.
  1755. This question has to do with cnews software, so may be
  1756. it is more appropriate to post it to some other newsgroup,
  1757. but i am not sure which one, so here it is:
  1758.  
  1759. i have just installed cnews on the server which is our mailhost -
  1760. and everything works fine. Unfortunately, i had to reinstall it
  1761. on some other machine; it works ok so far - i was able to post
  1762. articles to the test group; i used rsh to execute uux on the
  1763. mailhost (changed sys file under /usr/lib/news);
  1764.  
  1765. my problem is: what happens when uunet sends batches to my mailhost?
  1766. as far as i understand, rnews still must be available there, right?
  1767. another words, i can not clean up my mailhost in terms of cnews
  1768. software, can i?
  1769.  
  1770. Thanks in advance for any suggestions.
  1771. Vlad
  1772.  
  1773. -----------------------------
  1774.  
  1775. From: Ade Barkah <mbarkah@slate.mines.colorado.edu>
  1776. Subject: How does a mortal become a UNIX WIZARD ?
  1777. Date: 19 Nov 92 00:15:12 GMT
  1778. Sender: Ade Barkah <mbarkah@slate.mines.colorado.edu>
  1779. To:       info-unix@sem.brl.mil
  1780.  
  1781.  
  1782. What does it take for a man, er, person, to become a Unix Wizard ?
  1783.  
  1784. Which bibles should we study ? (after memorizing O'Rileys to become
  1785.   an X Wizzie ?)
  1786.  
  1787. How many kernels (and which ones) we need to take apart and reassemble ?
  1788.  
  1789. Some doth say that the only way thou shall gain salvation is to
  1790. partake in the (sacrireligios) ceremony of rewriting Unix from
  1791. scratch.
  1792.  
  1793. So, oh, mylord, how does a mortal become a Unix Wizard ?
  1794.  
  1795.  
  1796. (next question: how does a newbie become a net.personality ?)
  1797.  
  1798. (ade barkah)
  1799. -- 
  1800. Internet  : mbarkah@slate.mines.colorado.edu    (NeXT Mailable)
  1801. CompuServe: 74160,3404
  1802.  
  1803. -----------------------------
  1804.  
  1805. From: "Niemeyer (Pat" <pat@bcserv.wustl.edu>
  1806. MMDF-Warning:  Parse error in original version of preceding line at BRL.MIL
  1807. Subject: What's wrong with select() ?
  1808. Date: 19 Nov 92 21:55:44 GMT
  1809. NNTP-Posting-Host: bcserv.wustl.edu
  1810. To:       info-unix@sem.brl.mil
  1811.  
  1812.  
  1813. I'm totally confused.
  1814.  
  1815. I find that I cannot get the select() system call to 
  1816. correctly identify when there are characters waiting
  1817. on a file descriptor that I have opened with 'open()'.
  1818.  
  1819. It *does* seem to work for the fd associated with stdin.
  1820.  
  1821. The attached piece of code illustrates the difficulty.
  1822.  
  1823. It simply reads chars, at 1/2 second intervals, from either
  1824. either stdin or the device given as it's argument.
  1825. Before each read, it shows the status that select() returns as
  1826. to whether there are chars to be read.
  1827. (1 = pending, 0 = buffer empty)
  1828.  
  1829. The idea is this:  
  1830.  
  1831.     run it on your tty, (first as stdin, then as an argument to be opened)
  1832.  
  1833.     type a blurb of garbage, (and hit return if not in cbreak mode)
  1834.  
  1835.     and watch as it reads off character by character.
  1836.  
  1837. What I find is that it works perfectly for the first case (run from stdin)
  1838. but totally fails for the second (where it opens your tty).
  1839.  
  1840. I have tried many variations on this:
  1841. I have used a real serial port as opposed to a ptty.
  1842. and I have verified that the termio settings don't effect the problem 
  1843. as far as I can tell with the information reported by 'stty -a'.
  1844.  
  1845. Any help would be greatly appreciated.
  1846.  
  1847. /*----------------------------------------------*/
  1848. #include <sys/types.h>
  1849. #include <sys/time.h>
  1850. #include <stdio.h>
  1851. #include <fcntl.h>
  1852.  
  1853. char getch();
  1854. int rdchk();
  1855.  
  1856. main(argc, argv)
  1857. int argc; char *argv[];
  1858.     {
  1859.     int iofd;
  1860.  
  1861.     setbuf(stdout, NULL);
  1862.  
  1863.     if ( argc == 2 )
  1864.         if ( (iofd = open(argv[1], O_RDWR)) == -1) 
  1865.             {
  1866.             printf("openerror\n"); 
  1867.             exit(1);
  1868.             }
  1869.         else
  1870.             printf("Opened %s\n", argv[1]);
  1871.     else
  1872.         {
  1873.         iofd=fileno(stdin);
  1874.         printf("Opened stdin\n");
  1875.         }
  1876.  
  1877.     while(1) 
  1878.         {
  1879.         usleep(500000);
  1880.         rdchk(iofd);
  1881.         getch(iofd);
  1882.         }
  1883.     }
  1884.  
  1885. char getch(iofd)
  1886. int iofd;
  1887.     {
  1888.     int got;
  1889.     char ch;
  1890.  
  1891.     if ( (got = read(iofd, &ch, 1) ) == -1 )
  1892.         {
  1893.         printf("read error\n");
  1894.         return(-1);
  1895.         }
  1896.  
  1897.     if (got > 0) 
  1898.         {
  1899.         printf("(%c)", ch); 
  1900.         return(ch);
  1901.         } 
  1902.     else 
  1903.         {
  1904.         printf("timeout");
  1905.         return(-1);
  1906.         }
  1907.     }
  1908.  
  1909. /* return true if a read will not block */
  1910. int rdchk( fd )
  1911. int fd;
  1912.     {
  1913.     int got;
  1914.     fd_set fdset;
  1915.     struct timeval timeout;
  1916.  
  1917.     FD_ZERO (&fdset);
  1918.     FD_SET (fd, &fdset);
  1919.     memset(&timeout, 0, sizeof(timeout));
  1920.  
  1921.     got = select (1, &fdset, NULL, NULL, &timeout);
  1922.     printf("select returned %u\n\r", got);
  1923.     return( got > 0 );
  1924.     }
  1925.  
  1926. /*----------------------------------------------*/
  1927.  
  1928. /* Pat@bcserv.wustl.edu */
  1929.  
  1930. -- 
  1931.  
  1932.  
  1933. Pat
  1934.  
  1935. -----------------------------
  1936.  
  1937. From: "David W. Rankin Jr." <rankin@ms.uky.edu>
  1938. Subject: Re: sudo with hidden password?
  1939. Date: 20 Nov 92 07:07:23 GMT
  1940. To:       info-unix@sem.brl.mil
  1941.  
  1942. In article <Bxz50B.IIB@news.cso.uiuc.edu> rolf@geoserv.isgs.uiuc.edu writes:
  1943. >I have been using the "sudo" command from the Unix System
  1944. >Administration Handbook by Nemeth/Snyder/Seebass and like it
  1945. >very much. However, I would like to find if someone has a
  1946. >modified version of it that would hide your password instead
  1947. >of displaying it for all to see.
  1948. >                                     Thank you.
  1949.  
  1950. Just after glancing through the code, I'd say that what you could do is
  1951. (assuming your system echos characters back rather than relying on local
  1952. echo) place a system("stty -echo");, or the equivalent, and see if that
  1953. helps anything. Place that call before the input for the password, then
  1954. system("stty echo"); after it. I don't know if it works myself, since I
  1955. don't have a UNIX system to run sudo on yet [yet :)], but my guess would
  1956. bne that that would work.
  1957.  
  1958. Hope this helps,
  1959.  
  1960. -- 
  1961. "You know, I don't think Apple could damage the Mac more if the tried."
  1962.   -me, on the new pricing schemes on System 7.1, MacTCP 1.1.1, and MacX
  1963. --"When UK pays me money for my opinions, it can have them. Not before."--
  1964. David W. Rankin, Jr.,  Mac Archiver for f.ms.uky.edu   Packrat on IRC
  1965. Main address: rankin@ms.uky.edu  rankin@ukma.BITNET ...!gatech!ukma!rankin
  1966.          Alternates: rankin@mik.uky.edu  djrank00@aix3090b.uky.edu
  1967.  
  1968. -----------------------------
  1969.  
  1970.  
  1971. End of INFO-UNIX Digest
  1972. ***********************
  1973.  
  1974.