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

  1. Path: sparky!uunet!gatech!darwin.sura.net!jvnc.net!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: <34211@adm.brl.mil>
  6. Date: 22 Nov 92 18:39:41 GMT
  7. Sender: news@adm.brl.mil
  8. Lines: 1863
  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:19:00 EST
  18. From: info-unix@BRL.MIL
  19. Subject: INFO-UNIX Digest  V17#008
  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:13 EST
  26. Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa25264; 21 Nov 92 7:23 EST
  27. Received: from sem.brl.mil by SEM.BRL.MIL id aa25030; 21 Nov 92 7:05 EST
  28. Date:       Sat, 21 Nov 92 07:04:42 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#008
  33. Message-ID:  <9211210705.aa25030@SEM.BRL.MIL>
  34.  
  35. INFO-UNIX Digest          Sat, 21 Nov 1992              V17#008
  36.  
  37. Today's Topics:
  38.                              UNIX Training
  39.               where no vi has gone before...? (CORRECTION)
  40.   Tutorials - nine topics (12/7, San Jose)  Sun User Group Conference
  41.                           tcsh-like subroutine
  42.                            Re: IS UNIX DEAD?
  43.                         Re: IS UNIX DEAD (long)
  44.                       Adoptation of Unix in Europe
  45.              Re: Looking for Time Series Analysis software
  46.              Re: What full-screen file managers are there?
  47.                      Re: SCO TCPIP >9 LOGINS AGAIN
  48.                          Unlocking named pipes
  49.                                 Re: grep
  50.                               FSCK command
  51.                        pwd: getwd: can't open ..?
  52.              Re: What full-screen file managers are there?
  53.                 lib77 "flush" call. Where is it in UNIX?
  54.                            Re: Wait for child
  55.                       Re: name of file descriptor
  56.                                 Re: talk
  57.                   Re: Changing the owner of a process
  58.                             file .fingerees
  59.          Re: Whence Unix? (was Re: IS UNIX DEAD?) (New Thread?)
  60.                        Curses support under DOS?
  61.                             MPE, NS, TCP/IP
  62.               Re: lib77 "flush" call. Where is it in UNIX?
  63.                     Re: Searching for E-mail package
  64.                         C++ Debugger with Motif
  65.              Re: Looking for Time Series Analysis software
  66.                           Re: file .fingerees
  67.             Re: BIG IMPORTANT QUESTION PLEEEEZE HELP ME!!!!!
  68.                 Shortened repost: mmap over NFS problem
  69.        Sun Printserver? IPX-stack available ? NCP documentation ?
  70.                 Tool for email, and snail mail addresses
  71.                   Re: Changing the owner of a process
  72.                        I need some pic-like thing
  73.                  Re: C Source Code for Pattern Matching
  74.                         Re: IS UNIX DEAD? (long)
  75.             Re: BIG IMPORTANT QUESTION PLEEEEZE HELP ME!!!!!
  76.                         Re: IS UNIX DEAD? (long)
  77.                         Re: tcsh-like subroutine
  78.                   Re: Changing the owner of a process
  79.                         Re: IS UNIX DEAD (long)
  80.                 rexec does not search for ~/.netrc file
  81.                            Re: IS UNIX DEAD?
  82.                      Re: IS UNIX DEAD? (very long)
  83.                    Re: Overflow warnings (SCO SV3.2)
  84.                  CURSES - No delay option, SunOS 4.1.1
  85.               Re: lib77 "flush" call. Where is it in UNIX?
  86.                         Re: IS UNIX DEAD? (long)
  87.              Re: What full-screen file managers are there?
  88. -----------------------------------------------------------------
  89.  
  90. From: "Mr. Themos Pentakalos; ADMIN-COMP" <themos@umbc5.umbc.edu>
  91. Subject: UNIX Training
  92. Date: 17 Nov 92 02:28:08 GMT
  93. Sender: News posting account <newspost@umbc3.umbc.edu>
  94. To:       info-unix@sem.brl.mil
  95.  
  96. Hi everyone,
  97.  
  98. I am not very familiar with the UNIX market and would like to ask
  99. a couple of questions.
  100.  
  101. 1) are there any companies which teach UNIX topics such as system
  102.    management, networking, etc? addresses? prices?
  103.  
  104. 2) what are the most popular magazines in the UNIX area?
  105.  
  106.     Thanks a lot. Please reply directly to:   themos@umbc5.umbc.edu
  107. and i'll be glad to summarize if comments are good.
  108.  
  109. Themos.
  110.  
  111. -----------------------------
  112.  
  113. From: Vinay Kashyap <kashyap@oddjob.uchicago.edu>
  114. Subject: where no vi has gone before...? (CORRECTION)
  115. Date: 17 Nov 92 02:35:07 GMT
  116. Sender: News System <news@wakinyan.uchicago.edu>
  117. To:       info-unix@sem.brl.mil
  118.  
  119. I had posted a list of questions on vi, and Tuomas Lukka pointed out
  120. that question 3 didn't make sense:
  121.  
  122. >3. Is there a way to prepend or append characters to macros without
  123. >   (a) introducing newlines between the additions, &/or
  124. >   (b) writing to the file and deleting to a named buffer
  125. It should have read as follows (I apologize for the error):
  126.  
  127. 3. Is there a way to prepend or append characters to BUFFERS without
  128.    (a) introducing newlines between additions (yanking to an uppercase
  129.    buffer appends to text already in the buffer, but on a new line) &/or
  130.    (b) writing to the file and deleting to the named buffer (in other
  131.    words, are there ways to put characters in named buffers other than
  132.    yanking/deleting text)?
  133.  
  134. Vinay (kashyap@oddjob.uchicago.edu)
  135.  
  136. -----------------------------
  137.  
  138. From: Nancy Frishberg <nancyf@sug.org>
  139. Subject: Tutorials - nine topics (12/7, San Jose)  Sun User Group Conference
  140. Keywords: tutorials seminar Unix security programming tools network debugging
  141. Date: 17 Nov 92 00:19:49 GMT
  142. Sender: Mr USENET himself <news@world.std.com>
  143. Nntp-Posting-Host: sug.org
  144. To:       info-unix@sem.brl.mil
  145.  
  146.  
  147. If you're concerned about advanced Unix security, Posix-conforming
  148. systems, or moving from Unix programming to Unix system
  149. administration, plan to be at the Sun User Group Conference (San Jose
  150. Convention Center) on Monday, December 7, 1992 for one of the full day
  151. tutorials.  The Conference and Exhibition extends through Thursday.
  152.  
  153. All-day tutorials will focus on these topics and others of interest to
  154. novice and experienced Unix users as well as Unix programmers who want
  155. to expand their theoretical and practical knowledge.
  156.  
  157. Special offer: 5 full conference registrations (each includes a day of 
  158. tutorial) for the price of 4 when preregistering with a single payment.
  159.  
  160. Full-day tutorials currently scheduled include:
  161. - Advanced Unix Security (Matt Bishop, Dartmouth College)
  162. - Preparing for Disaster (a.m. - Brent Chapman, Great Circle Associates),
  163.   plus, Why have Computer Security? (p.m. Bob Baldwin, Tandem Computers)
  164. - Sun Network Debugging (Smoot Carl-Mitchell, Texas Internet Consulting)
  165. - Topics in Perl (Tom Christiansen, Convex Computer Corporation)    
  166. - Programming in POSIX (Jeffrey S. Haemer, Canary Software)    
  167. - UNIX Programming Tools (Kenneth Ingham, consultant)
  168. - The Internet and its Protocols (William LeFebvre, Northwestern University)
  169. - Introduction to UNIX System Administration (Dinah McNutt, Tivoli Systems)
  170. - Integrating C Code and Xt Widgets (Craig Rudlin, MD, Medical Software and Computer Systems)
  171.  
  172. If you just want to go to the exhibits, ask for a free show-only pass.
  173.  
  174. To get more information by email about these tutorials, the technical
  175. program, or exhibits at the Sun User Group conference, send requests
  176. to sugshow@sug.org .
  177.  
  178. You will receive the full tutorials and program description with
  179. registration information.  Or call 1-800/727-EXPO.  (Outside the U.S.,
  180. use 512/331-7761 (voice) or 512/331-3950 (FAX).)  
  181.  
  182. -- 
  183. Nancy Frishberg, Sun User Group.
  184.  
  185. -----------------------------
  186.  
  187. From: Karl Glazebrook <Karl.Glazebrook@durham.ac.uk>
  188. Subject: tcsh-like subroutine
  189. Date: 16 Nov 92 16:07:56 GMT
  190. Nntp-Posting-Host: dur.dust6
  191. To:       info-unix@sem.brl.mil
  192.  
  193. Hello,
  194.  
  195. I'm looking for a tcsh like input routine which would be callable from a C or
  196. FORTRAN program. I just want to be able to read a line of text from the user
  197. with tcsh-like (or emacs-like!) command line editing/recall features.
  198.  
  199. I'm working on a SPARC with SUNOS 4.1.3 but obviously the more general and
  200. portable the solution the better!
  201.  
  202. As a bonus there would also be another routine which could modify the recall
  203. list, but this is not essential as I could probably hack this myself given
  204. the first subroutine.
  205.  
  206. Thanks for any help,
  207.  
  208. Karl Glazebrook.
  209.  
  210. ---
  211.  ------------------------------------------------------------------------------
  212. | Karl Glazebrook,      | INTERNET:   Karl.Glazebrook@durham.ac.uk           |
  213. | Dept. of Physics,     |    JANET:   KARL.GLAZEBROOK@UK.AC.DURHAM           |
  214. | Univ. of Durham,      |     SPAN:   19463::DUVAD::KGB                      |
  215. | United Kingdom.       |      FAX:   091-374-3749                           |
  216.  ------------------------------------------------------------------------------
  217.  
  218. -----------------------------
  219.  
  220. From: Leslie Mikesell <les@chinet.chi.il.us>
  221. Subject: Re: IS UNIX DEAD?
  222. Date: 16 Nov 92 18:17:47 GMT
  223. To:       info-unix@sem.brl.mil
  224.  
  225. In article <1992Nov11.215409.18067@osuunx.ucc.okstate.edu> martin@datacomm.ucc.okstate.edu (Martin McCormick) writes:
  226.  
  227. >First, I completely agree with Jeff's enthusiasm for this system.  It is good
  228. >and probably is the wave of the future.  I do have one gripe, however.
  229. >As I have said, in other postings, Postscript is a half-finished job until
  230. >somebody comes up with a method for converting it back into standard ASCII
  231. >text like the lines you are reading, now.
  232.  
  233. I think GNU Ghostscript has an ASCII output option that will generate
  234. text positioned approximately where it is supposed to be on a page
  235. with anything else omitted.  
  236.  
  237. > The windows-oriented approach is
  238. >totally useless for those of us who are blind and use speech synthesizers.
  239. >We were able to cobble together a small C program to strip out all that
  240. >Postscript language and display a completely deformatted stream of data.
  241. >It beats nothing, though not by much.  I would love to help fix this problem,
  242. >but I need to find a document explaining Postscript in electronic form so
  243. >I can read it and figure out how to tackle this beast.
  244.  
  245. It's non-trivial in the general case because you have to be able to handle
  246. the entire postscript language to interpret the positioning and scaling
  247. effects.  Plus you'll miss things where fonts have been converted to
  248. curves and manipulated for artistic but still readable effects.  A
  249. quick and dirty approach is to just extract the strings in parens
  250. from the postscript and try to assemble them into text.  A more ambitious
  251. project would be to modify the Ghostscript ascii output to maintain
  252. some font size and type info that could be used by the speech synthesizer
  253. to vary the output effects.
  254.  
  255. Les Mikesell
  256.   les@fb.com
  257.  
  258. -----------------------------
  259.  
  260. From: Andy Newman <andy@research.canon.oz.au>
  261. Subject: Re: IS UNIX DEAD (long)
  262. Date: 16 Nov 92 23:44:31 GMT
  263. Sender: news@research.canon.oz.au
  264. To:       info-unix@sem.brl.mil
  265.  
  266. papresco@napier.uwaterloo.ca (Paul Prescod) writes:
  267. >
  268. >True, the problem is there are people, in this very newsgroup, who see
  269. >no reason to try to make user friendly applications for unix.  To them,
  270. >if you can't use VI right off the bat, or enjoy learning obscure, 
  271. >nonsensical, illogical keystrokes, you should go back to the mac.
  272. >THIS will kill Unix.
  273. >
  274.  
  275. Define "user friendly". Aren't the people who like vi users too?
  276.  
  277. -- 
  278. Andy Newman (andy@research.canon.oz.au)
  279.  
  280. -----------------------------
  281.  
  282. From: Nick Gavrielatos <gavriel@socrates.umd.edu>
  283. Subject: Adoptation of Unix in Europe
  284. Keywords: Unix, Europe
  285. Date: 17 Nov 92 04:51:55 GMT
  286. To:       info-unix@sem.brl.mil
  287.  
  288. I am preparing some work on adoptation of Unix in Europe.
  289.  
  290. WOuld anyone happen to have any old articles, or know 
  291. of any other magazine and/or book articles that can 
  292. recommend? Any info via personal mail would be greatly
  293. aprreciated.
  294.  
  295. Thank you much, 
  296.  
  297. Nick Gavrielatos
  298. gavriel@socrates.umd.edu
  299.  
  300. -----------------------------
  301.  
  302. From: s jonathan silverman <sjs6@quads.uchicago.edu>
  303. Subject: Re: Looking for Time Series Analysis software
  304. Date: 17 Nov 92 05:16:27 GMT
  305. Sender: News System <news@uchinews.uchicago.edu>
  306. To:       info-unix@sem.brl.mil
  307.  
  308.  
  309. The leading program for time series analysis is probably RATS, which runs
  310. under DOS, the Macintosh, Unix and perhaps some other operating systems
  311. as well.
  312.  
  313. The company that writes this is located in Evanston, IL.  Their name used
  314. to be VAR econometrics, but they might well have changed it about a year ago
  315. (perhaps to "Estima", but I could have them confused with another company).
  316.  
  317. RATS stands for something like "regression analysis for time series" and 
  318. contains a broad array of time series analysis functions including specral
  319. analysis.
  320.  
  321. If you cant track this down yourself, contact me by email and I will send
  322. you the phone number.
  323.  
  324. -- 
  325. Jonathan Silverman
  326.  
  327. sjs6@quads.uchicago.edu
  328. jonat@cicero.spc.uchicago.edu
  329.  
  330. -----------------------------
  331.  
  332. From: Pete Holsberg <pjh@mccc.edu>
  333. Subject: Re: What full-screen file managers are there?
  334. Keywords: utree, maint
  335. Date: 16 Nov 92 22:33:40 GMT
  336. To:       info-unix@sem.brl.mil
  337.  
  338. In article <1e4mbcINN1kh@crcnis1.unl.edu> pkramer@unlinfo.unl.edu (Paul Kramer) writes:
  339. =Hello,
  340. =
  341. =I found while reading articles in this electronic conference, a 
  342. =reference to a public-domain program called utree.  It is full-screen 
  343. =file manager which allows you to perform file functions with single 
  344. =keystrokes.  For example, after I start the program I see a screen 
  345. =that lists the files on my account.  If I want to delete one of those 
  346. =files I move the cursor on top of it, press a certain key.  Boom it 
  347. =gone!  
  348. =
  349. =Well I am wondering:  Is there anything better than utree?  I am aware
  350. =of a program called 'maint' but it doesn't have the full functionality
  351. =of 'utree'.
  352.  
  353. I prefer HDSCAN.
  354.  
  355. -----------------------------
  356.  
  357. From: Bill Campbell <bill@celestial.com>
  358. Subject: Re: SCO TCPIP >9 LOGINS AGAIN
  359. Date: 17 Nov 92 02:00:52 GMT
  360. To:       info-unix@sem.brl.mil
  361.  
  362. In <9461.63.uupcb@cccbbs.UUCP> doug.pavey@cccbbs.UUCP (Doug Pavey) writes:
  363.  
  364. >Well, I read Aris' and Barry's messages about what is involved in
  365. >getting more than 9 tty's to login.  ttyp00 -ttyp08 work fine, ttyp09
  366. >will login, but hang TCP.
  367.  
  368. Xenix has a max of 32 ptys and SCO UNIX a max around 254.
  369.  
  370. >How does one debug streams limits problems - determine how many are in
  371. >use, or how many one should set up if the user may be using as many as
  372. >10 processes per login (Progress Database is wonderful).  All users are
  373. >using TCP via 3 8 port Terminal servers. I can get the login messages on
  374. >all ports, until the user actually signs in, we don't seem to have
  375. >problems.  Seems like streams may be the culprit.  How to fix???
  376.  
  377. You don't say in this post whether you're running Xenix or UNIX
  378. and there are different tools to determine problems with streams
  379. in each.  Xenix comes with a program 'sw', UNIX comes with crash, and
  380. there are some freely distributed monitor programs such as u386mon
  381. available from various ftp sites.
  382.  
  383. Xenix sw displays:
  384.  
  385. Pause=1   Calls=74                                Host=camco1
  386.  
  387.    Resource  Cnt       Use   Total     Max    Fail
  388.      stream: 128        40    4020      53       0
  389.       queue: 256        83    8074     111       0
  390.      mblock:1152        7818508524     636       0
  391. dblk totals:1152        7813966687     543    4469
  392.  
  393. Mem Size Cnt Med Low   Use   Total     Max    Fail
  394.   1    4 256 230 204     0  893844     155       0
  395.   2   16 128 115 102     2  449445     102     889
  396.   8   32 256 230 204     6 2644776     207    3339
  397.  16   64 256 230 204     5 8602774     147       0
  398.  16  128 128 115 102    50  386387     103      18
  399.  12  256  48  43  38    15  220139      37       0
  400.   4  512   8   7   6     0  102435       7     223
  401.  32 1024  32  28  25     0   50083       8       0
  402.  64 2048  32  28  25     0  584718      13       0
  403.  32 4096   8   7   6     0   32086       5       0
  404.   0 8192   0   0   0     0       0       0       0
  405.  
  406. Buffers (used/total) = 11/187 Kbytes
  407.  
  408. This is from a system that has been running for a while now.  Uptime gives:
  409. camco1:ttyp02 /usr/local/bin # uptime
  410.   5:53pm  up 20 days, 55 mins,  12 users,  load average: 1.19, 1.04, 1.02
  411.  
  412. You would probably want to use crash and it's strstat command on a UNIX
  413. system which gives similar information.  A typical crash display is:
  414. beeson1:ttyp8:/onager/etc > crash
  415. dumpfile = /dev/mem, namelist = /unix, outfile = stdout
  416. > strstat
  417. ITEM                  CONFIG   ALLOC    FREE         TOTAL     MAX    FAIL
  418. streams                  256      158      98           821     171       0
  419. queues                  1280      704     576          2306     786       0
  420. message blocks          2825      309    2516      11357083     705       0
  421. data block totals       2260      309    1950       9675047     669      63
  422. data block size    4     384       51     333         66265     364      63
  423. data block size   16     384        8     376         39861      65       0
  424. data block size   64     512       24     488       4950469      68       0
  425. data block size  128     448      157     290       2974970     392       0
  426. data block size  256     220       33     187        632454     107       0
  427. data block size  512     136       36     100        495575      46       0
  428. data block size 1024      52        0      52         84628      44       0
  429. data block size 2048     104        0     104        430474      25       0
  430. data block size 4096      20        0      20           351      12       0
  431.  
  432. Count of scheduled queues:   0
  433. >
  434.  
  435. Bill
  436. -- 
  437. INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Software
  438. UUCP:   ...!thebes!camco!bill   6641 East Mercer Way
  439.              uunet!camco!bill   Mercer Island, WA 98040; (206) 947-5591
  440. SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
  441.  
  442. -----------------------------
  443.  
  444. From: "frederick.d.true" <ft@cbnewsi.cb.att.com>
  445. Subject: Unlocking named pipes
  446. Keywords: named pipe
  447. Date: 17 Nov 92 06:11:16 GMT
  448. Followup-To: ftrue@attmail.att.com
  449. To:       info-unix@sem.brl.mil
  450.  
  451. I'm having a bit of trouble figuring out what's wrong with the
  452. following usage of named pipes. I have 12 large compressed files which
  453. I would like to merge/sort (they are sorted) without having to
  454. decompress all of them before merging. So, I've written a simple script
  455. to create 12 named pipes with mknod, say pipe1..pipe12. I begin
  456. background processes to zcat each of the 12 files to one of the pipes
  457. in sequence. I then start 'sort <switches> -m pipe1 .. pipe12 | <stuff> >
  458. outputfile'.
  459.  
  460. Things go fine for a while, then the entire process freezes. The
  461. output stream stops, and all processes go into IW wait, as if waiting
  462. for something to happen. While in deadlock, if I try to read any of
  463. the pipes, they each have data waiting, so all seems to be fine. So
  464. who stopped everything and why?
  465.  
  466. Sort is able to merge at most 16 files at once, so I don't think
  467. there's anything wrong there. Is there another anomoly in sort that
  468. might cause this failure?
  469.  
  470. As best I can tell, sort found a depleted pipe that zcat couldn't keep
  471. up with (perhaps sort is reading large buffers?), but no EOF, and
  472. started sleeping. However, this isn't logical since the sort process
  473. is followed by 3 other heavyweight processes in the pipe before the
  474. output is written, so I would think that zcat could feed the pipes
  475. fast enough. Besides, I thought processes would handle FIFO's normally
  476. and sleep for at most a few seconds if it found and empty one before
  477. hitting EOF.
  478.  
  479. By the way, in case it proves significant: I'm using SunOS 4.1.2 on a
  480. SPARC. Standard sort, zcat, etc. Named pipes are created with mknod
  481. -p. I've also tried sleeping for a few seconds before starting things,
  482. with no results.
  483.  
  484. Can someone clear up the confusion, or at least add postulations to
  485. the heap?
  486.  
  487. Please e-mail to ftrue@attmail.att.com or post here.
  488.  
  489. --
  490. Fred True
  491. AT&T
  492.  
  493. -----------------------------
  494.  
  495. From: "David L. Parker" <dlparker@dlpinc00.rn.com>
  496. Subject: Re: grep
  497. Date: 17 Nov 92 03:36:38 GMT
  498. To:       info-unix@sem.brl.mil
  499.  
  500. In article <1992Nov16.092645.522@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes:
  501. >In article <1992Nov13.113839.25046@dlpinc00.rn.com>, 
  502. >dlparker@dlpinc00.rn.com (David L. Parker) writes:
  503. >|> 
  504. >|> Actually it's Global Regular Expression Parser.
  505. >
  506. >Unfortunately Brian Kernigan and Rob Pike disagree with you, see
  507. >page 18 of:
  508. >
  509. >The Unix Programming Environment
  510. >Prentice Hall
  511. >ISBN 0-13-937699-2
  512. >
  513.  
  514. WOOPS!  Okay, so I got three out of four.
  515. -- 
  516. Dave Parker
  517. Automated Data Management Services, Pleasant Hill, MO 64080-1331
  518. (816) 987-5167/5218 voice/fax          -          dlpinc00!dlparker
  519.  
  520. -----------------------------
  521.  
  522. From: Big.Fun@debug.cuc.ab.ca
  523. Subject: FSCK command
  524. Date: 17 Nov 92 04:50:34 GMT
  525. To:       info-unix@sem.brl.mil
  526.  
  527. When using the fsck (file system check), when it comes upon part 4 of
  528. the check, which is a reference check, it says, "UNREF DEVICE".  What
  529. does this mean?
  530.  
  531. Thanks.. please send all replies via mail..
  532.  
  533. suicide
  534. big.fun@debug.cuc.ab.cu
  535.  
  536. -----------------------------
  537.  
  538. From: Jonas Furrer <jonas@uiag.ch>
  539. Subject: pwd: getwd: can't open ..?
  540. Date: 16 Nov 92 11:10:22 GMT
  541. To:       info-unix@sem.brl.mil
  542.  
  543. Hi,
  544.  
  545. why I have this error -> pwd: getwd: can't open ..
  546.  
  547.  
  548. OS          : OS/MP 4.1A.1 (Solbourne -> SUN 4.1)
  549. fstab entry : /dev/sd2d /files/disk2/imagery  4.2 rw 1 9
  550.  
  551. belfast:/% df /dev/sd2d
  552. Filesystem            kbytes    used   avail capacity  Mounted on
  553. /dev/sd2d             564349  311204  196710    61%    /files/disk2/imagery
  554.  
  555. belfast:/% ls -agld files 
  556. drwxrwxrwx  6 root          512 Oct 21 15:48 files
  557.  
  558. belfast:/% cd /files
  559. belfast:/files% ls -agld files
  560. drwxrwxrwx  4 root          512 Oct  2 14:07 disk2
  561. belfast:/files% pwd
  562. /files
  563.  
  564. belfast:/files% cd disk2
  565. belfast:/files/disk2% ls -agld files
  566. drwxrwxrwx  5 root          512 Nov 13 11:16 imagery
  567. belfast:/files/disk2% pwd
  568. /files/disk2
  569.  
  570. belfast:/files/disk2% cd imagery
  571. belfast:/files/disk2/imagery% pwd
  572. pwd: getwd: can't open ..
  573. belfast:/files/disk2/imagery% df .
  574. Filesystem            kbytes    used   avail capacity  Mounted on
  575. Could not find mount point for .
  576.  
  577. Can anyone help?
  578.  
  579. Thanks.
  580.  
  581.           +---------------------+---------------------------+
  582.           |Jonas Furrer         |E-Mail : jonas@uiag.ch     |
  583.           |Emch + Berger AG     |Tel    : +41 31 25 23 23   |
  584.           |Gartenstrasse 1      |Fax    : +41 31 25 16 85   |
  585.           |3001 BERN (CH)       |                           |
  586.           +---------------------+---------------------------+
  587.  
  588. -----------------------------
  589.  
  590. From: Arnaldo MANDEL <mandel@litp.ibp.fr>
  591. Subject: Re: What full-screen file managers are there?
  592. Date: 17 Nov 92 09:01:45 GMT
  593. Sender: Le Facteur <news@jussieu.fr>
  594. Nntp-Posting-Host: litp4.ibp.fr
  595. Full-Name: Arnaldo MANDEL
  596. To:       info-unix@sem.brl.mil
  597.  
  598. In article <1992Nov16.223340.15353@mccc.edu> pjh@mccc.edu (Pete Holsberg) writes:
  599.  
  600. > In article <1e4mbcINN1kh@crcnis1.unl.edu> pkramer@unlinfo.unl.edu (Paul Kramer) writes:
  601. > =Hello,
  602. > =
  603. > =I found while reading articles in this electronic conference, a 
  604. > =reference to a public-domain program called utree.  It is full-screen 
  605. > =file manager which allows you to perform file functions with single 
  606. > =keystrokes.  For example, after I start the program I see a screen 
  607. > =that lists the files on my account.  If I want to delete one of those 
  608. > =files I move the cursor on top of it, press a certain key.  Boom it 
  609. > =gone!  
  610. > =
  611. > =Well I am wondering:  Is there anything better than utree?  I am aware
  612. > =of a program called 'maint' but it doesn't have the full functionality
  613. > =of 'utree'.
  614.  
  615. > I prefer HDSCAN.
  616.  
  617. Better go all the way and get emacs, with tree-dired.  You not only get all
  618. funtions most file managers execute, but you can add some of your own.  And
  619. then, this would be just the beginning of using emacs for almost everything,
  620. instead of hundreds of little frozen utilities.
  621. --
  622.  ............................................................
  623. Arnaldo Mandel   ---  am@ime.usp.br
  624. Temporarily: mandel@litp.ibp.fr
  625.  
  626. -----------------------------
  627.  
  628. From: Bruce Sams <bruce@head-cfa.harvard.edu>
  629. Subject: lib77 "flush" call. Where is it in UNIX?
  630. Date: 17 Nov 92 12:23:03 GMT
  631. To:       info-unix@sem.brl.mil
  632.  
  633. Dear fellow UNIX and HP-UX folks,
  634.  
  635.    I am trying to bring up the graphics package MONGO on our HP-720 machine
  636.    and I have encountered a problem.  It seems that MONGO uses a "flush"
  637.    call deep in its IO guts.  Looking through all the HP-UX libraries I 
  638.    find no such routine.  Rather, I find "pflushli", "flushinp", "intrflush",
  639.    "__cflush", "fflush", and "fflush_p."  Some of these are clearly not
  640.    what I want, but others are less certainly wrong.  I find no documentation
  641.    for any of these readily available.  How do I proceed?  Has anybody out
  642.    there installed MONGO under HP-UX?
  643.  
  644. Cheers,
  645.  
  646. Lowell Tacconi-Garman
  647.  
  648. -----------------------------
  649.  
  650. From: der Mouse <mouse@thunder.mcrcim.mcgill.edu>
  651. Subject: Re: Wait for child
  652. Date: 17 Nov 92 12:54:28 GMT
  653. Followup-To: comp.unix.questions
  654. To:       info-unix@sem.brl.mil
  655.  
  656. In article <1992Nov16.122725.15971@alf.uib.no>, singg@alf.uib.no (Kurt George Gjerde) writes:
  657.  
  658. > On Unix, how can I have a process wait for it's child process to do
  659. > something (not terminate).
  660.  
  661. This is a UNIX question, not a C question.  Consequently, I'm
  662. cross-posting to comp.unix.questions and directing followups there.
  663.  
  664. There are multiple ways.  You can have the child send some signal to
  665. the parent.  You can create a pipe (or other stream connection) and
  666. have the child write and the parent read.  You can use semaphores, if
  667. your system provides them.  There are probably other ways that don't
  668. come to mind at the moment.
  669.  
  670. Which one is best?  That depends on many factors, such as the required
  671. response time, how much information needs to be passed (besides the
  672. bare fact of the wakeup), how widely portable the code needs to be,
  673. what if anything the parent is doing while waiting....
  674.  
  675.                     der Mouse
  676.  
  677.                 mouse@larry.mcrcim.mcgill.edu
  678.  
  679. -----------------------------
  680.  
  681. From: der Mouse <mouse@thunder.mcrcim.mcgill.edu>
  682. Subject: Re: name of file descriptor
  683. Date: 17 Nov 92 12:59:31 GMT
  684. Followup-To: comp.unix.questions
  685. To:       info-unix@sem.brl.mil
  686.  
  687. In article <1992Nov16.122835.16126@alf.uib.no>, singg@alf.uib.no (Kurt George Gjerde) writes:
  688.  
  689. > How can I get the filename from a filedescriptor, on Unix??
  690.  
  691. This is a UNIX question, not a C question, and I'm therefore
  692. crossposting to comp.unix.questions and redirecting followups there.
  693.  
  694. In general, you can't.  The file descriptor may not be connected to a
  695. file (it may be a pipe or (other) socket or TLI stream or a device or
  696. maybe something else).  Even if it is a file, the file may have no
  697. names any longer, or it may have multiple names.  Even if it has at
  698. least one name, there may be no name by which it is accessible to your
  699. process or possibly even other processes.  And even if you assume it
  700. has a name that you could use to refer to it by, there is no way to
  701. find any such name short of a full scan of all filesystems, which can
  702. take a *long* time.
  703.  
  704. You're usually best off writing wrappers for open/close (or
  705. fopen/fclose if you're using stdio) that remember filenames.  The major
  706. case where this doesn't work is when you're dealing with redirection to
  707. or from files, in which case you're pretty much out of luck.
  708.  
  709.                     der Mouse
  710.  
  711.                 mouse@larry.mcrcim.mcgill.edu
  712.  
  713. -----------------------------
  714.  
  715. From: der Mouse <mouse@thunder.mcrcim.mcgill.edu>
  716. Subject: Re: talk
  717. Date: 17 Nov 92 13:06:42 GMT
  718. To:       info-unix@sem.brl.mil
  719.  
  720. In article <83678@ut-emx.uucp>, devil@ccwf.cc.utexas.edu (The Beast) writes:
  721.  
  722. > I tried to use 'talk' to converse with a friend in another college.
  723. > I got the following message:
  724. > 'Target machine does not recognize us'.
  725.  
  726. This means simply that talkd on the remote machine did a
  727. gethostbyaddr() on your machine's address and got a failure indication.
  728.  
  729. Either the remote machine is broken somehow or whatever nameserver is
  730. responsible for the relevant .in-addr.arpa zone is misbehaving, or
  731. (worst case) hasn't been set up.
  732.  
  733. > If so, how can this situation be circumvented?
  734.  
  735. The right way to fix it is to fix whatever's wrong.  A workable
  736. substitute is to fix talkd so that if gethostbyaddr() fails, it prints
  737. the numeric address instead (and in parallel, fix talk to accept
  738. numeric addresses).  This is what I've done, and sometimes when the net
  739. is flaking out (and thereby breaking the DNS) it's proven useful.
  740.  
  741.                     der Mouse
  742.  
  743.                 mouse@larry.mcrcim.mcgill.edu
  744.  
  745. -----------------------------
  746.  
  747. From: Ed Posnak <eposnak@dale.ksc.nasa.gov>
  748. Subject: Re: Changing the owner of a process
  749. Keywords: process owner
  750. Date: 17 Nov 92 14:28:37 GMT
  751. To:       info-unix@sem.brl.mil
  752.  
  753.  
  754. In article <1992Nov5.235228.1944@dale.ksc.nasa.gov> I wrote:
  755. "Is there an un-general way of changing the euid of a process from another
  756. "process?  We have an unusal requirement on our project for a 'shift-change'
  757. "where a user logs in and 'inherits' ownership processes that were running
  758. "under another euid.  Thanks in advance.
  759.  
  760. Thanks to all who responded.  I was surprised at the number of different 
  761. responses I received, (most involving setuid()) which led me to realize my 
  762. wording must've been real vague.
  763.  
  764. What I was looking for was something along the lines of how to change the 
  765. effective user id of a process who's source I may not be able to modify, by 
  766. some other means, e.g. from another process.  Many suggested writing a device
  767. driver or system call to do this.  Here is one answer along those lines. 
  768. ---
  769.  
  770. This is one of those dirty tricks I've always wanted to get around to
  771. figuring out a way to do... (without kernel source, that is)
  772.  
  773. I believe it could be done by writing a device driver. Open the device
  774. driver and write commands to it, and it does the dirty work. For
  775. instance, send it 8 bytes containing the process to change and the uid
  776. to change it to.
  777.  
  778. The uid, in every version of Unix I've seen, is stored in the proc
  779. structure in the kernel. You should be able to fiddle with this at
  780. will in a device driver, and since it's in the proc structure and not
  781. the u area, it'll always be there even if the process is swapped out.
  782. It *should* be just a matter of searching for the entry and changing
  783. it.
  784.  
  785. This technique should also serve to implement something like renice()
  786. under Xenix, which doesn't have it. (The nice value also being stored
  787. in the proc structure.)
  788. --
  789. Mark Buda
  790.  
  791. I get my monkeys for nothing and my chimps for free.
  792. ---
  793.  
  794. I would enjoy hearing from anyone who might have done this already.  Thanks.
  795.  
  796.  
  797.  
  798. -- 
  799. --
  800. Ed Posnak
  801. Harris Space Systems Corporation
  802. eposnak%core1@kssib.ksc.nasa.gov
  803.  
  804. -----------------------------
  805.  
  806. From: Luke Higgins <lukeh@gnumath.rutgers.edu>
  807. Subject: file .fingerees
  808. Date: 17 Nov 92 13:56:41 GMT
  809. To:       info-unix@sem.brl.mil
  810.  
  811.  
  812. I have found a program which attempts to execute a file when you are
  813. fingered and I am having problems getting it to work.  My problem is
  814. that on my system I can't seem to find the .fingerees file.  Is this
  815. a standard unix file and if so how do I go about finding it.
  816.     Thanks
  817.     Luke  (a computer novice  to say the least)
  818.  
  819. -----------------------------
  820.  
  821. From: Lamar Owen <lowen@lorc.uucp>
  822. Subject: Re: Whence Unix? (was Re: IS UNIX DEAD?) (New Thread?)
  823. Date: 16 Nov 92 15:57:21 GMT
  824. To:       info-unix@sem.brl.mil
  825.  
  826. In <STEVEV.92Nov13100727@miser.uoregon.edu> stevev@miser.uoregon.edu (Steve VanDevender) writes:
  827. >In article <1dvltdINN6i4@skat.usc.edu> jlowrey@skat.usc.edu (John 'Fritz' Lowrey) writes:
  828.  
  829.  
  830. >       My seed:
  831. >       Microsoft DOS    ->    Intended as a stepping stone while DR 
  832. >                   wrapped up CP/M-86, and now the program
  833. >                   loader of choice for countless millions. 
  834.  
  835. >You really need to study up on your computing history.  You seem
  836. >to imply that Microsoft got MS-DOS from Digital Research.
  837. >Microsoft got MS-DOS from a small firm called Seattle Computer,
  838. >which had written a quick-and-dirty CP/M clone called SC-DOS.
  839. >Then Microsoft hacked it up and marketed the hell out of it.
  840.  
  841. The original marketing niche for MS-DOS was as a stepping stone from the
  842. 8-bit CP/M world to the multiuser 16-bit world of Xenix.  Microsoft, in
  843. the early 80's, fully intended to make Xenix their high-end OS.  However,
  844. the market chose otherwise.
  845.  
  846.  
  847. >Steve VanDevender     
  848.  
  849. -- 
  850. --
  851.  
  852. Lamar Owen, Systems Consultant, GE Lighting Systems, Hendersonville, NC
  853. ***********************************************************************
  854.  Opinions expressed herein are the author's and do not reflect policy
  855.    or opinions of the General Electric Company or its subsidiaries.
  856. ***********************************************************************
  857.  
  858. -----------------------------
  859.  
  860. From: Jeffrey Reilly <jwreilly@mipos2.intel.com>
  861. Subject: Curses support under DOS?
  862. Date: 17 Nov 92 15:56:17 GMT
  863. Sender: USENET News System <news@inews.intel.com>
  864. Nntp-Posting-Host: mipos2
  865. To:       info-unix@sem.brl.mil
  866.  
  867. Is anyone aware of a curses package that works/can be ported to a DOS
  868. environment?
  869.  
  870. Any pointers would be appreciated!
  871.  
  872. Jeff
  873.  
  874. Jeff Reilly            | "Do not route the (Ethernet)
  875. Intel Corporation        | cable near a cyclotron" -
  876. jwreilly@mipos2.intel.com    | LAN/586 Board User's Guide
  877. (408) 765 - 5909        |
  878.  
  879. -----------------------------
  880.  
  881. From: Steven Lon George <georges@zeus.franklin.edu>
  882. Subject: MPE, NS, TCP/IP
  883. Date: 17 Nov 92 17:53:29 GMT
  884. To:       info-unix@sem.brl.mil
  885.  
  886. Hello there.  What I am wondering relates to the HP UNIX environment.
  887.  
  888. I am applying for a job under this environment, in a networking
  889. application. The job has some criteria that I am not sure what it means.
  890. I am hoping I can find someone who does. Anyway, the line reads as
  891. follows.?
  892.  
  893. Must have knowledge of MPE, NS, TCP/IP & Network Components and
  894. Architecture.
  895.  
  896. What is MPE (Multiplatorm Environment?), and NS.  Has anyone ever heard
  897. these acronyms before.  The interview is on Thursday, so you can answer
  898. by mail at 'georges@zeus.franklin.edu'.  Please notice the plural 
  899. georges with an s.  otherwise, someone else will get the message.
  900.  
  901. Thanks in advance.
  902.  
  903. Steve.... 
  904.  
  905. -----------------------------
  906.  
  907. From: "System Admin (Mike Peterson" <system@alchemy.chem.utoronto.ca>
  908. MMDF-Warning:  Parse error in original version of preceding line at BRL.MIL
  909. Subject: Re: lib77 "flush" call. Where is it in UNIX?
  910. Date: 17 Nov 92 17:29:55 GMT
  911. To:       info-unix@sem.brl.mil
  912.  
  913. In article <1992Nov17.122303.3080@cfa160.harvard.edu> bruce@head-cfa.harvard.edu (Bruce Sams) writes:
  914. >Dear fellow UNIX and HP-UX folks,
  915. >
  916. >   I am trying to bring up the graphics package MONGO on our HP-720 machine
  917. >   and I have encountered a problem.  It seems that MONGO uses a "flush"
  918. >   call deep in its IO guts.  Looking through all the HP-UX libraries I 
  919. >   find no such routine.  Rather, I find "pflushli", "flushinp", "intrflush",
  920. >   "__cflush", "fflush", and "fflush_p."  Some of these are clearly not
  921. >   what I want, but others are less certainly wrong.  I find no documentation
  922.  
  923. You can write a "flush" that calls "fflush" (which is a standard C
  924. routine, and you should have a man page for it). You will need to use the
  925. HP-UX 'fstream' routine to map the FORTRAN unit number to a C stream number.
  926.  
  927. I can't send you source for flush since it is licensed, but you can
  928. have these routines I used to make it work:
  929.  
  930.       function igetfstream (lunit)
  931. c
  932. c     Purpose:
  933. c        Return the FILE pointer corresponding to unit 'lunit',
  934. c        or 0 if unit 'lunit' is not open.
  935. c
  936.       logical opened
  937. c
  938. c
  939. c     write (6,*) 'igetfstream called for unit ', lunit
  940.       inquire (unit=lunit, opened=opened)
  941.       if (opened) then
  942.          igetfstream = fstream (lunit)
  943.          if (igetfstream .eq. 0) then
  944.             if (lunit .eq. 5) then
  945.                igetfstream = igetstdin ()
  946.             else if (lunit .eq. 6) then
  947.                igetfstream = igetstdout ()
  948.             else if (lunit .eq. 7) then
  949.                igetfstream = igetstderr ()
  950.             end if
  951.          end if
  952.       else
  953.          igetfstream = 0
  954.       end if
  955. c     write (6,'(1x,a,z9.8)') 'igetfstream returning ', igetfstream
  956.       return
  957.       end
  958.  
  959. To get the stream number for stdin/stdout/stderr, try:
  960.  
  961. /*
  962.  * Return the FILE pointer to stdin.
  963.  */
  964.  
  965. #include <stdio.h>
  966.  
  967.     FILE *
  968. igetstdin_ ()
  969. {
  970.     return (stdin);
  971. }
  972.  
  973.  
  974. /*
  975.  * Return the FILE pointer to stdout.
  976.  */
  977.  
  978. #include <stdio.h>
  979.  
  980.     FILE *
  981. igetstdout_ ()
  982. {
  983.     return (stdout);
  984. }
  985.  
  986.  
  987. /*
  988.  * Return the FILE pointer to stderr.
  989.  */
  990.  
  991. #include <stdio.h>
  992.  
  993.     FILE *
  994. igetstderr_ ()
  995. {
  996.     return (stderr);
  997. }
  998.  
  999.  
  1000. Note that always use "+ppu" for f77 compilations; you will need
  1001. to remove the trailing '_' on the C routines if you don't.
  1002.  
  1003. I have (cross-)posted this to comp.sys.hp.
  1004. -- 
  1005. What are the chances that any HP computer system will ever "work" properly?
  1006.  ... and Slim just left town. -*- Mike Peterson, SysAdmin, U/Toronto Chemistry
  1007.  
  1008. -----------------------------
  1009.  
  1010. From: Tim Evans <tkevans@eplrx7.es.dupont.com>
  1011. Subject: Re: Searching for E-mail package
  1012. Date: 17 Nov 92 17:00:53 GMT
  1013. To:       info-unix@sem.brl.mil
  1014.  
  1015. karl@BofA.com (Karl Nicholas) writes:
  1016.  
  1017. >In article <BxMtso.Ipz@beach.csulb.edu> kumeda@beach.csulb.edu (ANDY KUMEDA) writes:
  1018. >>
  1019. >>
  1020. >>
  1021. >>We are currently searching for E-mail/Office Automation packages that will
  1022. >>serve several thousand users based on the following criteria:
  1023. >>
  1024. >>  1) Must support X-Window (OpenLook or Motif) either through an X-terminal
  1025. >>     or a PC running an X-server.
  1026. >>  2) Must also support PCs running DOS, with a TCP/IP network connection.
  1027. >>  3) In addition, a non-X version (character-based -- ASCII terminals) is 
  1028. >>     preferable, but not required.
  1029. >>  4) Must be able to 'customize' -- ie original text to be replied or
  1030. >>     forwarded should not be modifiable.
  1031. >>  5) Must support SMTP.
  1032. >>  6) Vendor must have good technical support.  
  1033. >>
  1034.  
  1035. >    I don;t know all the answers to the questions here, 
  1036. >but you should call the cc-mail people. no I do not know the
  1037. >phone number either, sorry, but cc-mail is the name of the
  1038. >product. What do I know? well ...
  1039.  
  1040. cc:Mail is only made by Lotus.  You know, that unknown 1-2-3 company.
  1041. -- 
  1042. Tim Evans                     |    E.I. du Pont de Nemours & Co.
  1043. tkevans@eplrx7.es.dupont.com  |    Experimental Station
  1044. (302) 695-9353/7395           |    P.O. Box 80357
  1045. EVANSTK AT A1 AT ESVAX        |    Wilmington, Delaware 19880-0357
  1046.  
  1047. -----------------------------
  1048.  
  1049. From: Ioi Kim Lam <ioi@pixmap.seas.upenn.edu>
  1050. Subject: C++ Debugger with Motif
  1051. Date: 17 Nov 92 14:16:28 GMT
  1052. Sender: Ford WDL <Uwdl1@atherton.com>
  1053. To:       info-unix@sem.brl.mil
  1054.  
  1055.  
  1056. I am using X11R4 on the SunOS. I am writing Motif programs in C++, using the
  1057. GNU compiler g++. Does anyone know how to debug these programs. I tried
  1058. gdb-3.2 and gdb-3.5 but they don't seem to understand the C++
  1059. function-name convention. Gdb-4.4 gives an segmentation fault with the
  1060. Motif program, although it can debug normal C++ programs under Unix. I
  1061. tried UPS but it always shows the header file instead of the source file. 
  1062.  
  1063. Are there any public-domain X-Debugger available that can support C++?
  1064.  
  1065. Please reply to ioi@eniac.seas.upenn.edu
  1066.  
  1067. Thank you in advance.
  1068.  
  1069. -----------------------------
  1070.  
  1071. From: Stephen Daedalus <farrar@adaclabs.com>
  1072. Subject: Re: Looking for Time Series Analysis software
  1073. Date: 17 Nov 92 16:56:04 GMT
  1074. Sender: Stephen Daedalus <farrar@firewall>
  1075. Nntp-Posting-Host: 192.153.52.178
  1076. To:       info-unix@sem.brl.mil
  1077.  
  1078. You might take a look at TSP, which runs on mainframes to PC's.  We used the
  1079. student version in one of my econometrics classes and, although limited, did
  1080. a very good job on the project, and kept me out of the comp. lab. 
  1081. ---
  1082. Richard Farrar        These views are my own, not my company's or country's.
  1083. ADAC Laboratories    "A man without hand is not a man."
  1084. farrar@adaclabs.com        - George Costanza, Seinfeld
  1085.         Spam is a registered trademark of Hormel
  1086.  
  1087. -----------------------------
  1088.  
  1089. From: Fiona Wong <a1001032@cdf.toronto.edu>
  1090. Subject: Re: file .fingerees
  1091. Date: 17 Nov 92 17:51:59 GMT
  1092. Sender: news@cdf.toronto.edu
  1093. Nntp-Posting-Host: eddie.cdf
  1094. To:       info-unix@sem.brl.mil
  1095.  
  1096. In article <Nov.17.08.56.40.1992.16495@gnumath.rutgers.edu> lukeh@gnumath.rutgers.edu (Luke Higgins) writes:
  1097. >
  1098. >I have found a program which attempts to execute a file when you are
  1099. >fingered and I am having problems getting it to work.  My problem is
  1100. >that on my system I can't seem to find the .fingerees file.  Is this
  1101. >a standard unix file and if so how do I go about finding it.
  1102.  
  1103. make it by yourself. :-)
  1104.  
  1105. >    Thanks
  1106. >    Luke  (a computer novice  to say the least)
  1107.  
  1108.  
  1109. -- 
  1110. |       ____                    | You know you've been spending too much time |
  1111. |      /    . __   __   __      | on the computer when your friend misdatess  |
  1112. |     /--- / /  ) /  ) ___)     | a check, and you suggest adding a "++" to   |
  1113. |____/    / (__/ /  / (__(______|_fix it._____________________________________|
  1114.  
  1115. -----------------------------
  1116.  
  1117. From: Pete Hardie <phardie@nastar.uucp>
  1118. Subject: Re: BIG IMPORTANT QUESTION PLEEEEZE HELP ME!!!!!
  1119. Date: 17 Nov 92 14:45:36 GMT
  1120. To:       info-unix@sem.brl.mil
  1121.  
  1122. In article <1992Nov14.220251.9739@umbc3.umbc.edu> rouben@math9.math.umbc.edu (Rouben Rostamian) writes:
  1123. >In article <Bxq5x7.L2p@unix.amherst.edu> twpierce@unix.amherst.edu (Tim Pierce) writes:
  1124. >>My car's making a funny noise somewhere under the hood.  It's one of
  1125. >>these cheapo models, though, and it doesn't have pull-down help from
  1126. >>under the visor available!!!  Can anyone tell me what it's doing
  1127. >>wrong!!!!
  1128. >
  1129. >Switch to emacs and go into the overdrive mode.
  1130.  
  1131. Shouldn't that be 'drive-over' mode?
  1132.  
  1133.  
  1134. -- 
  1135. Pete Hardie:  phardie@nastar  (voice) (404) 497-0101
  1136. Digital Transmission Systems, Inc., Duluth GA
  1137. Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection" 
  1138. Position:  Goalie               |
  1139.  
  1140. -----------------------------
  1141.  
  1142. From: 25235-gokhman <esg@pyuxd.uucp>
  1143. Subject: Shortened repost: mmap over NFS problem
  1144. Keywords: Does mmap with MAP_SHARED work for write over NFS ?
  1145. Date: 17 Nov 92 18:54:22 GMT
  1146. Sender: USENET System Software <netnews@porthos.cc.bellcore.com>
  1147. To:       info-unix@sem.brl.mil
  1148.  
  1149. Hi:
  1150.  
  1151. This is a (shortened) repost of an article for which I got no responses. Writing
  1152. to a memory region allocated with mmap call using MAP_FILE and
  1153. MAP_SHARED causes a segmentation fault (RS6000 under AIX 3.2) when
  1154. it is done over NFS. Mapping to the same file locally works fine.
  1155. Documentation, as far as I can tell, does not mention
  1156. NFS as a limitation. Is mmap supposed to work over NFS and this is an AIX
  1157. bug, or is it not supposed to work and it is a documentation problem ?
  1158.  
  1159.             Thanx in advance, Ed Gokhman
  1160.  
  1161. -----------------------------
  1162.  
  1163. From: Ruurd van der Meer <rvdm@oce.nl>
  1164. Subject: Sun Printserver? IPX-stack available ? NCP documentation ?
  1165. Date: 16 Nov 92 11:28:19 GMT
  1166. Sender: USENET News System <news@oce.nl>
  1167. Originator: rvdm@st33-sys4
  1168. To:       info-unix@sem.brl.mil
  1169.  
  1170. I want to have a printserver on a Sun SParc (SunOS 4.1.x, in future Solaris) 
  1171. for a Novell environment.  So I have some questions:
  1172.  
  1173. Does anybody know if such a product exists ? If not:
  1174.  
  1175. Is there an IPX protocol stack on a Sun SParc available, commercial or public 
  1176. domain ? If this is in the form of a Netware shell as in DOS, what about
  1177. a C-interface for it (to write a printserver)? 
  1178.  
  1179. And what about the NCP protocol of Novell? Is this available somewhere ?
  1180.  
  1181. Please direct answers to
  1182.  
  1183. rvdm@oce.nl
  1184.  
  1185. If I have collected the answers I will put them back into the newsgroups.
  1186.  
  1187.       ###########################################################
  1188.       #  This note does not necessarily represent the position  #
  1189.       #     of Oce-Nederland B.V. Therefore no liability or     #
  1190.       #      responsibility for whatever will be accepted.      #
  1191.       ###########################################################
  1192.  
  1193. -----------------------------
  1194.  
  1195. From: Matz Engstrom <gucme@gdunix.gd.chalmers.se>
  1196. Subject: Tool for email, and snail mail addresses
  1197. Date: 17 Nov 92 19:11:00 GMT
  1198. Sender: Matz Engstrom <gucme@gdunix.gd.chalmers.se>
  1199. To:       info-unix@sem.brl.mil
  1200.  
  1201. I am interested in a UNIX tool for keeping my
  1202. addressbook, both electronic and snailmail. I
  1203. store them as VM NAMES files today, which also
  1204. gives me the possibility to store phone numbers,
  1205. and free text notes about the addressee.
  1206.  
  1207. Do you know of any UNIX tools for that, including
  1208. a fullscreen interface to maintain the files,
  1209. and some extracting tools to make the email
  1210. addresses available to my mail tools?
  1211. -- 
  1212. H{lsningar (Sincerely) /
  1213.           Matz Engstrom, Gothenburg Universities' Computing Centre;
  1214.           Address Box 19070; Kapellg}ngen 5; S-400 12 Gothenburg; Sweden
  1215.           Phone +46 31 818 338; Fax +46 31 185 006;
  1216.  
  1217. -----------------------------
  1218.  
  1219. From: "Michael S. McLean" <msm@eng.ufl.edu>
  1220. Subject: Re: Changing the owner of a process
  1221. Keywords: process owner
  1222. Date: 17 Nov 92 20:08:13 GMT
  1223. Sender: "Michael S. McLean" <msm@mailbox.eng.ufl.edu>
  1224. To:       info-unix@sem.brl.mil
  1225.  
  1226. In article <1992Nov17.142837.21252@dale.ksc.nasa.gov>, eposnak@dale.ksc.nasa.gov (Ed Posnak) writes:
  1227. |> 
  1228. |> What I was looking for was something along the lines of how to change the 
  1229. |> effective user id of a process who's source I may not be able to modify, by 
  1230. |> some other means, e.g. from another process.  Many suggested writing a device
  1231. |> driver or system call to do this.  Here is one answer along those lines. 
  1232. |> ---
  1233. |> 
  1234. |> This is one of those dirty tricks I've always wanted to get around to
  1235. |> figuring out a way to do... (without kernel source, that is)
  1236. |> 
  1237. |> I believe it could be done by writing a device driver. Open the device
  1238. |> driver and write commands to it, and it does the dirty work. For
  1239. |> instance, send it 8 bytes containing the process to change and the uid
  1240. |> to change it to.
  1241.  
  1242. There is no need to write another device driver for this.  /dev/kmem will
  1243. suffice.
  1244.  
  1245. -- 
  1246. Michael S. McLean (msm@eng.ufl.edu)                
  1247. Engineering Computing Systems             "Imagination is the one weapon
  1248. College of Engineering                     in the war against reality."
  1249. University of Florida                         -- Jules de Gaultier
  1250.  
  1251. -----------------------------
  1252.  
  1253. From: Artur Romao <artur@morgaine.puug.pt>
  1254. Subject: I need some pic-like thing
  1255. Keywords: pic
  1256. Date: 17 Nov 92 15:19:19 GMT
  1257. Sender: USENET News System <news@puug.pt>
  1258. Followup-To: comp.unix.questions
  1259. To:       info-unix@sem.brl.mil
  1260.  
  1261.  
  1262. Hello, net!
  1263.  
  1264. I need to build some docs, and some of the stuff needs pic. I know
  1265. it isn't public domain (or am I wrong?), so what I would like was
  1266. to find something that does the work, but available in the public domain.
  1267.  
  1268. Is there any such thing. 
  1269.  
  1270. Thanks in advance for any info.
  1271.  
  1272. BTW, are theese the right groups to ask this kind of questions. Please
  1273. adress me to the apropriate ones if not.
  1274.  
  1275. Best regards,
  1276.  
  1277.  .........................................................................
  1278. Artur M. P. Romao : PUUG - Grupo Portugues de Utilizadores do Sistema UNIX
  1279. artur@puug.pt     : Av. 24 de Julho, 134 - 7.
  1280. +351 (1) 3950642  : P-1300 LISBOA - PORTUGAL
  1281.  .................:.......................................................
  1282.  
  1283. -----------------------------
  1284.  
  1285. From: Eduardo Rodriguez <erodrigu@dcc.uchile.cl>
  1286. Subject: Re: C Source Code for Pattern Matching
  1287. Keywords: text pattern matching source
  1288. Date: 17 Nov 92 22:11:25 GMT
  1289. Sender: Network News <usenet@dcc.uchile.cl>
  1290. Originator: erodrigu@tortel
  1291. To:       info-unix@sem.brl.mil
  1292.  
  1293.  
  1294. In article <leb.721935245@edgar>, leb@edgar.Jpl.Nasa.Gov (Larry Bright) writes:
  1295. > Could anyone tell me where I could find C source code for some
  1296. > simple text pattern matching s/w, preferably with a syntax and
  1297. > semantics based on "regular expressions" as in grep, awk, sed, etc.
  1298. > Anything that implements a non-trivial subset of these functions
  1299. > would be useful.
  1300.  
  1301. The agrep package (approximate pattern matching) has many of the grep functions
  1302. and other stuff besides.  You can pick it up from cs.arizona.edu using
  1303. anonymous ftp.
  1304. Regards,
  1305.     Edo...
  1306.  
  1307.  ////                                ```\                             .
  1308.  c-OO  Is there something that       OO-c     erodrigu@dcc.uchile.cl  .
  1309.     \  hurt you?                     /      Dpto Cs de la Computacion .
  1310.    -                    Ya... Pain    -        Universidad de Chile   .
  1311.  
  1312. -----------------------------
  1313.  
  1314. From: Paul Prescod <papresco@undergrad.math.waterloo.edu>
  1315. Subject: Re: IS UNIX DEAD? (long)
  1316. Keywords: n
  1317. Date: 18 Nov 92 01:32:12 GMT
  1318. To:       info-unix@sem.brl.mil
  1319.  
  1320. >and will probably miss the end:
  1321. >
  1322. >I disagree.  Not having used too many OS's, I can only recall 2 
  1323. >that the help command did something.  Vax VMS, and Microsoft Dos 5.
  1324. >I take that back, i just thought of Wylbur/MVSX, and VM/CMS.  I believe
  1325. >help does something on those systems.  
  1326.  
  1327. Add in OS/2 and (I believe) AmigaDOS.  Plus many, many, many, command 
  1328. line oriented programs that are not operating systems like symbolic
  1329. math packages and graphing packages.  Plus every text mode adventure
  1330. game.    
  1331. >
  1332. >Why should help do something at the command prompt?  I would much, much
  1333. >rather have the hardcopy manual in my hand.  While online help might
  1334. >be nice, I really just do not see its absence as an inherent flaw.
  1335.  
  1336. You think the average university should issue everyone textual manuals?
  1337.  
  1338. Especially for the huge mass of files that come with Unix???
  1339.  
  1340. And what about when those files change?
  1341.  
  1342. -----------------------------
  1343.  
  1344. From: Mike Leibensperger <mjl@bos.locus.com>
  1345. Subject: Re: BIG IMPORTANT QUESTION PLEEEEZE HELP ME!!!!!
  1346. Date: 16 Nov 92 22:12:51 GMT
  1347. Sender: Netnews <news@locus.com>
  1348. To:       info-unix@sem.brl.mil
  1349.  
  1350.  
  1351.    In article <Bxq5x7.L2p@unix.amherst.edu> twpierce@unix.amherst.edu
  1352.    (Tim Pierce) writes:
  1353.  
  1354.    >My car's making a funny noise somewhere under the hood.  It's one of
  1355.    >these cheapo models, though, and it doesn't have pull-down help from
  1356.    >under the visor available!!!  Can anyone tell me what it's doing
  1357.    >wrong!!!!
  1358.  
  1359. Hey Tim!  I think I know what you're (*smirk*) DRIVING at!!!  ;-)  ;-)  ;-)
  1360.  
  1361. Listen up, gang!  Tim thinks maybe if you Read The Fine Manual you
  1362. might fair better with some of these questions!!!  What a Fine idea!
  1363. Or, as we net.czars say, WAFI!
  1364.  
  1365. In article <Bxq9zu.J6o@cs.dal.ca> franklin@ug.cs.dal.ca (Steve
  1366. Franklin) writes:
  1367.  
  1368.    Wrong group Timbo... This is comp.unix.questions, not 
  1369.    comp.eunuchs.questions. Try again, and this time read your damn warning
  1370.    when you post (are you REALLY REALLY sure you wanna do this?)
  1371.       steve
  1372.  
  1373. Hey Steve-a-rino!  Maybe your fine manual is floating up in the air,
  1374. near the AC duct in the ceiling!  You'll have to (*smirk*) LIGHTEN UP
  1375. if you want to grab it and read it!
  1376.  
  1377.     Too wise for his own good,
  1378.     mjl
  1379. --
  1380. Michael J. Leibensperger      "Rats and roaches live by competition under the
  1381. Locus Computing/Boston         laws of supply and demand; it is the privilege
  1382. 25 Mall Road; Burlington MA         of human beings to live under the laws of
  1383. 01803 (617)229-4980 mjl@locus.com       justice and mercy."  -- Wendell Berry
  1384. Member of the League for Programming Freedom --- write league@prep.ai.mit.edu
  1385.  
  1386. -----------------------------
  1387.  
  1388. From: fred j mccall 575-3539 <mccall@mksol.dseg.ti.com>
  1389. Subject: Re: IS UNIX DEAD? (long)
  1390. Date: 17 Nov 92 21:17:47 GMT
  1391.  
  1392. hacktic.nl>
  1393. To:       info-unix@sem.brl.mil
  1394.  
  1395. In <1992Nov11.223946.411@global.hacktic.nl> peter@global.hacktic.nl (Peter Busser) writes:
  1396.  
  1397. >sherman@unx.sas.com (Chris Sherman) writes:
  1398.  
  1399. >>In <1992Nov6.113324.6348@global.hacktic.nl> peter@global.hacktic.nl (Peter Busser) writes:
  1400.  
  1401.  
  1402. >>>user interfaces. With NT or OS/2 you only need to learn only *1* user
  1403. >>>interface.
  1404.  
  1405. >>Suppose you don't like it...
  1406.  
  1407. >Then you're stuck with it. But then at least you're stuck consistently... :-)
  1408.  
  1409. Yes, and all cars should look like an EDSEL.  ;-)
  1410.  
  1411. -- 
  1412. "Insisting on perfect safety is for people who don't have the balls to live
  1413.  in the real world."   -- Mary Shafer, NASA Ames Dryden
  1414.  ------------------------------------------------------------------------------
  1415. Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
  1416.  
  1417. -----------------------------
  1418.  
  1419. From: Mike O'Connor <mjo@slee01.srl.ford.com>
  1420. Subject: Re: tcsh-like subroutine
  1421. Date: 18 Nov 92 00:14:47 GMT
  1422. NNTP-Posting-Host: slee01.srl.ford.com
  1423. To:       info-unix@sem.brl.mil
  1424.  
  1425. In article <BxtGt9.FDq@newcastle.ac.uk> Karl.Glazebrook@durham.ac.uk writes:
  1426.  
  1427. :I'm looking for a tcsh like input routine which would be callable from a C or
  1428. :FORTRAN program. I just want to be able to read a line of text from the user
  1429. :with tcsh-like (or emacs-like!) command line editing/recall features.
  1430.  
  1431. You need the GNU readline library or a clone of the GNU readline
  1432. library.  The GNU stuff is FTPable at prep.ai.mit.edu:/pub/gnu...
  1433.  
  1434.                         ...Mike
  1435.  
  1436. --
  1437.  Michael J. O'Connor           |  Internet:  mjo@FMSRL7.SRL.FORD.COM
  1438.  Ford Motor Company, OPEO      |  UUCP:      ...!{backbone}!fmsrl7!mjo
  1439.  20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
  1440.  Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277
  1441.  
  1442. -----------------------------
  1443.  
  1444. From: Tim Ramsey <tar@math.ksu.edu>
  1445. Subject: Re: Changing the owner of a process
  1446. Keywords: process owner
  1447. Date: 18 Nov 92 01:40:58 GMT
  1448. Followup-To: comp.unix.internals
  1449. NNTP-Posting-Host: hilbert.math.ksu.edu
  1450. To:       info-unix@sem.brl.mil
  1451.  
  1452. [ Followups set to comp.unix.internals ]
  1453.  
  1454. msm@eng.ufl.edu (Michael S. McLean) writes:
  1455.  
  1456. >There is no need to write another device driver for this.  /dev/kmem will
  1457. >suffice.
  1458.  
  1459. You can do it by poking about in /dev/kmem, but it's not safe.  Consider:
  1460.  
  1461. Process A                     Process B               Process C
  1462. Open /dev/kmem                <runs>
  1463. Find B proc table entry       <runs>
  1464. Update proc table entry       <exits>                 <starts up>
  1465.  
  1466. Between the time when Process A locates the proc table entry for Process B
  1467. and the time that it updates the entry, Process B exits and Process C is
  1468. started -- and given Process B's old table entry.  You end up updating
  1469. the wrong process.
  1470.  
  1471. -- 
  1472.     Tim Ramsey, 913.532.6750  |  I'm a sysadmin and I'm okay;
  1473.     Department of Mathematics |  I work all night and I sleep all day.
  1474.     Kansas State University   |
  1475.  
  1476. -----------------------------
  1477.  
  1478. From: Paul Prescod <papresco@undergrad.math.waterloo.edu>
  1479. Subject: Re: IS UNIX DEAD (long)
  1480. Date: 18 Nov 92 01:50:24 GMT
  1481. To:       info-unix@sem.brl.mil
  1482.  
  1483. >
  1484. > It isn't a question of preservation of case sensetivity; it is a
  1485. >question of teaching the kernel about case insensetivity. Right now,
  1486. >the kernel doesn't know anything about the character set you (or
  1487. >anyone else on the system) is using; all it knows about are two
  1488. >special 8-bit blobs, one for 'end of filepath' and another for
  1489. >'filepath sepperator'. If you teach it about case insensetivity,
  1490. >it is now working in whatever character set you chose, and people
  1491. >who wish to use it with other ones are out of luck.
  1492.  
  1493. Am I to understand that unix file management is in the "kernel" and can
  1494. not be intercepted before and after kernel operations?  Even DOS seperates
  1495. the file system and kernel enough that you can use stacker or something
  1496. between the files system and the kernel.
  1497.  
  1498. -----------------------------
  1499.  
  1500. From: "Sheetal V. Kakkad" <svkakkad@cs.utexas.edu>
  1501. Subject: rexec does not search for ~/.netrc file
  1502. Keywords: rexec, netrc
  1503. Date: 17 Nov 92 22:29:42 GMT
  1504. NNTP-Posting-Host: boogie.cs.utexas.edu
  1505. To:       info-unix@sem.brl.mil
  1506.  
  1507. I am trying to use rexec(3N) on a Sun SparcStation to start a server
  1508. on a remote host (also a Sun SparcStation). The synopsis of the call
  1509. (as given in the man page) is:
  1510.  
  1511. SYNOPSIS
  1512.      rem = rexec(ahost, inport, user, passwd, cmd, fd2p);
  1513.      char **ahost;
  1514.      u_short inport;
  1515.      char *user, *passwd, *cmd;
  1516.      int *fd2p;
  1517.  
  1518. Here's the relevant portion of the description from the man page:
  1519.  
  1520. DESCRIPTION
  1521.     ...
  1522.      If  a  username  and password are both specified, then these
  1523.      are used to authenticate to the foreign host; otherwise  the
  1524.      environment  and  then  the  user's  .netrc file in his home
  1525.      directory are searched for appropriate information.  If  all
  1526.      this fails, the user is prompted for the information.
  1527.     ...
  1528.  
  1529. Now, I have a .netrc file in my home directory which has lines of the
  1530. following form, one line for each foreign host:
  1531.  
  1532. machine machinename login mylogin password mypassword
  1533.  
  1534. Here's how I call rexec in my program (I have also shown some other
  1535. relevant variables used in the call):
  1536.  
  1537. int port;    /* set using getservent ("exec", "tcp") call */
  1538. char *rhost;    /* set to the foreign host name */
  1539. char *srvr;    /* set to full path name of my server */
  1540.  
  1541. s = rexec (&rhost, port, (char *) NULL, (char *) NULL, 
  1542.        srvr, (char *) NULL);
  1543.  
  1544. Even though I have the .netrc file set up in my home directory, the
  1545. call still prompts me for the username and password.
  1546.  
  1547. My question is: Am I doing something wrong here, or is this a commonly
  1548. known bug? Any pointers will be appreciated.
  1549.  
  1550. My machine is a SparcStation ELC running SunOS 4.1.2. All the remote
  1551. hosts (where I am trying to start up my server) are SparcStation 1's
  1552. also running SunOS 4.1.2.
  1553.  
  1554. Thanks in advance,
  1555.  
  1556. - Sheetal
  1557.  
  1558. Note: Follow-up set to comp.sys.sun.misc.
  1559.  
  1560.  ----------------------------------------------------------------------
  1561. Sheetal V. Kakkad    svkakkad@cs.utexas.edu    Office: (512) 471-9586
  1562. Dept of Computer Sciences, UT-Austin        Home:   (512) 450-1756
  1563. ======================================================================
  1564.  
  1565. -----------------------------
  1566.  
  1567. From: Paul Prescod <papresco@undergrad.math.waterloo.edu>
  1568. Subject: Re: IS UNIX DEAD?
  1569. Date: 18 Nov 92 02:35:41 GMT
  1570. To:       info-unix@sem.brl.mil
  1571.  
  1572. >>Because that often saves (a lot of) money.
  1573. >
  1574. >I doubt it. If you insist to install the OS yourself then you better
  1575. >start learning how manage it.
  1576.  
  1577. No, no, no, no, no....OS/2, Windows, DOS etc. have PROVED that you don't
  1578. have to be a system administrator to install an OS.  Why do you insist on
  1579. this dogma "if you aren't computer literate enough to install Unix, you
  1580. should pay someone to do it."  Why not make unix easy enough to install
  1581. that you don't have to do either?  Why force the problem onto the user 
  1582. instead of just FIXING it?  Why defend a flaw?  
  1583.  
  1584. I won't defend Dos, or windows' or OS/2s' flaws.  I will highlight their
  1585. strong points.  Highlight unixes' strong points, but FIX IT'S FLAWS.
  1586.  
  1587. Overly complex installation is a flaw.
  1588.  
  1589. -----------------------------
  1590.  
  1591. From: Paul Prescod <papresco@undergrad.math.waterloo.edu>
  1592. Subject: Re: IS UNIX DEAD? (very long)
  1593. Date: 18 Nov 92 02:30:43 GMT
  1594. To:       info-unix@sem.brl.mil
  1595.  
  1596. >Mine popped up after 45 seconds (cheap Korean brand).  In the same
  1597. >vein, my microwave doesn't ask for confirmation, my light switches
  1598. >don't ask for confirmation, and my toilet definitely does not ask
  1599. >"are you sure? (y/n)".
  1600.  
  1601. All of these are considerably easier to use then a text editor.  Many cars
  1602. will (rightly) make a sound if you leave your keys in.  They will also
  1603. (rightly) make a sound if you leave your lights on when the engine is
  1604. off.  It would be (and perhaps is, in some cars) nice if you could turn
  1605. these off.  But for my, girlfriend, who is very intelligent, but occasionally
  1606. forgets her lights and keys, the buzzers are a Godsend.  And for me, 
  1607. who can forget and type qw instead of wq, a prompt "haven't saved yet"
  1608. would be nice.  BTW, this is not asking for superflurous time wasting
  1609. prompting.  VI will NOT LET YOU QUIT with a Q.  It must be wq or Q!.  So
  1610. if I type Q, why not ask me if I meant WQ?  Easier for the user, easeir
  1611. for the power user that forgets.
  1612.  
  1613. >But then, we're arguing apples and oranges, as I said before.  You can't
  1614. >do anything useful with a Microsoft Write file except print it, as far
  1615. >as I can tell, and I haven't printed anything out in about a month.
  1616.  
  1617. Or compile it?  write can write ascii as well as VI!
  1618.  
  1619. >No, assembly is a low level language, C is my favorite programming language,
  1620. >and control-c is the de facto standard for process interruption on Unix
  1621. >systems.  The bit about kill %1 was facetious, but everyone who intends to
  1622. >use Unix seriously should have control-c pretty firmly imbedded in their
  1623. >minds.
  1624.  
  1625. process interruption is different from exit.  Exit implies "update setup
  1626. files etc., and perhaps prompt me if I want to save"  Process interruption
  1627. implies "quit unconditionally."
  1628.  
  1629. >Definitely not.  My keyboard doesn't have an F1 key.  If it did, there
  1630. >would be no guarantee that it would produce what your F1 key does.
  1631. >There are good reasons why nobody uses F-keys -- their original purpose
  1632. >was to be bindable to whatever the user felt appropriate.
  1633.  
  1634. That's fine...your keyboard doesn't have an F1 key and you don't want help.
  1635. My keyboard DOES have an F1 key, and unix doesn't have a standard F1 key.
  1636. If I want to bind F1 on my computer, having help on it doesn't matter.  Think
  1637. about it...it would be intercepted before it gets sent, and translated,
  1638. wouldn't it?  And for those of us that don't know how to bind keys yet,
  1639. it would go through to help.
  1640.  
  1641. >You mean one character left, but you're still terminally unconscious.
  1642.  
  1643. Yes...I keep saying right because I'm thinking about what hand I use to 
  1644. type it.
  1645.  
  1646. >Little bumps on the keyboard don't mandate any sort of cursor control
  1647. >arrangement whatsoever.  It makes perfect sense to not use ; for a
  1648. >control key -- it's not right of l on all keyboards, for one thing.
  1649.  
  1650. Non standard QWERTY-incompliant keyboards are certainly not my problem.
  1651. 99.9% of qwerty keyboards (and every one I have seen) has a semicolon beside
  1652. the l.  The other .1% are so nonstandard that perhaps their hjkl aren't
  1653. in a row either.
  1654.  
  1655. >It does NOT make perfect sense to have an unshifted help key in the
  1656. >middle of the goddamn keyboard in an editor people are supposed to use.
  1657. >Why don't you take some courses on human-computer interaction and
  1658. >ergonomics and try to get back to Unix later?
  1659.  
  1660. Thus the beauty of the (till now) unused F1 key.  Besides, one would
  1661. assume that VI would be configurable enough that you could change the
  1662. key mappings of the keys!  Or at least turn off help if you wanted to.
  1663.  
  1664. >I assume that you meant "if you launch an editor from RN."  Pray tell,
  1665. >how does vi figure out from where it was launched, and whether or not
  1666. >that program would necessarily need word-wrap on?  Please go on to
  1667. >inform me how you've determined that I want word-wrap when I write news --
  1668. >I don't -- and how you've managed to instantiate artificial intelligence
  1669. >on any other competing system that you're now comparing with Unix?
  1670.  
  1671. Well, in the PC world (blaspheme!!!!) you tell programs what editor you
  1672. want to use and what command line options to send to them.  And guess what
  1673. if you want to change that information, you don't have to edit some 
  1674. invisible file that the computer has (annoyingly) placed in your work
  1675. directory.  The program updates it's OWN config file.  (although you could
  1676. do it manually if you're into that kind of thing)
  1677.  
  1678. >For you, it's a flaw.  For enough other people, it's not.  Your systems
  1679. >administrator has decided not to add a file that does something at the
  1680. >prompt.  Contact him for further information.
  1681.  
  1682. I see.  For other people it is a benefit?  Can you explain how it is to 
  1683. their benefit to have help do nothing?
  1684.  
  1685. >If they were, then it would be.
  1686.  
  1687. They are.
  1688.  
  1689. >Programs do not decay.  vi is unchallenged as a small, powerful text editor;
  1690. >that it was originally written years ago is just not important.
  1691.  
  1692. B
  1693. A
  1694. A
  1695. A
  1696. yes programs DO decay.  See that crap above this line?  That's what
  1697. happens when I try to use my arrow keys.  Let's see what happens when
  1698. I try to use my f1 key?  Beep.  Where is built in help?  It's not there.
  1699.  
  1700. VI is decaying.  It is not keeping up with the hardware.  It is not keeping
  1701. up with competing software.  Anyone in their right mind given a choice
  1702. would not use vi unless they are already familiar with it (or the only
  1703. choice is emacs).  
  1704.  
  1705. Let's not let this decay happen to unix.
  1706.  
  1707. -----------------------------
  1708.  
  1709. From: Kevin Smith <kevin@shady.uucp>
  1710. Subject: Re: Overflow warnings (SCO SV3.2)
  1711. Date: 17 Nov 92 15:49:54 GMT
  1712. Followup-To: comp.unix.sysv386
  1713. To:       info-unix@sem.brl.mil
  1714.  
  1715. In article <BxnKJu.9DF@world.std.com> apl@world.std.com (Anthony P Lawrence) writes:
  1716. :>gryphon@openage.openage.com (The Golden Gryphon) writes:
  1717. :>: 
  1718. :>:cd /etc/conf/cf.d
  1719. :>:./configure
  1720. :>: 
  1721. :>:find NREGION and NFILE, and increase their size quite a bit.  I would recommend
  1722. :>:doubling them.  Then relink the kernel.  DO THIS IN SINGLE USER MODE!  Back the
  1723. :>:system up first.
  1724. :>
  1725. :>While this is certainly not bad advice, isn't backing up the system somewhat 
  1726. :>like cautioning the use of seatbelts while vacuuming the car?  All that's
  1727. :>really going to be affected is /unix.  I could see making a /unix.good, and
  1728. :>he certainly should have backups anyway, but this makes it all sound very
  1729. :>scary and system-threatening!
  1730. :>
  1731. :>What is the point of single user mode? Increasing these parameters doesn't
  1732. :>affect anything but the space in the new kernel, so how is it going to
  1733. :>cause any problems for the running system?
  1734. :>
  1735. :>Just wondering why we're being so cautious here.
  1736. :>
  1737.  
  1738. Relinking the kernal and installing the new unix automatically creates
  1739. /unix.old.  This is fine unless you screw up the kernel twice in a row
  1740. and have nothing to boot.  This is where the /unix.good can save the day.
  1741. I always create a /unix.good from a known, working, kernel.  It, however,
  1742. does not have to always be the latest one, just one that will boot.
  1743.  
  1744. Single user mode is important because 'ps' may not run with the new
  1745. kernel (without '-n /unix.old'), which may, in turn, cause shutdown to
  1746. hang or not shut everything down.  Many applications (ingres...) use
  1747. ps to find their daemons and servers and so may not terminate properly.
  1748. -- 
  1749.         | Email - !shady!kevin uunet!shady!kevin
  1750. Kevin Smith | Voice - (908) 874-7980
  1751.         | Mail  - ShadeTree Software, Inc., 192 Capricorn Dr. #10,
  1752.         |         Somerville, NJ  08876
  1753.  
  1754. -----------------------------
  1755.  
  1756. From: Narendra Bhandari <nbhandar@enws241.eas.asu.edu>
  1757. Subject: CURSES - No delay option, SunOS 4.1.1
  1758. Date: 18 Nov 92 03:30:30 GMT
  1759. Sender: USENET News System <news@ennews.eas.asu.edu>
  1760. To:       info-unix@sem.brl.mil
  1761.  
  1762.  
  1763. Is there a nodelay function in curses.
  1764.  
  1765. I am using SunOS 4.1.1.( I have used one on SVR4).
  1766.  
  1767. If not , is there any other technique of 
  1768.  
  1769. Non-blocking character input from Keyboard.
  1770.  
  1771.  
  1772. -- 
  1773.       ...........................................................
  1774.       .  Narendra Bhandari             nbhandar@cs.eas.asu.edu    .
  1775.       .  950 S Terrace Road, #D366     602.921.3401(Home)    .
  1776.       .  Tempe, AZ 85281        602.965.1780(Work)    .
  1777.  
  1778. -----------------------------
  1779.  
  1780. From: Paul_Dineen <pld@fc.hp.com>
  1781. Subject: Re: lib77 "flush" call. Where is it in UNIX?
  1782. Date: 17 Nov 92 23:31:11 GMT
  1783. Sender: Notes Administrator <news@fc.sde.hp.com>
  1784. X-Newsreader: TIN [version 1.1.4 PL6]
  1785. To:       info-unix@sem.brl.mil
  1786.  
  1787. : You can write a "flush" that calls "fflush" (which is a standard C
  1788. : routine, and you should have a man page for it). You will need to use the
  1789. : HP-UX 'fstream' routine to map the FORTRAN unit number to a C stream number.
  1790.  
  1791.   Note that 'fstream' is a FORTRAN routine, rather than an HP-UX routine.
  1792.  
  1793. -----------------------------
  1794.  
  1795. From: Tim Pierce <twpierce@unix.amherst.edu>
  1796. Subject: Re: IS UNIX DEAD? (long)
  1797. Keywords: n
  1798. Date: 18 Nov 92 03:57:30 GMT
  1799. To:       info-unix@sem.brl.mil
  1800.  
  1801. In article <Bxw1Lp.CwH@undergrad.math.waterloo.edu> papresco@undergrad.math.waterloo.edu (Paul Prescod) writes:
  1802.  
  1803. >>I take that back, i just thought of Wylbur/MVSX, and VM/CMS.  I believe
  1804. >>help does something on those systems.  
  1805. >
  1806. >Add in OS/2 and (I believe) AmigaDOS.  Plus many, many, many, command 
  1807. >line oriented programs that are not operating systems like symbolic
  1808. >math packages and graphing packages.  Plus every text mode adventure
  1809. >game.    
  1810.  
  1811. Which, as we all know, collectively constitute the zenith of software
  1812. development.  It is doubtful that any modern operating system could
  1813. succeed that was not modeled after a text adventure.  I can see it now
  1814.  ...
  1815.  
  1816. amhux3% hello sailor
  1817.  
  1818. -- 
  1819. ____ Tim Pierce                / 
  1820. \  / twpierce@unix.amherst.edu /               Rocks say goodbye.
  1821.  \/ (BITnet: TWPIERCE@AMHERST) / 
  1822.  
  1823. -----------------------------
  1824.  
  1825. From: Thomas Richard Stevenson <tom@uts.cc.wayne.edu>
  1826. Subject: Re: What full-screen file managers are there?
  1827. Date: 17 Nov 92 23:35:49 GMT
  1828. To:       info-unix@sem.brl.mil
  1829.  
  1830. mandel@litp.ibp.fr (Arnaldo MANDEL) writes:
  1831.  
  1832. >In article <1992Nov16.223340.15353@mccc.edu> pjh@mccc.edu (Pete Holsberg) writes:
  1833.  
  1834. >> In article <1e4mbcINN1kh@crcnis1.unl.edu> pkramer@unlinfo.unl.edu (Paul Kramer) writes:
  1835. >> =Hello,
  1836. >> =
  1837. >> =I found while reading articles in this electronic conference, a 
  1838. >> =reference to a public-domain program called utree.  It is full-screen 
  1839. >> =file manager which allows you to perform file functions with single 
  1840. >> =keystrokes.  For example, after I start the program I see a screen 
  1841. >> =that lists the files on my account.  If I want to delete one of those 
  1842. >> =files I move the cursor on top of it, press a certain key.  Boom it 
  1843. >> =gone!  
  1844. >> =
  1845. >> =Well I am wondering:  Is there anything better than utree?  I am aware
  1846. >> =of a program called 'maint' but it doesn't have the full functionality
  1847. >> =of 'utree'.
  1848.  
  1849. >> I prefer HDSCAN.
  1850.  
  1851. >Better go all the way and get emacs, with tree-dired.  You not only get all
  1852. >funtions most file managers execute, but you can add some of your own.  And
  1853. >then, this would be just the beginning of using emacs for almost everything,
  1854. >instead of hundreds of little frozen utilities.
  1855. >--
  1856. >............................................................
  1857. >Arnaldo Mandel   ---  am@ime.usp.br
  1858. >Temporarily: mandel@litp.ibp.fr
  1859.  
  1860. If you are going to install emacs and you have X-terminals, also think
  1861. about epoch. I just installed it today, and it's great!
  1862. -- 
  1863.      ____  __   __       Tom@UTS.CC.Wayne.Edu
  1864.       /   /_/  /_        Thomas_Richard_Stevenson@MTS.CC.Wayne.Edu
  1865.      /.  /\ . __/.       Tom@CMS.CC.Wayne.Edu
  1866.                          UserTom@WayneMTS.Bitnet
  1867.  
  1868. -----------------------------
  1869.  
  1870.  
  1871. End of INFO-UNIX Digest
  1872. ***********************
  1873.