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

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!lhc!adm!news
  2. From: postmaster@starlab.csc.com (SMTP MAILER)
  3. Newsgroups: comp.unix.questions
  4. Subject: Mail not delivered yet, still trying
  5. Message-ID: <34242@adm.brl.mil>
  6. Date: 23 Nov 92 22:20:03 GMT
  7. Sender: news@adm.brl.mil
  8. Lines: 575
  9.  
  10.  
  11.  ----Mail status follows----
  12. Have been unable to send your mail to <DGRAY@STARLAB.CSC.COM>,
  13. will keep trying for a total of eight days.
  14. At that time your mail will be returned.
  15.  
  16.  ----Transcript of message follows----
  17. Date: 22 Nov 92 03:27:00 EST
  18. From: INFO-UNIX@BRL.MIL
  19. Subject: INFO-UNIX Digest  V17#008
  20. To: "DGRAY" <DGRAY@STARLAB.CSC.COM>
  21.  
  22. Return-Path: <info-unix-request@sem.brl.mil>
  23. Received: from SEM.BRL.MIL by milo.starlab.csc.com with SMTP ; 
  24.           Sun, 22 Nov 92 03:19:06 EST
  25. Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa25264; 21 Nov 92 7:23 EST
  26. Received: from sem.brl.mil by SEM.BRL.MIL id aa25030; 21 Nov 92 7:05 EST
  27. Date:       Sat, 21 Nov 92 07:04:42 EST
  28. From:       The Moderator (Mike Muuss) <Info-Unix-Request@BRL.MIL>
  29. To:         INFO-UNIX@BRL.MIL
  30. Reply-To:   INFO-UNIX@BRL.MIL
  31. Subject:    INFO-UNIX Digest  V17#008
  32. Message-ID:  <9211210705.aa25030@SEM.BRL.MIL>
  33.  
  34. INFO-UNIX Digest          Sat, 21 Nov 1992              V17#008
  35.  
  36. Today's Topics:
  37.                              UNIX Training
  38.               where no vi has gone before...? (CORRECTION)
  39.   Tutorials - nine topics (12/7, San Jose)  Sun User Group Conference
  40.                           tcsh-like subroutine
  41.                            Re: IS UNIX DEAD?
  42.                         Re: IS UNIX DEAD (long)
  43.                       Adoptation of Unix in Europe
  44.              Re: Looking for Time Series Analysis software
  45.              Re: What full-screen file managers are there?
  46.                      Re: SCO TCPIP >9 LOGINS AGAIN
  47.                          Unlocking named pipes
  48.                                 Re: grep
  49.                               FSCK command
  50.                        pwd: getwd: can't open ..?
  51.              Re: What full-screen file managers are there?
  52.                 lib77 "flush" call. Where is it in UNIX?
  53.                            Re: Wait for child
  54.                       Re: name of file descriptor
  55.                                 Re: talk
  56.                   Re: Changing the owner of a process
  57.                             file .fingerees
  58.          Re: Whence Unix? (was Re: IS UNIX DEAD?) (New Thread?)
  59.                        Curses support under DOS?
  60.                             MPE, NS, TCP/IP
  61.               Re: lib77 "flush" call. Where is it in UNIX?
  62.                     Re: Searching for E-mail package
  63.                         C++ Debugger with Motif
  64.              Re: Looking for Time Series Analysis software
  65.                           Re: file .fingerees
  66.             Re: BIG IMPORTANT QUESTION PLEEEEZE HELP ME!!!!!
  67.                 Shortened repost: mmap over NFS problem
  68.        Sun Printserver? IPX-stack available ? NCP documentation ?
  69.                 Tool for email, and snail mail addresses
  70.                   Re: Changing the owner of a process
  71.                        I need some pic-like thing
  72.                  Re: C Source Code for Pattern Matching
  73.                         Re: IS UNIX DEAD? (long)
  74.             Re: BIG IMPORTANT QUESTION PLEEEEZE HELP ME!!!!!
  75.                         Re: IS UNIX DEAD? (long)
  76.                         Re: tcsh-like subroutine
  77.                   Re: Changing the owner of a process
  78.                         Re: IS UNIX DEAD (long)
  79.                 rexec does not search for ~/.netrc file
  80.                            Re: IS UNIX DEAD?
  81.                      Re: IS UNIX DEAD? (very long)
  82.                    Re: Overflow warnings (SCO SV3.2)
  83.                  CURSES - No delay option, SunOS 4.1.1
  84.               Re: lib77 "flush" call. Where is it in UNIX?
  85.                         Re: IS UNIX DEAD? (long)
  86.              Re: What full-screen file managers are there?
  87. -----------------------------------------------------------------
  88.  
  89. From: "Mr. Themos Pentakalos; ADMIN-COMP" <themos@umbc5.umbc.edu>
  90. Subject: UNIX Training
  91. Date: 17 Nov 92 02:28:08 GMT
  92. Sender: News posting account <newspost@umbc3.umbc.edu>
  93. To:       info-unix@sem.brl.mil
  94.  
  95. Hi everyone,
  96.  
  97. I am not very familiar with the UNIX market and would like to ask
  98. a couple of questions.
  99.  
  100. 1) are there any companies which teach UNIX topics such as system
  101.    management, networking, etc? addresses? prices?
  102.  
  103. 2) what are the most popular magazines in the UNIX area?
  104.  
  105.     Thanks a lot. Please reply directly to:   themos@umbc5.umbc.edu
  106. and i'll be glad to summarize if comments are good.
  107.  
  108. Themos.
  109.  
  110. -----------------------------
  111.  
  112. From: Vinay Kashyap <kashyap@oddjob.uchicago.edu>
  113. Subject: where no vi has gone before...? (CORRECTION)
  114. Date: 17 Nov 92 02:35:07 GMT
  115. Sender: News System <news@wakinyan.uchicago.edu>
  116. To:       info-unix@sem.brl.mil
  117.  
  118. I had posted a list of questions on vi, and Tuomas Lukka pointed out
  119. that question 3 didn't make sense:
  120.  
  121. >3. Is there a way to prepend or append characters to macros without
  122. >   (a) introducing newlines between the additions, &/or
  123. >   (b) writing to the file and deleting to a named buffer
  124. It should have read as follows (I apologize for the error):
  125.  
  126. 3. Is there a way to prepend or append characters to BUFFERS without
  127.    (a) introducing newlines between additions (yanking to an uppercase
  128.    buffer appends to text already in the buffer, but on a new line) &/or
  129.    (b) writing to the file and deleting to the named buffer (in other
  130.    words, are there ways to put characters in named buffers other than
  131.    yanking/deleting text)?
  132.  
  133. Vinay (kashyap@oddjob.uchicago.edu)
  134.  
  135. -----------------------------
  136.  
  137. From: Nancy Frishberg <nancyf@sug.org>
  138. Subject: Tutorials - nine topics (12/7, San Jose)  Sun User Group Conference
  139. Keywords: tutorials seminar Unix security programming tools network debugging
  140. Date: 17 Nov 92 00:19:49 GMT
  141. Sender: Mr USENET himself <news@world.std.com>
  142. Nntp-Posting-Host: sug.org
  143. To:       info-unix@sem.brl.mil
  144.  
  145.  
  146. If you're concerned about advanced Unix security, Posix-conforming
  147. systems, or moving from Unix programming to Unix system
  148. administration, plan to be at the Sun User Group Conference (San Jose
  149. Convention Center) on Monday, December 7, 1992 for one of the full day
  150. tutorials.  The Conference and Exhibition extends through Thursday.
  151.  
  152. All-day tutorials will focus on these topics and others of interest to
  153. novice and experienced Unix users as well as Unix programmers who want
  154. to expand their theoretical and practical knowledge.
  155.  
  156. Special offer: 5 full conference registrations (each includes a day of 
  157. tutorial) for the price of 4 when preregistering with a single payment.
  158.  
  159. Full-day tutorials currently scheduled include:
  160. - Advanced Unix Security (Matt Bishop, Dartmouth College)
  161. - Preparing for Disaster (a.m. - Brent Chapman, Great Circle Associates),
  162.   plus, Why have Computer Security? (p.m. Bob Baldwin, Tandem Computers)
  163. - Sun Network Debugging (Smoot Carl-Mitchell, Texas Internet Consulting)
  164. - Topics in Perl (Tom Christiansen, Convex Computer Corporation)    
  165. - Programming in POSIX (Jeffrey S. Haemer, Canary Software)    
  166. - UNIX Programming Tools (Kenneth Ingham, consultant)
  167. - The Internet and its Protocols (William LeFebvre, Northwestern University)
  168. - Introduction to UNIX System Administration (Dinah McNutt, Tivoli Systems)
  169. - Integrating C Code and Xt Widgets (Craig Rudlin, MD, Medical Software and Computer Systems)
  170.  
  171. If you just want to go to the exhibits, ask for a free show-only pass.
  172.  
  173. To get more information by email about these tutorials, the technical
  174. program, or exhibits at the Sun User Group conference, send requests
  175. to sugshow@sug.org .
  176.  
  177. You will receive the full tutorials and program description with
  178. registration information.  Or call 1-800/727-EXPO.  (Outside the U.S.,
  179. use 512/331-7761 (voice) or 512/331-3950 (FAX).)  
  180.  
  181. -- 
  182. Nancy Frishberg, Sun User Group.
  183.  
  184. -----------------------------
  185.  
  186. From: Karl Glazebrook <Karl.Glazebrook@durham.ac.uk>
  187. Subject: tcsh-like subroutine
  188. Date: 16 Nov 92 16:07:56 GMT
  189. Nntp-Posting-Host: dur.dust6
  190. To:       info-unix@sem.brl.mil
  191.  
  192. Hello,
  193.  
  194. I'm looking for a tcsh like input routine which would be callable from a C or
  195. FORTRAN program. I just want to be able to read a line of text from the user
  196. with tcsh-like (or emacs-like!) command line editing/recall features.
  197.  
  198. I'm working on a SPARC with SUNOS 4.1.3 but obviously the more general and
  199. portable the solution the better!
  200.  
  201. As a bonus there would also be another routine which could modify the recall
  202. list, but this is not essential as I could probably hack this myself given
  203. the first subroutine.
  204.  
  205. Thanks for any help,
  206.  
  207. Karl Glazebrook.
  208.  
  209. ---
  210.  ------------------------------------------------------------------------------
  211. | Karl Glazebrook,      | INTERNET:   Karl.Glazebrook@durham.ac.uk           |
  212. | Dept. of Physics,     |    JANET:   KARL.GLAZEBROOK@UK.AC.DURHAM           |
  213. | Univ. of Durham,      |     SPAN:   19463::DUVAD::KGB                      |
  214. | United Kingdom.       |      FAX:   091-374-3749                           |
  215.  ------------------------------------------------------------------------------
  216.  
  217. -----------------------------
  218.  
  219. From: Leslie Mikesell <les@chinet.chi.il.us>
  220. Subject: Re: IS UNIX DEAD?
  221. Date: 16 Nov 92 18:17:47 GMT
  222. To:       info-unix@sem.brl.mil
  223.  
  224. In article <1992Nov11.215409.18067@osuunx.ucc.okstate.edu> martin@datacomm.ucc.okstate.edu (Martin McCormick) writes:
  225.  
  226. >First, I completely agree with Jeff's enthusiasm for this system.  It is good
  227. >and probably is the wave of the future.  I do have one gripe, however.
  228. >As I have said, in other postings, Postscript is a half-finished job until
  229. >somebody comes up with a method for converting it back into standard ASCII
  230. >text like the lines you are reading, now.
  231.  
  232. I think GNU Ghostscript has an ASCII output option that will generate
  233. text positioned approximately where it is supposed to be on a page
  234. with anything else omitted.  
  235.  
  236. > The windows-oriented approach is
  237. >totally useless for those of us who are blind and use speech synthesizers.
  238. >We were able to cobble together a small C program to strip out all that
  239. >Postscript language and display a completely deformatted stream of data.
  240. >It beats nothing, though not by much.  I would love to help fix this problem,
  241. >but I need to find a document explaining Postscript in electronic form so
  242. >I can read it and figure out how to tackle this beast.
  243.  
  244. It's non-trivial in the general case because you have to be able to handle
  245. the entire postscript language to interpret the positioning and scaling
  246. effects.  Plus you'll miss things where fonts have been converted to
  247. curves and manipulated for artistic but still readable effects.  A
  248. quick and dirty approach is to just extract the strings in parens
  249. from the postscript and try to assemble them into text.  A more ambitious
  250. project would be to modify the Ghostscript ascii output to maintain
  251. some font size and type info that could be used by the speech synthesizer
  252. to vary the output effects.
  253.  
  254. Les Mikesell
  255.   les@fb.com
  256.  
  257. -----------------------------
  258.  
  259. From: Andy Newman <andy@research.canon.oz.au>
  260. Subject: Re: IS UNIX DEAD (long)
  261. Date: 16 Nov 92 23:44:31 GMT
  262. Sender: news@research.canon.oz.au
  263. To:       info-unix@sem.brl.mil
  264.  
  265. papresco@napier.uwaterloo.ca (Paul Prescod) writes:
  266. >
  267. >True, the problem is there are people, in this very newsgroup, who see
  268. >no reason to try to make user friendly applications for unix.  To them,
  269. >if you can't use VI right off the bat, or enjoy learning obscure, 
  270. >nonsensical, illogical keystrokes, you should go back to the mac.
  271. >THIS will kill Unix.
  272. >
  273.  
  274. Define "user friendly". Aren't the people who like vi users too?
  275.  
  276. -- 
  277. Andy Newman (andy@research.canon.oz.au)
  278.  
  279. -----------------------------
  280.  
  281. From: Nick Gavrielatos <gavriel@socrates.umd.edu>
  282. Subject: Adoptation of Unix in Europe
  283. Keywords: Unix, Europe
  284. Date: 17 Nov 92 04:51:55 GMT
  285. To:       info-unix@sem.brl.mil
  286.  
  287. I am preparing some work on adoptation of Unix in Europe.
  288.  
  289. WOuld anyone happen to have any old articles, or know 
  290. of any other magazine and/or book articles that can 
  291. recommend? Any info via personal mail would be greatly
  292. aprreciated.
  293.  
  294. Thank you much, 
  295.  
  296. Nick Gavrielatos
  297. gavriel@socrates.umd.edu
  298.  
  299. -----------------------------
  300.  
  301. From: s jonathan silverman <sjs6@quads.uchicago.edu>
  302. Subject: Re: Looking for Time Series Analysis software
  303. Date: 17 Nov 92 05:16:27 GMT
  304. Sender: News System <news@uchinews.uchicago.edu>
  305. To:       info-unix@sem.brl.mil
  306.  
  307.  
  308. The leading program for time series analysis is probably RATS, which runs
  309. under DOS, the Macintosh, Unix and perhaps some other operating systems
  310. as well.
  311.  
  312. The company that writes this is located in Evanston, IL.  Their name used
  313. to be VAR econometrics, but they might well have changed it about a year ago
  314. (perhaps to "Estima", but I could have them confused with another company).
  315.  
  316. RATS stands for something like "regression analysis for time series" and 
  317. contains a broad array of time series analysis functions including specral
  318. analysis.
  319.  
  320. If you cant track this down yourself, contact me by email and I will send
  321. you the phone number.
  322.  
  323. -- 
  324. Jonathan Silverman
  325.  
  326. sjs6@quads.uchicago.edu
  327. jonat@cicero.spc.uchicago.edu
  328.  
  329. -----------------------------
  330.  
  331. From: Pete Holsberg <pjh@mccc.edu>
  332. Subject: Re: What full-screen file managers are there?
  333. Keywords: utree, maint
  334. Date: 16 Nov 92 22:33:40 GMT
  335. To:       info-unix@sem.brl.mil
  336.  
  337. In article <1e4mbcINN1kh@crcnis1.unl.edu> pkramer@unlinfo.unl.edu (Paul Kramer) writes:
  338. =Hello,
  339. =
  340. =I found while reading articles in this electronic conference, a 
  341. =reference to a public-domain program called utree.  It is full-screen 
  342. =file manager which allows you to perform file functions with single 
  343. =keystrokes.  For example, after I start the program I see a screen 
  344. =that lists the files on my account.  If I want to delete one of those 
  345. =files I move the cursor on top of it, press a certain key.  Boom it 
  346. =gone!  
  347. =
  348. =Well I am wondering:  Is there anything better than utree?  I am aware
  349. =of a program called 'maint' but it doesn't have the full functionality
  350. =of 'utree'.
  351.  
  352. I prefer HDSCAN.
  353.  
  354. -----------------------------
  355.  
  356. From: Bill Campbell <bill@celestial.com>
  357. Subject: Re: SCO TCPIP >9 LOGINS AGAIN
  358. Date: 17 Nov 92 02:00:52 GMT
  359. To:       info-unix@sem.brl.mil
  360.  
  361. In <9461.63.uupcb@cccbbs.UUCP> doug.pavey@cccbbs.UUCP (Doug Pavey) writes:
  362.  
  363. >Well, I read Aris' and Barry's messages about what is involved in
  364. >getting more than 9 tty's to login.  ttyp00 -ttyp08 work fine, ttyp09
  365. >will login, but hang TCP.
  366.  
  367. Xenix has a max of 32 ptys and SCO UNIX a max around 254.
  368.  
  369. >How does one debug streams limits problems - determine how many are in
  370. >use, or how many one should set up if the user may be using as many as
  371. >10 processes per login (Progress Database is wonderful).  All users are
  372. >using TCP via 3 8 port Terminal servers. I can get the login messages on
  373. >all ports, until the user actually signs in, we don't seem to have
  374. >problems.  Seems like streams may be the culprit.  How to fix???
  375.  
  376. You don't say in this post whether you're running Xenix or UNIX
  377. and there are different tools to determine problems with streams
  378. in each.  Xenix comes with a program 'sw', UNIX comes with crash, and
  379. there are some freely distributed monitor programs such as u386mon
  380. available from various ftp sites.
  381.  
  382. Xenix sw displays:
  383.  
  384. Pause=1   Calls=74                                Host=camco1
  385.  
  386.    Resource  Cnt       Use   Total     Max    Fail
  387.      stream: 128        40    4020      53       0
  388.       queue: 256        83    8074     111       0
  389.      mblock:1152        7818508524     636       0
  390. dblk totals:1152        7813966687     543    4469
  391.  
  392. Mem Size Cnt Med Low   Use   Total     Max    Fail
  393.   1    4 256 230 204     0  893844     155       0
  394.   2   16 128 115 102     2  449445     102     889
  395.   8   32 256 230 204     6 2644776     207    3339
  396.  16   64 256 230 204     5 8602774     147       0
  397.  16  128 128 115 102    50  386387     103      18
  398.  12  256  48  43  38    15  220139      37       0
  399.   4  512   8   7   6     0  102435       7     223
  400.  32 1024  32  28  25     0   50083       8       0
  401.  64 2048  32  28  25     0  584718      13       0
  402.  32 4096   8   7   6     0   32086       5       0
  403.   0 8192   0   0   0     0       0       0       0
  404.  
  405. Buffers (used/total) = 11/187 Kbytes
  406.  
  407. This is from a system that has been running for a while now.  Uptime gives:
  408. camco1:ttyp02 /usr/local/bin # uptime
  409.   5:53pm  up 20 days, 55 mins,  12 users,  load average: 1.19, 1.04, 1.02
  410.  
  411. You would probably want to use crash and it's strstat command on a UNIX
  412. system which gives similar information.  A typical crash display is:
  413. beeson1:ttyp8:/onager/etc > crash
  414. dumpfile = /dev/mem, namelist = /unix, outfile = stdout
  415. > strstat
  416. ITEM                  CONFIG   ALLOC    FREE         TOTAL     MAX    FAIL
  417. streams                  256      158      98           821     171       0
  418. queues                  1280      704     576          2306     786       0
  419. message blocks          2825      309    2516      11357083     705       0
  420. data block totals       2260      309    1950       9675047     669      63
  421. data block size    4     384       51     333         66265     364      63
  422. data block size   16     384        8     376         39861      65       0
  423. data block size   64     512       24     488       4950469      68       0
  424. data block size  128     448      157     290       2974970     392       0
  425. data block size  256     220       33     187        632454     107       0
  426. data block size  512     136       36     100        495575      46       0
  427. data block size 1024      52        0      52         84628      44       0
  428. data block size 2048     104        0     104        430474      25       0
  429. data block size 4096      20        0      20           351      12       0
  430.  
  431. Count of scheduled queues:   0
  432. >
  433.  
  434. Bill
  435. -- 
  436. INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Software
  437. UUCP:   ...!thebes!camco!bill   6641 East Mercer Way
  438.              uunet!camco!bill   Mercer Island, WA 98040; (206) 947-5591
  439. SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
  440.  
  441. -----------------------------
  442.  
  443. From: "frederick.d.true" <ft@cbnewsi.cb.att.com>
  444. Subject: Unlocking named pipes
  445. Keywords: named pipe
  446. Date: 17 Nov 92 06:11:16 GMT
  447. Followup-To: ftrue@attmail.att.com
  448. To:       info-unix@sem.brl.mil
  449.  
  450. I'm having a bit of trouble figuring out what's wrong with the
  451. following usage of named pipes. I have 12 large compressed files which
  452. I would like to merge/sort (they are sorted) without having to
  453. decompress all of them before merging. So, I've written a simple script
  454. to create 12 named pipes with mknod, say pipe1..pipe12. I begin
  455. background processes to zcat each of the 12 files to one of the pipes
  456. in sequence. I then start 'sort <switches> -m pipe1 .. pipe12 | <stuff> >
  457. outputfile'.
  458.  
  459. Things go fine for a while, then the entire process freezes. The
  460. output stream stops, and all processes go into IW wait, as if waiting
  461. for something to happen. While in deadlock, if I try to read any of
  462. the pipes, they each have data waiting, so all seems to be fine. So
  463. who stopped everything and why?
  464.  
  465. Sort is able to merge at most 16 files at once, so I don't think
  466. there's anything wrong there. Is there another anomoly in sort that
  467. might cause this failure?
  468.  
  469. As best I can tell, sort found a depleted pipe that zcat couldn't keep
  470. up with (perhaps sort is reading large buffers?), but no EOF, and
  471. started sleeping. However, this isn't logical since the sort process
  472. is followed by 3 other heavyweight processes in the pipe before the
  473. output is written, so I would think that zcat could feed the pipes
  474. fast enough. Besides, I thought processes would handle FIFO's normally
  475. and sleep for at most a few seconds if it found and empty one before
  476. hitting EOF.
  477.  
  478. By the way, in case it proves significant: I'm using SunOS 4.1.2 on a
  479. SPARC. Standard sort, zcat, etc. Named pipes are created with mknod
  480. -p. I've also tried sleeping for a few seconds before starting things,
  481. with no results.
  482.  
  483. Can someone clear up the confusion, or at least add postulations to
  484. the heap?
  485.  
  486. Please e-mail to ftrue@attmail.att.com or post here.
  487.  
  488. --
  489. Fred True
  490. AT&T
  491.  
  492. -----------------------------
  493.  
  494. From: "David L. Parker" <dlparker@dlpinc00.rn.com>
  495. Subject: Re: grep
  496. Date: 17 Nov 92 03:36:38 GMT
  497. To:       info-unix@sem.brl.mil
  498.  
  499. In article <1992Nov16.092645.522@ericsson.se> etxmesa@eos.ericsson.se (Michael Salmon) writes:
  500. >In article <1992Nov13.113839.25046@dlpinc00.rn.com>, 
  501. >dlparker@dlpinc00.rn.com (David L. Parker) writes:
  502. >|> 
  503. >|> Actually it's Global Regular Expression Parser.
  504. >
  505. >Unfortunately Brian Kernigan and Rob Pike disagree with you, see
  506. >page 18 of:
  507. >
  508. >The Unix Programming Environment
  509. >Prentice Hall
  510. >ISBN 0-13-937699-2
  511. >
  512.  
  513. WOOPS!  Okay, so I got three out of four.
  514. -- 
  515. Dave Parker
  516. Automated Data Management Services, Pleasant Hill, MO 64080-1331
  517. (816) 987-5167/5218 voice/fax          -          dlpinc00!dlparker
  518.  
  519. -----------------------------
  520.  
  521. From: Big.Fun@debug.cuc.ab.ca
  522. Subject: FSCK command
  523. Date: 17 Nov 92 04:50:34 GMT
  524. To:       info-unix@sem.brl.mil
  525.  
  526. When using the fsck (file system check), when it comes upon part 4 of
  527. the check, which is a reference check, it says, "UNREF DEVICE".  What
  528. does this mean?
  529.  
  530. Thanks.. please send all replies via mail..
  531.  
  532. suicide
  533. big.fun@debug.cuc.ab.cu
  534.  
  535. -----------------------------
  536.  
  537. From: Jonas Furrer <jonas@uiag.ch>
  538. Subject: pwd: getwd: can't open ..?
  539. Date: 16 Nov 92 11:10:22 GMT
  540. To:       info-unix@sem.brl.mil
  541.  
  542. Hi,
  543.  
  544. why I have this error -> pwd: getwd: can't open ..
  545.  
  546.  
  547. OS          : OS/MP 4.1A.1 (Solbourne -> SUN 4.1)
  548. fstab entry : /dev/sd2d /files/disk2/imagery  4.2 rw 1 9
  549.  
  550. belfast:/% df /dev/sd2d
  551. Filesystem            kbytes    used   avail capacity  Mounted on
  552. /dev/sd2d             564349  311204  196710    61%    /files/disk2/imagery
  553.  
  554. belfast:/% ls -agld files 
  555. drwxrwxrwx  6 root          512 Oct 21 15:48 files
  556.  
  557. belfast:/% cd /files
  558. belfast:/files% ls -agld files
  559. drwxrwxrwx  4 root          512 Oct  2 14:07 disk2
  560. belfast:/files% pwd
  561. /files
  562.  
  563. belfast:/files% cd disk2
  564. belfast:/files/disk2% ls -agld files
  565. drwxrwxrwx  5 root          512 Nov 13 11:16 imagery
  566. belfast:/files/disk2% pwd
  567. /files/disk2
  568.  
  569. belfast:/files/disk2% cd imagery
  570. belfast:/files/disk2/imagery% pwd
  571. pwd: getwd: can't open ..
  572. belfast:/files/disk2/imagery% df .
  573. Filesystem            kbytes    used   avail capacity  Mounted on
  574. Could not find mount point for .
  575.  
  576. Can anyone help?
  577.  
  578. Thanks.
  579.  
  580.           +---------------------+---------------------------+
  581.           |Jonas Furrer         |E-Mail : jonas@uiag.ch     |
  582.           |Emch + Berger AG     |Tel    : +41 31 25 23 23   |
  583.           |Gartenstrasse 1      |Fax    : +41 31 25 16 85   |
  584.           |3001 BERN (CH)       |                           |
  585.