Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!news From: postmaster@ecf.ncsl.nist.gov (SMTP MAILER) Newsgroups: comp.unix.questions Subject: Mail Delivery Problem Message-ID: <24114@adm.BRL.MIL> Date: 12 Aug 90 11:24:56 GMT Sender: news@adm.BRL.MIL Lines: 1583 ----Reason for mail failure follows---- Sending mail to host ecf.ncsl.nist.gov : Fatal reply code to command 'RCPT TO:': 550 User "ise.ncsl.nist.gov" Unknown. ----Transcript of message follows---- Date: 12 Aug 90 06:38:00 EST From: info-unix@BRL.MIL Subject: INFO-UNIX Digest V10#114 To: "ise.ncsl.nist.gov" Return-Path: Received: from SEM.BRL.MIL by ecf.ncsl.nist.gov with SMTP ; Sun, 12 Aug 90 06:37:55 EST Received: from SEM.BRL.MIL by SEM.BRL.MIL id ab06918; 12 Aug 90 5:58 EDT Received: from sem.brl.mil by SEM.BRL.MIL id aa06885; 12 Aug 90 5:45 EDT Date: Sun, 12 Aug 90 05:45:39 EST From: The Moderator (Mike Muuss) To: INFO-UNIX@BRL.MIL Reply-To: INFO-UNIX@BRL.MIL Subject: INFO-UNIX Digest V10#114 Message-ID: <9008120545.aa06885@SEM.BRL.MIL> INFO-UNIX Digest Sun, 12 Aug 1990 V10#114 Today's Topics: Re: Foo Bar article "Get Ready for GNU Software" in Computer World magazine SUMMARY: finding disk usage of partitions Re: help sought - securing a terminal/line Re: C-shell programming Re: Suid script security Re: How to tell if a process exists make's usage of VPATH Re: book request, want advice AWK Language Question permissions and parameters on terminal line Re: Printer Accounting File Parsing Re: Millisecond clock Emacs Re: sorting (using sort/sed/awk/whatever) Re: What's wrong with this Bourne shell script? Curses for terminals w/space-taking attributes path in news articles System VR4/i386 - when ? Re: Checkpoints for large jobs Re: KSH recommendations? SCO Vpix works under UHC SVR4? the f2c program Re: the f2c program Re: Working with sed fuser for sco unix v3.2.1 "make" file question Re: Timeout on shell command. make SUFFIXES question..... link (ln) with *one* name? ----------------------------------------------------------------- From: "Karen C. Pichnarczyk" Subject: Re: Foo Bar Date: 8 Aug 90 18:31:37 GMT Sender: news@dftsrv.gsfc.nasa.gov To: info-unix@sem.brl.mil Foo Bar is derived from the abbreviation FUBAR: F: American English colloquialism for 'messed', or 'destroyed' ('nice' people don't use this language) U: Up B: Beyond A: All R: Recognition Karyn ***disclaimer: insert standard disclaimer here ----------------------------- From: Dan_Jacobson@att.com Subject: article "Get Ready for GNU Software" in Computer World magazine Date: 10 Aug 90 16:21:42 GMT Sender: Dan Jacobson Followup-To: gnu.misc.discuss To: info-unix@sem.brl.mil There's a 1/2 page article "Get Ready for GNU Software," in Computer World magazine, Aug. 6, 1990, page 102, by Simson L. Garfinkel. Quotes: "...Stallman, who by many accounts may be the world's best programmer." "...GNU Emacs, is becoming the standard Unix programmer's editor." "...Stallman was awarded a $240,000 ``Genius Grant'' from the MacArthur Foundation." -- Dan_Jacobson@ATT.COM +1-708-979-6364 ----------------------------- From: Rob Bunten Subject: SUMMARY: finding disk usage of partitions Date: 10 Aug 90 17:07:16 GMT To: info-unix@sem.brl.mil Thanks for the responses to my original request for the disk usage of directories, not including stuff mounted from other partitions. The responses were from: xie@math.arizona.edu suggested using df(1) :-) dietrich@cernvax.cern.ch sent a program which is used to determine the number of files and directories and the occupied disk space in a file hierarchy beginning at startdirectory. I have the source, but haven't managed to get it to run on SunOS. meissner@osf.org mentions that the gnu fileutils 1.3 package contains a du rewrite that adds a -f option to prevent du from crossing filesystem boundaries. tmdg@ti.co.uk has a program that reports file fragmentation that could possibly be adapted. eirik@elf.tn.cornell.edu suggested the following (this is what I used): Apparently you want a way to tell du not to cross mount points; if not, I am probably answering a different question than the one you asked. It also sounds like you are ignoring all but local partitions. Assuming you have root permissions on the machine with the disks, there is a way of doing what you want. It is, in a sense, cheating, but I'd rather cheat than lose. :-) Here's the idea: export all file systems you're interested in to localhost, and mount them via NFS. As an example, the following shows the usage in my root partition: exportfs -i -o root=localhost,access=localhost / mount -n localhost:/ /mnt du /mnt mount -f localhost:/ /mnt umount /mnt chip@chinacat.unicom.com has written a du reimplementation. It is more oriented towards the SysV world, but it might be usable. paul@ixi-limited.co.uk suggests: find / -fstype nfs -prune -o -type f -exec du -s {} \; | \ awk ' { total = total + $1 } END { print total }' However, this doesn't do quite what I wanted, as I wanted the totals for each directory. Sorry for the delay in summarizing (the original posting was on 4th July). ----------------------------- From: Guy Harris Subject: Re: help sought - securing a terminal/line Date: 10 Aug 90 18:29:46 GMT To: info-unix@sem.brl.mil >You're saying V.4 doesn't use inittab? I'm saying it doesn't necessarily run "getty" out of "inittab". >Um, this is not good. The flexibility of inittab has been very helpful. I >don't want to go back to kludging a login or getty front-end again. Um, this is not good. You're making some inferences that aren't justified based purely on what I said, and that aren't, in fact, correct.... "ttymon" will listen on a whole bunch of ports, and spin off a process when the port comes up. The process can run whatever program you want it to. You can also run "getty" out of "inittab", if you want to, or any other program. >What else does V.3.2 have that V.4 hasn't? A shared library mechanism that requires you to explicitly ask for the shared version of a library, for one thing.... (S5R4's, like the SunOS 4.x one from which it's derived, gives you the shared library by default if there is one.) Go buy the S5R4 documentation - or some subset thereof, the entire documentation set is rather expensive and only crazy completists like me buy it out of our own pockets. ----------------------------- From: Guy Harris Subject: Re: help sought - securing a terminal/line Date: 10 Aug 90 18:32:49 GMT To: info-unix@sem.brl.mil >Fear not; the V.4 init still understands inittab. All Guy was >referring to was the advent of ttymon, a STREAMS-based tty port >monitor that provides a more convenient way to deal with terminals >than the old inittab method. And also gives you a few additional bells and whistles, such as autobauding (not the bit where you hit BREAK to get it to cycle through speeds, although "ttymon" does support that, but the bit where you type a character and, based on what the character looked like, "ttymon" guesses the speed of the line; same sort of thing as the 4.[23]BSD "getty" supports). It does permit you to run some program other than "login" on some port when it comes up. ----------------------------- From: Guy Harris Subject: Re: C-shell programming Keywords: csh, multiple file input Date: 10 Aug 90 18:45:22 GMT To: info-unix@sem.brl.mil >Appropriate use of /dev/fd could make it even neater, if you don't already >have sorted files. And if you *do* have "/dev/fd", which most UNIX systems at this point don't have, although I think S5R4 might have it. ----------------------------- From: Vicki Brown Subject: Re: Suid script security Date: 10 Aug 90 19:41:32 GMT Sender: usenet@apple.com Sender: To: info-unix@sem.brl.mil In article <14920003@hpdmd48.boi.hp.com> markw@hpdmd48.boi.hp.com (Mark Wolfe) writes: > > I know that suid scripts are a bad idea from reading comp.questions and >comp.wizards over the last year or so. It seems that just about every guru >in the world has posted a warning NOT to do it, so I decided I would follow >the advice (it's a rare subject that all guru's agree on). However, it appears >that I'm now about to have one of these ugly animals forced on me from above, >so I'd like some advice: > > 1) Just what are the security risks involved? (i.e. how would someone attack > a system via one of these). > > 2) What can I do to make this as secure as possible? Warning - very long response ahead. Proceed at your own risk. There was a very interesting paper in the USENIX Association's publication, ;login: ( "How To Write a Setuid Program", Matt Bishop, ;login: Vol 12, Number 1, January/February 1987). An excerpt: Some versions of UNIX allow command scripts, such as shell scripts, to be made setuid ... Unfortunately, given the power and complexity of many command interpreters, it is often possible to force them to perform actions which were not intended, and which allow the user to violate system security. This leaves the owner of the setuid script open to a devastating attack. In general, such scripts should be avoided. ... suppose a site has a setuid script of sh commands. An attacker simply executes the script in such a way that the shell ... appears to have been invoked by a person logging in. UNIX applies the setuid bit on the script to the shell, and ... it becomes interactive... One way to avoid having a setuid script is to turn off the setuid bit on the script, and ... use a setuid [binary] program to invoke it. This program should take care to call the command interpreter by its full path name, and reset environment information such as file descriptors and environment variables to a known state. However, this method should be used only as a last resort and as a temporary measure, since with many command interpreters it is possible even under these conditions to force them to take undesirable action. The biggest problem with shell scripts is that you (the programmer / administrator) have very little control over the programs which run within the script. As a very real example, I ran across a script which allowed users to enter bug reports, using the "vi" editor. The script was setuid root, because it wanted to save files in funny places. The programmer had guarded against shell escapes (a known feature of vi), by making this script the login shell. However, he couldn't guard against another feature :e /etc/passwd You can attempt to make your script as safe as possible by 1) being very restrictive in your choice of UID. That is, make the script setuid for a non-privileged user, rather than root (for example, if it must write a log file, could the log file live in some locked area, accessed only by a new and otherwise non-privileged account?) 2) making the script setgid rather than setuid, with a very restricted GID (see #1) 3) ensuring that the script is short, very simple, and does not make use of commands such as `vi', `mail' or anything interactive. setuid programs should do ONE thing only, and in a non-complex manner. 4) setting the PATH, IFS, and other environment variables explicitly within the script 5) locking down the permissions on the script. If possible allow it to be run only by group members. Never allow write permission. 6) If your version of UNIX permits, take away read permission for anyone other than the owner. It's a bit harder to break something if you can't see how it works. 7) Rewrite it in C (carefully) 8) Convince your management that they don't really need this. If you plan to keep the script, or re-write it, try and get a copy of the paper. If you can't find it, send me mail. Vicki Brown A/UX Development Group Apple Computer, Inc. Internet: vlb@apple.com MS 58A, 10440 Bubb Rd. UUCP: {sun,amdahl,decwrl}!apple!vlb Cupertino, CA 95014 USA Ooit'n Normaal Mens Ontmoet? En..., Beviel't? (Did you ever meet a normal person? Did you enjoy it?) ----------------------------- From: Guy Harris Subject: Re: Suid script security Date: 11 Aug 90 21:01:33 GMT To: info-unix@sem.brl.mil >Now, what if the name of the very shell script were e.g. "-i"? Wouldn't that >give a nice exec? > > execl("/bin/sh", "sh", "-i", (char *) 0); > >So link the script to a file named "-i", and voila! >Yes, one needs write permission somewhere on the same device, if one's >operating system doesn't support symbolic links. > >What about the csh command interpreter? Well, 4.2BSD provides us with a csh >which has a NEW option: "-b"! Its goal is to avoid just the thing described >above: Whereas the Bourne shell already has an option whose effect is to avoid the thing just described above - "-". Yup, just a dash by itself, as in #! /bin/sh - >the mnemonic for `b' is `break'; To quote the C shell source code: case 'b': /* -b Next arg is input file */ batch++; so I don't think the mnemonic was intended to be "break".... ----------------------------- From: Vicki Brown Subject: Re: How to tell if a process exists Date: 10 Aug 90 19:44:33 GMT Sender: usenet@apple.com Sender: To: info-unix@sem.brl.mil In article <7733@amelia.nas.nasa.gov> samlb@pioneer.arc.nasa.gov.UUCP (Sam Bassett RCS) writes: >In article <1823@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: >>Wrong. RTFM -- kill(pid, 0) > > Hmmm -- must be running Reverse Polish Unix down under, 'cause my >manual sez: " kill [-sig] processid... ", and I've been doing it that way >for a looooooooong time. > > What kind of UNIX _are_ you running?? ---> C <--- ( man 2 kill 8^) Vicki Brown A/UX Development Group Apple Computer, Inc. Internet: vlb@apple.com MS 58A, 10440 Bubb Rd. UUCP: {sun,amdahl,decwrl}!apple!vlb Cupertino, CA 95014 USA Ooit'n Normaal Mens Ontmoet? En..., Beviel't? (Did you ever meet a normal person? Did you enjoy it?) ----------------------------- From: Doug Gwyn Subject: Re: How to tell if a process exists Date: 10 Aug 90 21:47:42 GMT To: info-unix@sem.brl.mil In article <7733@amelia.nas.nasa.gov> samlb@pioneer.arc.nasa.gov.UUCP (Sam Bassett RCS) writes: -In article <1823@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: ->Wrong. RTFM -- kill(pid, 0) - Hmmm -- must be running Reverse Polish Unix down under, 'cause my -manual sez: " kill [-sig] processid... ", and I've been doing it that way -for a looooooooong time. Doing what, incorrectly reading your manual? ----------------------------- From: Terry Laskodi Subject: Re: How to tell if a process exists Date: 10 Aug 90 22:16:13 GMT Sender: news@osf.org To: info-unix@sem.brl.mil In article <7733@amelia.nas.nasa.gov> samlb@pioneer.arc.nasa.gov.UUCP (Sam Bassett RCS) writes: >In article <1823@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: >>Wrong. RTFM -- kill(pid, 0) > > Hmmm -- must be running Reverse Polish Unix down under, 'cause my >manual sez: " kill [-sig] processid... ", and I've been doing it that way >for a looooooooong time. > > What kind of UNIX _are_ you running?? Well, you're both right. Boyd was describing kill(2); Sam was describing kill(1)..... ----------------------------- From: Sam Bassett RCS Subject: Re: How to tell if a process exists Date: 11 Aug 90 06:20:20 GMT Sender: news@amelia.nas.nasa.gov To: info-unix@sem.brl.mil Ooops -- yer right -- my mistake. Sorrreee..... Sam'l Bassett, Sterling Software @ NASA Ames Research Center, Moffett Field CA 94035 Work: (415) 604-4792; Home: (415) 969-2644 samlb@well.sf.ca.us samlb@ames.arc.nasa.gov := 'Sterling doesn't _have_ opinions -- much less NASA!' ----------------------------- From: Mike Verstegen Subject: make's usage of VPATH Keywords: make VPATH Date: 10 Aug 90 20:30:19 GMT Sender: mdv@comtst.uucp To: info-unix@sem.brl.mil A recent posting's comment about VPATH in make prompted me to use strings(1) to check our make to see if our makes were configured with this feature. Both of our systems' (3B2 V.3.1 and ISC 2.0.2) makes had the text VPATH in them. Then, using the documentation for nmake, I tried to get VPATHs to work. Unfortuanately, it did not. Either I don't understand VPATH as used in make, or make doesn't understand what I'm asking for. What I think VPATHs do is to provide alternate locations from source files in make's dependency analysis. For example, if I'm working on a project and I want to try out a private modification I could do the following: Directory contents: /u/official.d work.d ============= ====== foo.c foo.c bar.c Makefile contents: OBJ=foo.o bar.o fubar: $(OBJ) cc -o fubar $(OBJ) Commands executed: cd work.d VPATH=.:/u/official.d # also tried putting this in Makfile, no change export VPATH make foobar Results: Make: Don't know how to make bar.o. Stop. I think (acutally I thought): make would look in work.d and see foo.c in . (the first component in VPATH) and compile to foo.o as usual [it did]. Then, it would look for bar.c in . and see that it was not there. make would then look in /u/offical.d (the next component in VPATH), see it there, and use that as the file for complication [it did not]. Since VPATH is not a doucmented feature (at least that I can find) I know I cannot expect it to work, though I really would like this capability. I would appreciate any feedback on whether what I have described above is a correct expection and, if so, why doesn't it work? If it's not supposed to work (i.e. VPATH was there just to fool people like me), maybe I'll try to track down nmake which claims to support this feature. Please e-mail replies and I'll summarize if there is enough interest. -- Mike Verstegen ..!uunet!comtst!mdv mdv@domain.com ----------------------------- From: Doug Gwyn Subject: Re: book request, want advice Keywords: unix books, non-trivial Date: 10 Aug 90 21:52:37 GMT To: info-unix@sem.brl.mil In article <1900@batman.moravian.EDU> dodgeT@batman.moravian.EDU (Asmodeus) writes: - I would like the net's advice on (a) good book(s) concerning -the non-trivial aspects of unix. I am already familiar w/many of the -commands...that is not a problem...what i want is a book that -details and explains many of the unix features that separate it from -the smaller operating systems. Ex.-> devices, virtual memory, perl, -other various shells...basically a good book that doesn't spend too much -time explaining every line-editor and vi to me...tell me something -interesting... Libes & Ressler, "Life With UNIX", would probably tell you much of what you want to know, but only at a survey level. For details you have to dig into lots of places. ----------------------------- From: Ken Boi Subject: AWK Language Question Date: 10 Aug 90 22:25:24 GMT Sender: news@richsun.cpg.trs.reuter.com To: info-unix@sem.brl.mil According to the book "The AWK Programming Language", there are built-in string functions. One of them is 'gsub'. I have tried using it with the following comand line statement which is very close to the example in the book: awk '{ gsub(/USA/, "United States"); print }' awkdata where 'awkdata' is any text file. I get the error messages: awk: syntax error near line 1 awk: illegal statement near line 1 Anybody know why? ----------------------------- From: NRAO Array Operations Center Subject: permissions and parameters on terminal line Date: 10 Aug 90 23:01:05 GMT Sender: Ruth Milner To: info-unix@sem.brl.mil I have a user with a device attached to a serial line which he is writing a program to talk to. The problem is this: I don't particularly want to install his program setuid root, so how do I get the system to set the ownership of the terminal device at boot time so that it will stay that way as long as the system is up? Currently, every time he runs the program he has to first run something I gave him the change the ownership, and then after his program finishes the device reverts to root. Running a daemon on the line is not a nice solution, either, since if it dies for some reason the same problem crops up. Ideally I would like to be able to say something in /etc/rc.local like: chown -permanent him /dev/tty1c stty -permanent 4800 raw /dev/tty1c Obviously these commands won't work, but is there something else in stock UNIX which will? init won't work because every time it wakes up it interferes with his program; I have had to turn it off on that line. The system is a Solbourne 5/801 (SPARC CPU chip) running OS/MP 4.0c (= SunOS 4.0.3). Thanks in advance. Please reply by email and I will post the final solution. -- Ruth Milner Systems Manager NRAO/VLA Socorro NM rmilner@zia.aoc.nrao.edu ----------------------------- From: Larry Wall Subject: Re: Printer Accounting File Parsing Date: 11 Aug 90 00:02:38 GMT To: info-unix@sem.brl.mil In article <24110@adm.BRL.MIL> BKEHOE%widener@pucc.princeton.edu writes: : : Here's something that should be simple to solve..it can be in anything (C/ : awk/shell/whatever). : I need to parse down the results of the printer accounting file into a total : for each user for that 2-week or month-long period of time, and send mail to : those users that've gone above 50 pages saying something like "Calm down". : I've been futzing in awk but can't seem to pull it off -- and in C my string : manipulation seems to be off (admittedly I haven't spent a *lot* of time : hacking it out). : ... : It'd be nice if I could assess the # of pages they print off of each client : too, but that may be overkill. No problem. ---------- CUT HERE ---------- #!/usr/bin/perl $THRESHOLD = 50; while (<>) { ($pages, $wherewho) = split(' '); ($where, $who) = split(/:/, $wherewho); $sum{$who} += $pages; $client{$who} .= "$where " unless $clientsum{$wherewho}; $clientsum{$wherewho} += $pages; } foreach $who (keys %sum) { next if $sum{$who} < $THRESHOLD; @clients = sort split(' ', $client{$who}); $breakdown = ''; if (@clients >= 2) { $breakdown = "Breakdown:\n\tMachine \tPages\n"; foreach $client (@clients) { $breakdown .= sprintf("\t%-16s%5d\n", $client, $clientsum{"$client:$who"}); } } open(MAIL,"|/bin/mail $who") || die "Can't run mail: $!\n"; print MAIL < Subject: Re: Millisecond clock Keywords: HP-UX SYSV Date: 11 Aug 90 00:34:16 GMT To: info-unix@sem.brl.mil The folowing program for millisecond sleep works under HP-UX SYSV, so it should work on an ATT (serious finger crossing :-). Compile with: cc -O timer.c -o timer --------------------------------- cut here ----------------------------------- #include #include void myhandler() {} usleep(usec) int usec; { int sigret; struct itimerval rttimer; struct itimerval old_rttimer; struct sigaction *act, *oact ; rttimer.it_value.tv_sec = ( (float) usec) / 1000000; rttimer.it_value.tv_usec = ((float) usec) - ((float) rttimer.it_value.tv_sec * 1000000.0); rttimer.it_interval.tv_sec = 0; rttimer.it_interval.tv_usec = 0; (void) signal(SIGALRM,(myhandler)); setitimer (ITIMER_REAL, &rttimer, &old_rttimer); pause(); } main () { usleep(500000); } --------------------------- cut here -------------------------------------- ********************************************************************* Tony Burzio * OH! You have to turn it ON first! Martin Marietta Labs * mmlab!burzio@uunet.uu.net * - First day, DOS user. ********************************************************************* ----------------------------- From: Guy Harris Subject: Re: Millisecond clock Keywords: HP-UX SYSV Date: 11 Aug 90 20:55:54 GMT To: info-unix@sem.brl.mil >The folowing program for millisecond sleep works under HP-UX SYSV, so >it should work on an ATT (serious finger crossing :-). Crossing the fingers is a good idea here. "Xxx works under HP-UX SYSV, therefore it should work on an [arbitrary] ATT [System V release]" isn't a valid deduction. While some systems, including HP-UX, have "setitimer()", which your program uses, vanilla AT&T System V releases prior to S5R4 don't have it. ----------------------------- From: william n bell Subject: Emacs Date: 11 Aug 90 00:50:06 GMT Sender: news@acsu.buffalo.edu Nntp-Posting-Host: lictor.acsu.buffalo.edu To: info-unix@sem.brl.mil Who can I contact to get a Unix version of emacs? Is it public domain?? WHere can I find it?? Send email. Thanks. -- Out Of Touch BBS - 716-825-4268 from 8pm-8am! FIDO 1:260/170... Online games! ----------------------------- From: "Jon H. LaBadie" Subject: Re: sorting (using sort/sed/awk/whatever) Date: 11 Aug 90 07:19:22 GMT To: info-unix@sem.brl.mil In article <13492@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > In article montanaro@crdgw1.ge.com (Skip Montanaro) writes: > >In article <13485@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > > Surely you jest. You're asking for an artificial intelligence program here. > >I don't know. The following short shell script seems to do what Luke wanted > >(cluster all the C++ groups together, regardless of their spot in the Usenet > >tree). > > It only orders by the last member of the hierarchy, which is not very helpful > (as you can see by running a large .newsrc through this process). For example, > foo.c++.bugs would be collected with other *.bugs, not with other c++ groups. While I see little value in the original poster's desires, Doug's comment on Skip's solution is easily taken care of with out AI type code. To wit: cut -d: -f1 .newsrc | awk -F. ' { for (i = NF; i >= 1; i--) printf("%s ", $i) print "" }' | paste -d: - .newsrc | sort | cut -d: -f2- > puke And should you not have cut (a Xenix related deficiency) let me know and I'll provide an awk/shell script to mimic it. Or perhaps there is a ???.sources version around. Jon -- Jon LaBadie {att, princeton, bcr}!jonlab!jon {att, attmail, bcr}!auxnj!jon ----------------------------- From: "Jon H. LaBadie" Subject: Re: What's wrong with this Bourne shell script? Date: 11 Aug 90 07:36:45 GMT To: info-unix@sem.brl.mil In article <1990Aug6.172225.20319@iwarp.intel.com>, merlyn@iwarp.intel.com (Randal Schwartz) writes: > In article <1990Aug3.193231.3166@silma.com>, aab@silma (Andy Burgess) writes: > | While you're at it, is there a better way to get the total bytes > | of the files in a directory? > > PERL SCRIPT DELETED A script of mine called "addcol" was printed in UNIX World's monthly column Wizard's Grabbag and would do the same thing without perl; ls -ld | addcol -4 However, have we forgotten our roots? I'm surprised in this thread that no one has mentioned: TOTAL=`cat * | wc -c` Jon -- Jon LaBadie {att, princeton, bcr}!jonlab!jon {att, attmail, bcr}!auxnj!jon ----------------------------- From: Larry Wall Subject: Re: What's wrong with this Bourne shell script? Date: 11 Aug 90 18:55:52 GMT To: info-unix@sem.brl.mil In article <850@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: : In article <1990Aug6.172225.20319@iwarp.intel.com>, merlyn@iwarp.intel.com (Randal Schwartz) writes: : > In article <1990Aug3.193231.3166@silma.com>, aab@silma (Andy Burgess) writes: : > | While you're at it, is there a better way to get the total bytes : > | of the files in a directory? : > : > PERL SCRIPT DELETED : : A script of mine called "addcol" was printed in UNIX World's monthly : column Wizard's Grabbag and would do the same thing without perl; : : ls -ld | addcol -4 : : However, have we forgotten our roots? I'm surprised in this thread : that no one has mentioned: : : TOTAL=`cat * | wc -c` Let us be explicit about the advantages and disadvantages of these approaches. Any naive approach using ls is gonna screw up in /dev, and probably does the opposite of what you want on symbolic links. The cat approach has to read all the bytes (try it on a swapfile), but probably does what you want on symbolic links. It may or may not do what you want on files with holes in them. It doesn't do what you want with the last access times. It CERTAINLY doesn't do what you want in /dev, or in a directory containing a FIFO or a Unix domain socket. The stat structure in C is quite straightforward by comparison. Pity there's such a big ecological niche between shell and C... Larry ----------------------------- From: Randal Schwartz Subject: Re: What's wrong with this Bourne shell script? Date: 12 Aug 90 05:25:07 GMT Sender: news@iwarp.intel.com To: info-unix@sem.brl.mil In article <850@jonlab.UUCP>, jon@jonlab (Jon H. LaBadie) writes: | However, have we forgotten our roots? I'm surprised in this thread | that no one has mentioned: | | TOTAL=`cat * | wc -c` Because it (a) skips files that start with dot, and (b) is *horribly* inefficient. Don't try this at home, kiddies! Just another UNIX hacker (and look, I didn't mention Perl here, either), -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Welcome to Portland, Oregon, home of the California Raisins!"=/ ----------------------------- From: "David T. Sandberg" Subject: Curses for terminals w/space-taking attributes Date: 11 Aug 90 08:48:39 GMT Followup-To: comp.unix.questions To: info-unix@sem.brl.mil I have been having problems with using curses to do screen handling on terminals with the "magic cookie glitch", i.e. space-taking attributes. (I have elected to crosspost to comp.lang.c after some consideration, since curses comes from the land of C.) The following simple fragment illustrates the problem. I've run this through on three systems (NCR Tower w/SysVr2, 386 w/SCO Xenix 2.3.2, and my faithful AT&T Unix PC w/OS version 3.51). /*-------------------*/ #include main() { initscr(); clear(); move( 5, 5 ); standout(); addstr( " This should be highlighted " ); standend(); refresh(); getch(); endwin(); } /*-------------------*/ On all three systems this code performs as expected when using a terminal without space-taking attributes (in other words, a _real_ terminal ;'). However, when using either a tvi905 or a wyse50, both of which require a space for the attribute data, this code performs properly only on the Tower (and more complex stuff of this sort doesn't even like to work there). On the other two systems the strings is displayed highlighted for the barest of moments, and then reverts back to normal before the keystroke is accepted via getch(). (Note that applications programs which use highlighting on these system/terminal combinations work perfectly... I'm reasonably certain that the termcap/terminfo files are not the culprit.) So, are two of these three curses implementations broken in this regard? Or is proper handling of XMC beyond the capability of most curses implementations? Or am I just lacking knowledge on how to handle these types of terminals via curses? (I hope it's the latter - I need to make this work as soon as possible, and I'm rather more comfortable with curses than I am with using the terminal databases directly. The 386 running SCO Xenix is the environment in which I need to actually overcome this, BTW.) Any and all comments regarding coding for terminals with those god-cursed space-taking attributes will be greatly appreciated. Please email responses to dts@quad.sialis.mn.org... but if you choose to followup for some reason, I have redirected same to comp.unix.questions, since I do not receive comp.terminals.) -- \\ \ David Sandberg, consultant \\ // "Small hats!" / Richfield MN // \\ \ dts@quad.sialis.mn.org \\ ----------------------------- From: V-Link System Administrator Subject: path in news articles Keywords: path news Date: 11 Aug 90 11:50:28 GMT To: info-unix@sem.brl.mil I don't seem to have something right in my news software, everytime I post news my "path" doesn't come up right. Could some one tell me where and how to set this up. It is the "path" that appears in the news header like the one you are reading in this article. Thanks in advance. -- V-Link Corporation | V-Link Sys Admin 1828 Darrow Drive |---------------------------------- Powell, OH 43065-9261 | Local : root (614)792-6363 | Remote: root@vlink01.UUCP ----------------------------- From: Per Andersson Subject: System VR4/i386 - when ? Date: 11 Aug 90 12:35:19 GMT To: info-unix@sem.brl.mil Has anybody seen a sold rel4 for the 386 ? Can anybody quote a price ? This has to be the best vapourware of 1990. In January agents promised 'it would be for sale in a couple of weeks'. The market is probably screwed because it's too many home systems and too many poor system managers which doesn't make good customers. So why worry their heads with all this new stuff ?. SCO has no plan when r4 will be considered, and Interactive just released 2.2. Why not concentrate on getting the enhancement working on r4 instead ? r4 working on ICLs machines doesn't help one bit because the big 386 market couldn't afford one, and should better buy a Sparcstation SLC, 'cos thats not more expensive than a top end 386, and runs DOS programs, just like the 386. WHEN WILL I BE ABLE TO BUY SYSTEM V rel 4 FOR THE i386 ? Per -- --- Per Andersson Royal Institute of Technology, Stockholm, Sweden perand@admin.kth.se, @nada.kth.se ----------------------------- From: Skip Montanaro Subject: Re: Checkpoints for large jobs Date: 11 Aug 90 13:11:23 GMT Sender: news@crdgw1.crd.ge.com Followup-To: comp.unix.questions To: info-unix@sem.brl.mil On a case-by-case basis, you may be able to modify your applications so they will recover. For instance, if your application is an iterative solver of some sort, you may be able to checkpoint the intermediate data periodically. When the program is restarted, a flag can be set so the program initializes from the intermediate solution data. There was a system a few years ago (maybe 1986?) developed at the University of Wisconsin that allowed jobs to be restarted (modulo some special I/O situations). It was reported in a USENIX conference of that era. Also, UNICOS on the CRAY has a checkpointing facility. You might investigate it, and ask Sequent why they haven't got something similar. -- Skip (montanaro@crdgw1.ge.com) ----------------------------- From: Bill Heiser - Unix Sys Admin Subject: Re: KSH recommendations? Date: 11 Aug 90 15:44:00 GMT Sender: "Bill Heiser - Unix Sys Admin @ Raytheon Company, Sudbury MA" To: info-unix@sem.brl.mil In article <1990Aug08.113542.13266@iti.uucp> todd@iti.UUCP (maroC ddoT) writes: > >Since ISC just added job control (to 2.2) you may want to keep in mind that >any korn shell compiled for an earlier ISC probally will not support any >job control. Does anyone know if ESIX has job control? -- Bill Heiser Work: heiser@tdw201.ed.ray.com {decuac,necntc,uunet}!rayssd!tdw201!heiser Home: Bill.Heiser@f240.n322.z1.fidonet.org (Fidonet 1:322/240) The Think_Tank BBS (508)655-3848 1200/2400/9600-HST Other: 75106.2332@compuserve.com Other: heiser@world.std.com (Public Access Unix) ----------------------------- From: teoh@uicbert.eecs.uic.edu Subject: SCO Vpix works under UHC SVR4? Date: 11 Aug 90 17:55:27 GMT To: info-unix@sem.brl.mil UHC indicated Vpix from Interactive would work w/ their release of SVR4 but has no knowledge about SCO's. And, SCO claims that their Vpix is functionally identical to the one from Interactive. My question is since every vendor installation procedure is different, is it possible, w/out any modification, to install and run SCO Vpix on UHC SVR4? -- Hai-Chuan Teoh * Email: teoh@uicbert.eecs.uic.edu Electrical Engr & Comp Sci * Tel: (312) 930-1942 Univ of Illinois * ----------------------------- From: Doug McDonald Subject: the f2c program Date: 11 Aug 90 20:25:42 GMT Sender: News To: info-unix@sem.brl.mil On the computer research.att.com is a program called "f2c". It converts Fortran programs to, mostly, C. But it does NOT convert Fortran IO calls to C. Instead it just invokes some mysterious io routines. I take these to be somebody's Fortran IO runtime library - indeed, there are linking with certain libraries. But WHOSE libraries? Would someone with a Unix machine and NO Fortran compiler have these routines? IF so, exactly WHOSE Unix? I can't believe that the many different Fortran compilers out there would use the same runtime. So, whose will this thing work with???? Doug McDonald(mcdonald@aries.scs.uiuc.edu) ----------------------------- From: Henry Spencer Subject: Re: the f2c program Date: 12 Aug 90 00:58:36 GMT To: info-unix@sem.brl.mil In article <1990Aug11.202542.9891@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >On the computer research.att.com is a program called "f2c". It converts >Fortran programs to, mostly, C. But it does NOT convert Fortran IO >calls to C. Instead it just invokes some mysterious io routines. I >take these to be somebody's Fortran IO runtime library... whose will this >thing work with???? Also on research.att.com, in the same directory, are files named "libF77.Z" and "libi77.Z", which might be worth investigating. -- It is not possible to both understand | Henry Spencer at U of Toronto Zoology and appreciate Intel CPUs. -D.Wolfskill| henry@zoo.toronto.edu utzoo!henry ----------------------------- From: Guy Harris Subject: Re: Working with sed Date: 11 Aug 90 21:04:08 GMT To: info-unix@sem.brl.mil >On SysV and SunOS 4.0.3_EXPORT (therefore probably BSD systems in >general??) Nope. SunOS picked "dirname" up from S5, not from BSD. ----------------------------- From: Philip Hall Subject: fuser for sco unix v3.2.1 Keywords: fuser, sco v3.2.1 Date: 11 Aug 90 23:59:49 GMT To: info-unix@sem.brl.mil I have been trying to port the fuser.c source that can be found on uunet to the sco unix v3.2.1. Has anyone had any success doing this, and if so, can you mail me info on how to do it. The version of fuser.c that i got from uunet is realying on a tune structure being defined in tuneable.h. the structure is there, but not the info that fuser is expecting. i can hard code these values (nfile, nproc ...) but i don't know if there is anything else it is looking for. i would rather not re-envent the wheel if someone has already done so. i was surprised that sco doesn't provide fuser as a standard package. thanks for any help Philip Hall Sys admin Data Prompt Inc. Silver Spring Md. uunet!dprmpt!phil ----------------------------- From: flatau Subject: "make" file question Date: 12 Aug 90 00:18:43 GMT Sender: news@ccncsu.colostate.edu To: info-unix@sem.brl.mil I have the following "makefile" file PAT=/ub/path/ FILES=a.f b.f NEW=$(PAT)$(FILES) all: echo $(NEW) =========================== The output from this "make" is /ub/path/a.f b.f but I would like to have /ub/path/a.f /ub/path/b.f Well, the question is: How to append prefix (/ub/path/) to a list of files using "make". flatau@handel.cs.colostate.edu ----------------------------- From: flatau Subject: "make" file question Date: 12 Aug 90 00:18:43 GMT Sender: news@ccncsu.colostate.edu To: info-unix@sem.brl.mil I have the following "makefile" file PAT=/ub/path/ FILES=a.f b.f NEW=$(PAT)$(FILES) all: echo $(NEW) =========================== The output from this "make" is /ub/path/a.f b.f but I would like to have /ub/path/a.f /ub/path/b.f Well, the question is: How to append prefix (/ub/path/) to a list of files using "make". flatau@handel.cs.colostate.edu ----------------------------- From: Tom Christiansen Subject: Re: Timeout on shell command. Date: 12 Aug 90 01:24:12 GMT Sender: news@convex.com Followup-To: comp.unix.questions To: info-unix@sem.brl.mil In article brister@decwrl.dec.com (James Brister) writes: >I'd like to have a shell script run a command, but if that command doesn't >finish in X seconds, then the script should kill it, if the command >finishes sooner then the script should immediately continue. Any ideas on >how one could achieve this? Here's timeout.c; syntax is 'timeout seconds command'. --tom #include #include #include #include int pid,count; union wait status; int bang(); char **commands; main(ac,av) char **av; { if (ac < 3) { usage: fprintf (stderr, "usage: %s seconds command\n",*av); exit (EX_USAGE); } if ((count=atoi(av[1])) < 1) { fprintf (stderr, "seconds (%s) malformed or nonpositive\n",av[1]); goto usage; } commands = &av[2]; switch (pid=fork()) { default: parent(); /* NOTREACHED */ break; case 0: child(); /* NOTREACHED */ case -1: perror("fork"); exit(EX_OSERR); /* NOTREACHED */ } } parent() { (void) signal(SIGALRM,bang); alarm(count); while(wait(&status) != pid) /* VOID */; if (WIFSIGNALED(status)) exit(-status.w_termsig); exit(status.w_retcode); } bang() { fprintf(stderr,"Timeout!\n"); (void) signal(SIGALRM,SIG_DFL); (void) kill(pid,SIGTERM); if (kill(pid,0)) { sleep(1); (void) kill(pid,SIGKILL); } exit(EX_TEMPFAIL); } child() { execvp(*commands,commands); perror(*commands); _exit(EX_DATAERR); /* NOTREACHED */ } /* lint output: * timeout.c: */ -- Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in : Editor too big!" ----------------------------- From: Peter Morreale Subject: make SUFFIXES question..... Date: 12 Aug 90 05:08:50 GMT Sender: news@ncar.ucar.edu To: info-unix@sem.brl.mil Ok all you make wizards, I've got a good one for ya.... Consider the following makefile: ---------------------clip here------------------------- .pp.o: cp $*.pp $*.f .SUFFIXES: $(SUFFIXES) .pp FILES= f1.o compile: $(FILES) @echo "Why isn't .f.o applied?" clean: -rm -f $(FILES) *.f ----------------------clip here-------------------------- Create "f1.pp" and type make. You'll notice that the ".pp.o" rule is executed, and then the compile rule. The question is: Why isn't the default ".f.o" rule executed before the "compile" target? (If you type make again, the ".f.o" rule is executed and all is well....) It seems to me that the sequence of events should be: .pp.o .f.o compile I did a make -dd on this to obtain a listing, but I can't seem to decifer the output. It (the output is enclosed below) I executed this makefile on SunOS 4.0.3c and UNICOS 5.1 with identical results. Thanks for any and all help, -PWM ----------------"make -dd" output------------------------- MAKEFLAGS value: stat(default.mk) doname(default.mk) Looking for % rule for default.mk find_double_suffix_rule(default.mk) find_suffix_rule(default.mk,default.mk,) stat(/usr/include/make/default.mk) doname(/usr/include/make/default.mk) Looking for % rule for /usr/include/make/default.mk find_double_suffix_rule(/usr/include/make/default.mk) find_suffix_rule(/usr/include/make/default.mk,/usr/include/make/default.mk,) SUFFIXES= .o .c .c~ .s .s~ .S .S~ .ln .f .f~ .F .F~ .l .l~ .mod .mod~ .sym .def .def~ .p .p~ .r .r~ .y .y~ .h .h~ .sh .sh~ .cps .cps~ OUTPUT_OPTION = CC= cc CFLAGS = CPPFLAGS = LINT= lint LINTFLAGS = COMPILE.c= $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c LINK.c= $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) LINT.c= $(LINT) $(LINTFLAGS) $(CPPFLAGS) $(TARGET_ARCH) YACC= yacc YFLAGS = YACC.y= $(YACC) $(YFLAGS) LEX= lex LFLAGS = LEX.l= $(LEX) $(LFLAGS) -t FC= f77 FFLAGS = COMPILE.f= $(FC) $(FFLAGS) $(TARGET_ARCH) -c LINK.f= $(FC) $(FFLAGS) $(LDFLAGS) $(TARGET_ARCH) COMPILE.F= $(FC) $(FFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c LINK.F= $(FC) $(FFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) RFLAGS = COMPILE.r= $(FC) $(FFLAGS) $(RFLAGS) $(TARGET_ARCH) -c LINK.r= $(FC) $(FFLAGS) $(RFLAGS) $(LDFLAGS) $(TARGET_ARCH) M2C= m2c M2FLAGS = MODFLAGS = DEFFLAGS = COMPILE.def= $(M2C) $(M2FLAGS) $(DEFFLAGS) $(TARGET_ARCH) COMPILE.mod= $(M2C) $(M2FLAGS) $(MODFLAGS) $(TARGET_ARCH) PC= pc PFLAGS = COMPILE.p= $(PC) $(PFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c LINK.p= $(PC) $(PFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) AS= as ASFLAGS = COMPILE.s= $(AS) $(ASFLAGS) $(TARGET_MACH) COMPILE.S= $(CC) $(ASFLAGS) $(CPPFLAGS) $(TARGET_MACH) -c LD= ld LDFLAGS = LDLIBS = MAKE= make RM= rm -f AR= ar ARFLAGS= rv GET= /usr/sccs/get GFLAGS = HOME= /u1/morreale TERM= adm3a USER= morreale PATH= /u3/gnu/sun4/usr/local/bin:/bin:/usr/ucb:/u1/morreale/bin:.:/usr/bin/X11:/usr/bin:/usr/etc:/usr/local/bin LOGNAME= morreale PWD= /u1/morreale/flatau DISPLAY= laplata:0.0 TERMCAP= la|adm3a|3a:am:do=^J:le=^H:bs:cm=\E=%+\040%+\040:cl=1^Z:co#80:ho=^^:li#24:ma=^K^P:nd=^L:up=^K: EDITOR= /usr/ucb/vi EKBD= vt100 GRAPHCAP= X11 MAP3270= /u1/morreale/.map3270 VISUAL= /usr/ucb/vi PRINTER= scdimagen VIRTUAL_ROOT= / stat(.make.state) MAKEFLAGS= stat(makefile) doname(makefile) Looking for % rule for makefile find_double_suffix_rule(makefile) find_suffix_rule(makefile,makefile,) FILES= f1.o stat(.INIT) doname(.INIT) Looking for % rule for .INIT find_double_suffix_rule(.INIT) stat(compile) doname(compile) @ = stat(f1.o) doname(f1.o) Looking for % rule for f1.o find_double_suffix_rule(f1.o) find_suffix_rule(f1.o,f1,.o) build_suffix_list(.o) .c.o .s.o .S.o .f.o .F.o .l.o .mod.o .p.o .r.o .y.o .pp.o Trying f1.c Trying f1.s Trying f1.S Trying f1.f Trying f1.F Trying f1.l Trying f1.mod Trying f1.p Trying f1.r Trying f1.y Trying f1.pp stat(f1.pp) doname(f1.pp) Looking for % rule for f1.pp find_double_suffix_rule(f1.pp) find_suffix_rule(f1.pp,f1,.pp) build_suffix_list(.pp) Found f1.pp Date(f1.pp)=Sat Aug 11 18:23:07 1990 Date-dependencies(f1.o)=File does not exist Building f1.o using suffix rule for .pp.o because it is out of date relative to f1.pp find_suffix_rule(f1.o,f1.o,) build_suffix_list() .c .f .F .l .mod .p .r .y .sh Trying f1.o.c Trying f1.o.f Trying f1.o.F Trying f1.o.l Trying f1.o.mod Trying f1.o.p Trying f1.o.r Trying f1.o.y Trying f1.o.sh @= f1.o *= f1 <= f1.pp % = ? = f1.pp @ = * = < = % = ? = cp f1.pp f1.f stat(.make.state) stat(f1.o) Date(f1.o)=Younger than any file Date-dependencies(compile)=File does not exist Building compile because it is out of date relative to f1.o Looking for % rule for compile find_double_suffix_rule(compile) @= compile * = < = % = ? = f1.o @ = * = < = % = ? = Why .f.o is not being applied stat(.make.state) stat(compile) stat(.DONE) doname(.DONE) Looking for % rule for .DONE find_double_suffix_rule(.DONE) -- ------------------------------------------------------------------ Peter W. Morreale email: morreale@ncar.ucar.edu Nat'l Center for Atmos Research voice: (303) 497-1293 Scientific Computing Division ----------------------------- From: John G Dobnick Subject: link (ln) with *one* name? Date: 12 Aug 90 05:34:12 GMT Sender: news@uwm.edu To: info-unix@sem.brl.mil Stupid question time (I haven't asked one of these for a while, so I'm due. :-) ] Re: 4.3 "ln". The manpage says ln(1) can be called with only one name. What purpose does this serve? Given that ln(1) is supposed to create "links", I would think you need a minimum of *two* filenames, no? What am I missing here? Manpage extract: LN(1) UNIX Programmer's Manual LN(1) NAME ln - make links SYNOPSIS ln [ -s ] sourcename [ targetname ] ln [ -s ] sourcename1 sourcename2 [ sourcename3 ... ] targetdirectory DESCRIPTION Given one or two arguments, ln creates a link to an existing file sourcename. If targetname is given, the link has that name; targetname may also be a directory in which to place the link; otherwise it is placed in the current directory. If only the directory is specified, the link will be made to the last component of sourcename. The first line under DESCRIPTION can be read as "Given one argument, _ln_ creates a link to an existing file _sourcename_." Um, excuse me, but *what* link to _sourcename_????? Seems to me you need a minimum of two (2) arguments here to do anything useful. Am I correct in assuming that this is just a case of unclear writing? Or am I missing something obvious? (And if so, what?) Nitpickingly, -- John G Dobnick (JGD2) Computing Services Division @ University of Wisconsin - Milwaukee INTERNET: jgd@csd4.csd.uwm.edu ATTnet: (414) 229-5727 UUCP: uunet!uwm!csd4.csd.uwm.edu!jgd "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire ----------------------------- End of INFO-UNIX Digest ***********************