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

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