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

  1. Path: sparky!uunet!gatech!concert!rutgers!cmcl2!adm!news
  2. From: postmaster@vd1.hanscom.af.mil (SMTP MAILER)
  3. Newsgroups: comp.unix.questions
  4. Subject: Mail Delivery Problem
  5. Message-ID: <32375@adm.brl.mil>
  6. Date: 7 Sep 92 19:04:11 GMT
  7. Sender: news@adm.brl.mil
  8. Lines: 478
  9.  
  10.  
  11.  ----Reason for mail failure follows----
  12. Sending mail to recipient(s) woodfordm :
  13.   Couldn't make final delivery.
  14.  
  15.  ----Transcript of message follows----
  16. Received: from gw1.hanscom.af.mil by vd1.hanscom.af.mil with SMTP ; 
  17.           Fri,  4 Sep 92 17:36:36 EST
  18. Date: 4 Sep 92 17:30:00 EDT
  19. From: info-unix@BRL.MIL
  20. Subject: INFO-UNIX Digest  V15#140
  21. To: "woodfordm" <woodfordm@vd1.hanscom.af.mil>
  22.  
  23. Return-Path: <info-unix-request@sem.brl.mil>
  24. Received: from SEM.BRL.MIL by gw1.hanscom.af.mil with SMTP ; 
  25.           Fri,  4 Sep 92 17:30:25 EDT
  26. Received: from SEM.BRL.MIL by SEM.BRL.MIL id ab05177; 4 Sep 92 15:33 EDT
  27. Received: from sem.brl.mil by SEM.BRL.MIL id aa05056; 4 Sep 92 15:15 EDT
  28. Date:       Fri, 04 Sep 92 15:15:46 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  V15#140
  33. Message-ID:  <9209041515.aa05056@SEM.BRL.MIL>
  34.  
  35. INFO-UNIX Digest          Fri, 04 Sep 1992              V15#140
  36.  
  37. Today's Topics:
  38.                        Re: Using KKermit with cu
  39.                     missing /etc/resolv.conf - help
  40.                    Re: IP address from remote telnet
  41.          Re: SUMMARY:  What Unix HW/SW I will buy with my $8000
  42.                   Re: How to prevent a large core-dump
  43.                        Need help from a make guru
  44.                       Fixing Corrupted Tar files?
  45.                     Re: Shell Scripts vs. C programs
  46.                need script to rename uppercase filenames
  47.                              Dear vi guru,
  48.                            Re: Dear vi guru,
  49.                        spawning dbx on ones' self
  50. -----------------------------------------------------------------
  51.  
  52. From: "Patrick D. Buick" <buick@belay>
  53. Subject: Re: Using KKermit with cu
  54. Date: 31 Aug 92 18:02:11 GMT
  55. To:       info-unix@sem.brl.mil
  56.  
  57. In article <1992Aug13.124552.6761@news.yale.edu> szewczak@neutron.chem.yale.edu (Alexander Szewczak) writes:
  58. >les@chinet.chi.il.us (Leslie Mikesell) writes:
  59. >: I'm sort of internet-impaired myself
  60. >
  61. >Watch it, buddy. That's "differently networked".
  62. >
  63. >--
  64. >| Dave Schweisguth   Yale MB&B & Chemistry   Email: dcs@neutron.chem.yale.edu |
  65. >| Lab phone: 203-432-5208      Fax: 203-432-6144     Home phone: 203-624-3866 |
  66.  
  67. Nah, that's Internetually Challenged!! :-)
  68. -- 
  69. ==========================================================
  70. Patrick D. Buick EMT, EET  | Internet: buick%belay@uunet.uu.net
  71. Belay Enterprises Inc.     | Internet: buickp@cuug.ab.ca
  72. Calgary, Alberta, Canada   | UUCP:...!calgary!pixel!belay!buick
  73.  
  74. -----------------------------
  75.  
  76. From: Sabina Wolfson <swolfson@nyx.cs.du.edu>
  77. Subject: missing /etc/resolv.conf - help
  78. Date: 2 Sep 92 02:22:55 GMT
  79. Sender: netnews admin account <usenet@mnemosyne.cs.du.edu>
  80. X-Disclaimer: Nyx is a public access Unix system run by the University
  81.     of Denver for the Denver community.  The University has neither
  82.     control over nor responsibility for the opinions of users.
  83. To:       info-unix@sem.brl.mil
  84.  
  85. Hello,
  86.  
  87. The machine I have an account on at school is *missing* the resolv.conf
  88. file so that if I want to telnet/ftp somewhere I have to know the IP 
  89. address of the site, not just the name.  Is there something like
  90. gethostbyname() that will let me specify the name server to use (as is
  91. it just defaults to the local host which is not acceptable)?  Or is 
  92. there a way to get nslookup to use another namer server (as is I have to
  93. wait a minute or two for it to default to the /etc/hosts file and then
  94. specify another namer server -- this is a pain)?  Or is there some way
  95. I can send a request to another name server (I know which namer server
  96. my site should be using)?
  97.  
  98. Any help, hints, ideas would be appreciated!  Please post responses or
  99. mail them to sabina@cns.nyu.edu.
  100.  
  101. Thanks!  Sabina :)
  102.  
  103. p.s. yes, I already talked to the sys admin about this a few times...
  104.  
  105. -----------------------------
  106.  
  107. From: David Lemson <lemson@ux1.cso.uiuc.edu>
  108. Subject: Re: IP address from remote telnet
  109. Date: 2 Sep 92 03:33:18 GMT
  110. To:       info-unix@sem.brl.mil
  111.  
  112. dymm@cards.com (David Dymm) writes:
  113.  
  114.  
  115. >I would like to figure out how to determine an individual's IP address
  116. >when they are telneting into my system from a remote machine.
  117. >The scenario is that a user is on machine A (anywhere in the world),
  118. >and telnets into my system, and then runs a program on my system that
  119. >I provide to them.  The program that is running on my system must be
  120. >able to determine the IP address of machine A.
  121.  
  122. Get the log_tcp (tcp wrapper) package.  I believe it's on
  123. ftp.win.tue.nl and cert.sei.cmu.edu in the tools directory.
  124. -- 
  125. David Lemson                                                 (217) 244-1205
  126. University of Illinois NeXT Campus Consultant  / CCSO NeXT Lab System Admin
  127. Internet : lemson@uiuc.edu                 UUCP :...!uiucuxc!uiucux1!lemson 
  128. NeXTMail accepted                                   BITNET : LEMSON@UIUCVMD
  129.  
  130. -----------------------------
  131.  
  132. From: Greg Lehey <grog@adagio.uucp>
  133. Subject: Re: SUMMARY:  What Unix HW/SW I will buy with my $8000
  134. Date: 2 Sep 92 10:02:06 GMT
  135. Followup-To: comp.unix.questions
  136. To:       info-unix@sem.brl.mil
  137.  
  138. In article <RG.92Aug29154123@nymph.msel.unh.edu> rg@msel.unh.edu (Roger Gonzalez) writes:
  139. >
  140. >I wanted to buy a Unix box for home, and posted asking what I should buy for
  141. >$8000. 
  142. >
  143. >Looks like I will probably buy a
  144. >- 50MHz 486DX2 EISA w/ SCSI, 8Mb, 340Mb, svga    ($3695)
  145.                               ^^^ bad idea
  146. >- replace their monitor with NEC 5fg             ($1000)
  147. >- 1.2Gb disk                                     ($1200)
  148. >- 2.3Gb tape                                     ($1200)
  149.    ^^^^^^^^^^ can this read QIC-150 cassettes?
  150. >- Dell Unix                                      ($1000)
  151.  
  152. 8 MB should be considered an absolute minimum. You wouldn't get
  153. anything like good performance out of the machine with that little
  154. memory. Upgrading to 16 MB usually means throwing out the 8 MB of 1 MB
  155. SIMMs and replacing them with 4 x 4 MB SIMMs.
  156.  
  157. Most software distributed on tape will come on QIC-24 or QIC-150. If
  158. your nice 2.3 GB machine can't read them, it's only performing half
  159. its duty.
  160. -- 
  161. Greg Lehey                       | Tel: +49-6637-1488              
  162. LEMIS                            | Fax: +49-6637-1489
  163. Schellnhausen 2, W-6324 Feldatal, Germany
  164. *** NOTE ***: Headers get mangled at backbone - reply to grog%lemis@Germany.EU.net
  165.  
  166. -----------------------------
  167.  
  168. From: Lytras Apostolos <lytras@avalon.physik.unizh.ch>
  169. Subject: Re: How to prevent a large core-dump
  170. Date: 2 Sep 92 15:37:13 GMT
  171. Sender: USENET News Admin <news@ifi.unizh.ch>
  172. Nntp-Posting-Host: avalon
  173. To:       info-unix@sem.brl.mil
  174.  
  175. At least on the SUN we have here it works to put 
  176.  
  177. limit coredumpsize 0
  178.  
  179. in your .cshrc file, and that prevents cores from dumping...
  180.  
  181. - Apostolos.
  182.  
  183. PS: of course, you can set the limit to a different value, if you
  184. like... ;-)
  185.  
  186. -- 
  187.      lytras@ifi.unizh.ch           |   Apostolos Lytras
  188.      lytras@avalon.physik.unizh.ch    |   Informatik Club der Uni
  189.      lytras@amiga.physik.unizh.ch      |   Zuerich, SysAdmin
  190.  
  191. -----------------------------
  192.  
  193. From: Stephen Potter <spp@crane.cis.ufl.edu>
  194. Subject: Re: How to prevent a large core-dump
  195. Date: 2 Sep 92 15:38:13 GMT
  196. Sender: news@bikini.cis.ufl.edu
  197. Followup-To: comp.unix.admin
  198. Nntp-Posting-Host: crane.cis.ufl.edu
  199. To:       info-unix@sem.brl.mil
  200.  
  201. In article <1992Aug25.173056.13401@utwente.nl>, soos@math.utwente.nl (Adwin Soos) writes:
  202. |> Hello netters,
  203. |> 
  204. |> A few weeks or even months ago I have read some discussion about the problem
  205. |> of preventing a core-dump. I remember that there were some suggestions on how
  206. |> to prevent that a large core-dump will be made. 
  207. |> This person is not using this core to debug it so maybe we can just stop the
  208. |> creation of this core for this person.
  209. |> Is there someone who can mail me such suggestions?
  210. |> 
  211. Assuming the person is using some form of csh, why not just place a limit on the 
  212. coredump size....
  213. Place this in the .cshrc:
  214. limit coredumpsize 0
  215.  
  216. This will completely stop coredumps from being written.
  217.  
  218. -- 
  219. "There are worlds out there where the sky is burning.  The sea's asleep, and
  220. the rivers dream.  People made of smoke and cities made of sound.  Somewhere
  221. there's danger.  Somewhere there's injustice.  Somewhere else the tea's getting 
  222. cold.     Come on Ace, we've got work to do." -Dr Who, spp@cis.ufl.edu
  223.  
  224. -----------------------------
  225.  
  226. From: Guy Harris <guy@auspex.com>
  227. Subject: Re: How to prevent a large core-dump
  228. Date: 2 Sep 92 22:53:14 GMT
  229. Sender: news@auspex-gw.auspex.com
  230. Followup-To: comp.unix.admin
  231. Nntp-Posting-Host: bootme.auspex.com
  232. To:       info-unix@sem.brl.mil
  233.  
  234. >You won't get a core dump if the executable is stripped.  Am I the only
  235. >one who's noticed this?
  236.  
  237. The only other people who have noticed it are, presumably, the other
  238. people running a version of UNIX that doesn't produce core dumps if a
  239. process running a program whose image is stripped blows up.
  240.  
  241. I've yet to see any such version of UNIX....
  242.  
  243. -----------------------------
  244.  
  245. From: Karl Keyte <KKEYTE@esoc.bitnet>
  246. Subject: 'at' jobs - getting rid of mail
  247. Date: 2 Sep 92 16:21:35 GMT
  248. Organisation: European Space Operation Centre (E.S.O.C)
  249. To:       info-unix@sem.brl.mil
  250.  
  251.  
  252. How do I submit an 'at' job so I don't get any mail back?  The
  253. documentation says that the output of the job will be mailed unless
  254. I redirect it elsewhere.  For example,
  255.  
  256. demo.atfile contains:
  257.  
  258. (mycommand &) >/dev/null
  259.  
  260.  
  261. and I can do a:
  262.  
  263. at now + 1 min demo.atfile
  264.  
  265.  
  266. But I still get a mail back.  How do I stop this mail?
  267.  
  268. Please answer directly to me if you can - thanks.
  269.  
  270. Karl
  271.  
  272. -----------------------------
  273.  
  274. From: alan dare <alan@hal.larc.nasa.gov>
  275. Subject: Need help from a make guru
  276. Date: 2 Sep 92 19:19:56 GMT
  277. Sender: USENET Network News <news@ab20.larc.nasa.gov>
  278. Originator: alan@hal.larc.nasa.gov
  279. To:       info-unix@sem.brl.mil
  280.  
  281.  
  282. In our application we wanted to keep the object and source separate from 
  283. each other in a directory structure as shown below:
  284.  
  285.             <topdir>
  286.                |
  287.               / \
  288.                obj  src
  289.  
  290. My current makefile does this quite well. It also doesn't require a separate
  291. condition for each source. Problem: Several users add modules to a 
  292. executive then compile it. It would would be nice if they didn't have to
  293. modify the makefile. The makefile would just compile any source file in the
  294. current directory. I have taken several stabs at it, but I am not having
  295. any luck. All I need for it to work is a variable containing a list of
  296. the source and a variable containing the objects with the directory path 
  297. "../obj/" prefixed to it.  Below is a makefile that would compile all *.c and
  298. create a a.out file. However, I can't get make to execute the shell command
  299. correctly on the OBJECTS line correctly (the line is a valid shell command).
  300.  
  301. OBJDIR = ../obj
  302.  
  303. SOURCE=*.c
  304. OBJECTS=`for i in \`ls *.c |sed 's/\.c/.o/g'\`; do echo "../obj/$i"; done`
  305. $(OBJDIR)/a.out:  $(OBJECTS) 
  306.     cc -o $@ $(OBJECTS) 
  307.  
  308. $(OBJECTS) : $SOURCE
  309.     cc -c $(OPT)  $(@F:o=c) -o $@ 
  310.  
  311. Can anybody tell me how I can get the OBJECT variable set correctly?
  312.  
  313. Thanks to any and all.
  314. -- 
  315.  
  316. *********************************************************************
  317. Alan Dare                     |  Internet : alan@hal.larc.nasa.gov
  318. NASA Langley Research Center  | 
  319.  
  320. -----------------------------
  321.  
  322. From: John Tillema <jtillema@lpl.arizona.edu>
  323. Subject: Fixing Corrupted Tar files?
  324. Keywords: tar,corrupt
  325. Date: 2 Sep 92 20:59:48 GMT
  326. Sender: news@organpipe.uug.arizona.edu
  327. To:       info-unix@sem.brl.mil
  328.  
  329. Is there any way to do this? (fix corrupted tar files?)  Are
  330. there any utilties that will do this?
  331.  
  332. Thanks,
  333. John
  334. jtillema@panda.lpl.arizona.edu
  335. jtillema@lpl.arizona.edu
  336.  
  337. -----------------------------
  338.  
  339. From: Ajay Shah <ajayshah@almaak.usc.edu>
  340. Subject: Re: Shell Scripts vs. C programs
  341. Keywords: shell script, C
  342. Date: 2 Sep 92 22:17:51 GMT
  343. Sender: Ajay Shah <ajayshah@almaak.usc.edu>
  344. NNTP-Posting-Host: almaak.usc.edu
  345. To:       info-unix@sem.brl.mil
  346.  
  347. steiny@steiny.com (Don Steiny) writes:
  348.  
  349. >program.     Besides, there are still many systems that do not have ksh,
  350. >unfortunately, I have to use them all the time.   Even on Sun's, ksh is
  351. >a "local" program and is not always there.
  352.  
  353. There is a PD port of ksh, dunno how perfect it is.
  354. For this reason I've standardised on bash, but scripts are all !/bin/sh
  355.  
  356. Hopefully something like bash will proliferate far and wide, and then
  357. it'll be a good idea writing !/usr/bin/bash.
  358.  
  359.         -ans.
  360. -- 
  361. Ajay Shah, (213)749-8133, ajayshah@usc.edu
  362.  
  363. -----------------------------
  364.  
  365. From: Bill Miller <slix@svcs1.uucp>
  366. Subject: need script to rename uppercase filenames
  367. Keywords: script,tar,msdos
  368. Date: 2 Sep 92 22:26:57 GMT
  369. To:       info-unix@sem.brl.mil
  370.  
  371. Hi, everyone.
  372.  
  373. I'm fairly new to unix, and I need a script or procedure to do the following:
  374.  
  375. I have some source code in DOS (many separate files) that I tarred under
  376. DOS and untarred under 386BSD.  The big problem is that all the files
  377. came through in UPPERCASE and I need a script to mv (rename) them all
  378. to lowercase quickly.
  379.  
  380. Since they're in DOS text format, I realize I also need to strip the 
  381. extra carriage returns on each line.  I've been successful in doing this
  382. with:
  383.  
  384.   cat (file) | tr -d '\015' > (newfile)
  385.  
  386. It would be nice to combine both of these so that I could rename the
  387. files to uppercase and strip the extra newlines all in one fell swoop
  388. instead of doing it one file at a time.
  389.  
  390. -----------------------------
  391.  
  392. From: "Brian D. Schieber" <schieb@shark.gsfc.nasa.gov>
  393. Subject: Dear vi guru,
  394. Date: 2 Sep 92 22:41:36 GMT
  395. Sender: Usenet <usenet@nsisrv.gsfc.nasa.gov>
  396. Nntp-Posting-Host: shark.gsfc.nasa.gov
  397. To:       info-unix@sem.brl.mil
  398.  
  399. Dear vi guru,
  400.  
  401.  I like to use tabs alot in just about every session of vi I
  402. work with, It would be great if I had a macro or whatever that
  403. could replace the tabs with the appropriate number of spaces
  404. in a file WHILE in vi. Do you have such a macro?
  405.  
  406. Most graciously,
  407.  Brian
  408.  
  409. p.s. please send all suggestions to switch to EMACS to /dev/null
  410.  
  411. -----------------------------
  412.  
  413. From: Tom Parker <tparker@music.scd.ucar.edu>
  414. Subject: Re: Dear vi guru,
  415. Date: 2 Sep 92 23:33:30 GMT
  416. Sender: USENET Maintenance <news@ncar.ucar.edu>
  417. To:       info-unix@sem.brl.mil
  418.  
  419. In article <1992Sep2.224136.24163@nsisrv.gsfc.nasa.gov> schieb@shark.gsfc.nasa.gov (Brian D. Schieber) writes:
  420. >Dear vi guru,
  421. > I like to use tabs alot in just about every session of vi I
  422. >work with, It would be great if I had a macro or whatever that
  423. >could replace the tabs with the appropriate number of spaces
  424. >in a file WHILE in vi. Do you have such a macro?
  425.  
  426. Check if your system has the 'expand' command.  This command converts
  427. tabs to spaces, and vice versa.
  428.  
  429. --
  430. +--------------------------------------------------------------------+
  431. | Tom Parker             |  National Center for Atmospheric Research |
  432. | tparker@ncar.ucar.edu  |  (303) 497-1227                           |
  433. +--------------------------------------------------------------------+
  434.  
  435. -----------------------------
  436.  
  437. From: Will Sadkin <wsadkin@bbn.com>
  438. Subject: spawning dbx on ones' self
  439. Date: 2 Sep 92 23:08:34 GMT
  440. Sender: Will Sadkin <wsadkin@daedalus.bbn.com>
  441. NNTP-Posting-Host: daedalus.bbn.com
  442. To:       info-unix@sem.brl.mil
  443.  
  444.  
  445. To Unix wizards who read this group,
  446.  
  447. I have an application where I need to have it start up a dbx on itself
  448. a certain point in it's execution.  (For reasons I won't go into here, running
  449. dbx on the process from the start just won't do...) The basic scheme I came 
  450. up with is to:
  451.     get the pid for the process
  452.     fork
  453.     in child:  
  454.     run dbx on the pid of the parent
  455.     in parent: 
  456.     stop 
  457.  
  458. Unfortunately, I cannot get this to work...
  459.  
  460. If the parent sends itself a SIGSTOP, using kill, the dbx cannot
  461. attach, and just blocks forever.
  462.  
  463. It seems that when dbx first attaches to a process it sends its own
  464. SIGSTOP.  So I tried doing a sigpause(SIGSTOP), but this is not allowed.
  465.  
  466. I tried calling just pause in the parent; this results in the dbx 
  467. wedging, not accepting keyboard input; the same result happens if
  468. I simply call sleep. (What is happening here?)
  469.  
  470. Am I violating any fundamental rules?  If so, please let me know 
  471. where I've gone wrong, and if not, does anyone out there have a 
  472. solution to this problem?
  473.  
  474. /Will
  475.  
  476.  -------------------------------------------------------------------------------
  477. Will Sadkin                | "Never draw what you can copy;
  478. BBN Systems & Technologies |  never copy what you can trace;
  479. wsadkin@bbn.com            |  never trace what you can cut out and paste down!"
  480.  -------------------------------------------------------------------------------
  481.  
  482. -----------------------------
  483.  
  484.  
  485. End of INFO-UNIX Digest
  486. ***********************
  487.