unix-wizards-request@BRL.MIL (UNIX Wizards) (05/08/89)
INFO-UNIX Digest Sun, 05 Mar 1989 V7#012
Today's Topics:
Re: vi-like editor for the IBM PC
Re: Sys V accounting
Re: How to determine file being redirected to in C
Re: vi-like editor for the IBM PC
Re: signals
termcap and terminfo definitions for 32 line mode
vi for pc
linking "C" and FORTRAN functions together
Problems getting SLIP operational
troff and eof
Re: X Terminals for Sun hosts over dial up phone lines
Re: Socket question
Re: linking "C" and FORTRAN functions together
Shell..
cleanup script needed
sh script hangs after first external command
-----------------------------------------------------------------
From: "Roger A. Cornelius" <rac@sherpa.uucp>
Subject: Re: vi-like editor for the IBM PC
Date: 3 Mar 89 20:55:15 GMT
To: info-unix@sem.brl.mil
From article <7374@killer.DALLAS.TX.US>, by wnp@killer.DALLAS.TX.US (Wolf Paul):
- In article <776@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes:
->ked@garnet.berkeley.edu (Earl H. Kinmonth) wrote:
->> MKS (Mortice Kern Systems)
-
->compress
->uncompress
->zcat
-
- Unfortunately these handle only 12-bit compression and can't handle
- UNIX-compressed files (usually 16-bit)
If I remember correctly, the MKS compress programs will handle up to 14
bit compression. One thing I don't like about them though, is they
won't compress/decompress in place. They only write to stdout, so to
do something like 'compress -d *.c', requires a for loop or something
similar.
Roger
-----------------------------
From: Paul De Bra <debra@alice.uucp>
Subject: Re: Sys V accounting
Date: 4 Mar 89 04:22:21 GMT
To: info-unix@sem.brl.mil
In article <18528@adm.BRL.MIL> mchinni@ARDEC.ARPA (Michael J. Chinni, SMCAR-CCS-E) writes:
>Help!
>
>I am trying to set up the Sys V accouinting system on our Gould NP1 (bsd 4.3).
>
>I understand everything (I think) except the /usr/adm/fee file used by
>"chargefee". My manual says "chargefee loginname feeunit" will give me a line
>in /usr/adm/fee:
> uid loginname 0 0 0 0 0 0 0 0 0 0 feeunit
>but does not explain what the zeros and the feeunit mean. It does say that uid
>is the UID of user loginname.
>
>We intend to charge users fees for various services used on our system, but we
>can't set fees until we know what we can charge for (other than connect time).
>
>Also, is there a way to charge users by an account-charge-code ? For instance,
>user1 and user2 are doing work on project x and project y. Can we charge for
>project x work separate from project y work rather than charging user1 and
>user2?
>
Unix accounting is in general unreliable and primitive. There are a number of
questions to ask yourself before using much of the accounting software:
1) you can charge for disk-blocks used per user. but if user A has 2 files
of 512 bytes and user B has 1 1k file, should user A be charged twice as
much just because the system block size is 1k ? (actually 1k is the fragment
size, not the block size)
2) you can charge for connect time, but should I be charged extra if my
compile takes longer because of other activity on the system?
3) you can charge for cpu time, but should I be charged for cpu time spent
on page-faults because of other processes occupying memory while my
program runs? i.e. is it fair that exactly the same job doesn't cost
the same every time you run it?
4) you may want to encourage running jobs at lower priority but the accounting
does NOT record this. Do you want to charge as much for low priority jobs
as for high priority jobs? (you have no other alternative)
5) after some relatively short time the recorded times become negative because
of errors in the processing of the times that supposedly are some weird
but nonetheless unsigned type. how are you going to solve that?
As for your other question, Unix only knows about users and groups, and the
accounting only about users. If a user works on 2 projects that need to be
charged separately, you will need 2 logins. By putting both logins in a
separate group the user can still write all his files by giving the group
write permission.
My conclusion is that the accounting isn't accurate enough for precise
record keeping, but for rough estimates it can be used. It does take some
effort to read the reports and figure out what went wrong, because the
records are often wrong.
Paul.
--
------------------------------------------------------
|debra@research.att.com | uunet!research!debra |
------------------------------------------------------
-----------------------------
From: "David J. Camp" <david@wubios.wustl.edu>
Subject: Re: How to determine file being redirected to in C
Date: 3 Mar 89 21:24:50 GMT
Keywords: redirection
To: info-unix@sem.brl.mil
In article <7419@pyr.gatech.EDU> curci@stat.fsu.edu (Ray Curci (scri)) writes:
:>In article <10@sherpa.UUCP> rac@sherpa.UUCP (Roger A. Cornelius) writes:
:>>... Anyway, can someone tell me how to determine (in C)
:>>if output is being redirected, or more precisely, how to determine the
:>>file output is being redirected to.
:>>Roger rac@sherpa
:>> uunet!sherpa!rac
:>
:>You may want to investigate the isatty() function call. I believe that
:>you can use something like: isatty(stdout) which will tell you if
:>standard out is going to a terminal (the usual case), or if it has been
:>redirected via a pipe or into a file.
:>
:>ray curci
I just received umpteen replies about this. The function call is
isatty(fileno(stdout));
-David-
--
Bitnet: david@wubios.wustl ^ Mr. David J. Camp
Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics
uucp: uunet!wucs1!wubios!david v 660 South Euclid
Washington University Medical School Saint Louis, MO 63110
-----------------------------
From: "Billy G. Allie" <bga@bgalli.eds.com>
Subject: Re: vi-like editor for the IBM PC
Date: 4 Mar 89 05:13:13 GMT
To: info-unix@sem.brl.mil
In article <7374@killer.DALLAS.TX.US>, wnp@killer.DALLAS.TX.US (Wolf Paul) writes:
< [refering to the MKS cpio command]
< Very good! It has a (non-standard) option to compress each file before
< adding it to the archive; unfortunately limited by the fact that MKS'
< compress does not support 16-bit compression. Another limitation is
< that of course, such compressed cpio archives are not directly
< unpackable under UNIX -- you have to unpack them, and then manually
< run each extracted file through uncompress.
Archives created with the -z (non-standard) option of the MKS cpio command
can be unpacked with the following command (filename is the name of the
compressed archive file):
zcat filename | cpio -ic
assuming that the '-c' option was used in creating the archive. In fact the
'-z' option is meant equivalent with the following pipelines:
MKS command UNIX pipeline
---------------------- ---------------------------------------
cpio -oz<other options> <--> cpio -o<other options> | compress -b 14
cpio -iz<other options> <--> uncompress | cpio -i<other options>
BTW, the -z option was added because MS-DOS does not have multi-tasking or
true pipes. To compress the archive on MS-DOS using pipes would require
a temporary file big enough to hold the content of the entire archive. By
building the compression into cpio, this temporary file is not needed.
< [refering to the MKS compress, uncompress and zcat commands]
< Unfortunately these handle only 12-bit compression and can't handle
< UNIX-compressed files (usually 16-bit)
These commands can handle up to 14-bit compression modes. This is not a
great concern to me since I have a version of compress that will handle
16-bit compression on MS-DOS.
One fact that wasn't mentioned is the capability of the MKS Korn shell has
of passing up to 5Kbytes of arguments to the MS-DOS programs. Of course, the
programs must know how to access these arguments (all MKS toolkit programs do
this).
I have no connection to MKS except as a satisfied customer.
--
____ | Billy G. Allie | Internet..: bga@bgalli.eds.com
| /| | 7436 Hartwell | UUCP......: uunet!{mcf|edsews}!bgalli!bga
|-/-|----- | Dearborn, MI 48126 | Compuserve: 76337,2061
|/ |LLIE | (313) 582-1540 | Genie.....: BGALLIE
-----------------------------
From: Bob Lenk <rml@hpfcdc.hp.com>
Subject: Re: signals
Date: 4 Mar 89 01:28:26 GMT
To: info-unix@sem.brl.mil
> Does Unix make any guarantees about when a signal will be delivered? The
> man page for kill doesn't say anything about this in any of the versions
> at my disposal.
In all implementations I know of a signal sent by a process to itself
will be delivered before kill() returns, with one possible exception.
If the process happens to receive some other signal that it is catching
with exactly the right timing, it is possible that it will execute the
signal handler for that other signal and then return from kill() without
delivering the signal sent by kill(). This possibility exists in
most non-reliable signal implementations (eg. V7, SVR2). It does not
exist in 4.2 or 4.3. I'm not sure about 4.1 or SVR3 (with their
variant of reliable signals).
This is not mentioned in any manual I know of. POSIX (IEEE 1003.1) states:
If the value of _pid_ causes _sig_ to be generated for the
sending process, either _sig_ or at least one pending
unblocked signal shall be delivered to the sending process
before the kill() function returns.
It also has similar wording for sigprocmask() (similar to sigsetmask()
in 4.2/4.3 or sigrelse() in 4.1/SVR3).
> Looking at the man page actually confused me further. My manuals for
> 4.1BSD, 4.2BSD and SunOS4.0 claim that kill(0, sig) sends sig to all
> *other* processes in the process group (SunOS4.0 is particularly
> explicit about this). 4.3BSD and SunOS 3.2 just say all processes in
> the process group. Presumably the latter description is the correct
> one for all these systems?
It appears to be correct for at least 4.2 and 4.3. For kill(-1, sig)
the calling process is not sent the signal in these systems, but is
sent the signal in System V. Much time was spent agonizing over that
difference in POSIX deliberations, but no one ever questioned that
kill(0, sig) goes to the whole pgrp including the sender (which POSIX
requires). I'd never noticed that in the 4.2 manuals before.
> (Sixth edition refers to "all other
> processes which have the same controlling typewriter".)
And furthermore makes the statement that "In no case is it possible for
a process to kill itself". It's not clear if that is only supposed to
refer to a pid of 0, or even to an explicit kill(getpid(), sig). I
don't have V6 source handy.
Bob Lenk
hplabs!hpfcla!rml
rml%hpfcla@hplabs.hp.com
-----------------------------
From: "David J. Camp" <david@wubios.wustl.edu>
Subject: termcap and terminfo definitions for 32 line mode
Date: 4 Mar 89 01:19:33 GMT
Keywords: 43 line termcap terminfo vt100 ncsa telnet
To: info-unix@sem.brl.mil
I am trying to set up termcap and terminfo entries for a 43 line
terminal. Actually, it is an IBMPC with an EGA running
Clarkson_NCSA_Telnet on an Ungermann-Bass NICPS2 adapter.
My host is a Sun 3/260 running SunOS 4.0.1.
I know that I can type 'stty rows 42' once I have connected to configure
the correct mode. What I want to do instead is to have a termcap entry
for that terminal that will specify that mode automatically when I enter
the terminal type to tset.
How do I specify an 'stty' option from termcap or terminfo? Is there
somewhere else that I need to specify this option instead?
-David-
--
Bitnet: david@wubios.wustl ^ Mr. David J. Camp
Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics
uucp: uunet!wucs1!wubios!david v 660 South Euclid
Washington University Medical School Saint Louis, MO 63110
--
Bitnet: david@wubios.wustl ^ Mr. David J. Camp
Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics
uucp: uunet!wucs1!wubios!david v 660 South Euclid
Washington University Medical School Saint Louis, MO 63110
-----------------------------
From: "David J. Camp" <david@wubios.wustl.edu>
Subject: vi for pc
Date: 4 Mar 89 02:02:04 GMT
Keywords: vi ibm pc
To: info-unix@sem.brl.mil
A pd vi clone has been placed in
simtel20.arpa::pd1:<msdos.editor>VI-19A.ARC
-David-
--
Bitnet: david@wubios.wustl ^ Mr. David J. Camp
Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics
uucp: uunet!wucs1!wubios!david v 660 South Euclid
Washington University Medical School Saint Louis, MO 63110
-----------------------------
From: "STEVEN E. PARKER" <850181p@aucs.uucp>
Subject: linking "C" and FORTRAN functions together
Date: 2 Mar 89 21:10:10 GMT
To: info-unix@sem.brl.mil
I am trying to find out how to link a fortran library
subroutine "SVD" into a "C" program.
I know that you have to compile the souce
to .o files but what do you do next???
ld does not seem to do the right thing...
There might be a flag that I am not setting
correctly.
thanks ....
-----------------------------------------------------------
Steven E. Parker Acadia Univ. School of Computer Science
Wolfville N.S. Canada BOP1XO
UUCP: {uunet|watmath|utai|garfield}!dalcs!aucs!850181p
BITNET: 850181p@Acadia
Internet: 850181p%Acadia.BITNET@CUNYVM.CUNY.EDU
-----------------------------------------------------------
-----------------------------
From: "Don W. Willits" <willitd@mist.cs.orst.edu>
Subject: Problems getting SLIP operational
Date: 4 Mar 89 20:59:22 GMT
Sender: usenet@CS.ORST.EDU
Followup-To: comp.unix, comp.unix.wizards
Keywords: SLIP
To: info-unix@sem.brl.mil
We're attempting to set up the version of SLIP (serial line IP) included with
4.3 BSD, and have been encountering some problems.
We've been successful in establishing an IP connections across the
serial line using slattach and ifconfig commands. The connection has
been tested using telnet, ftp and ping.
The problem is we're suffering seemingly random and significant packet
loss. Anywhere between 0 and 70% packet loss while performing a ping
across the serial line. All the sessions we've opened suffer from *VERY*
erratic response time, followed by eventual lock-up on both ends. And
large packets (500+ bytes in ping, for example) almost always fail.
We've tried different cables, different serial cards - with no luck.
We think this is a software problem, but even that is uncertain.
Can anyone out there in "netland" offer any advice or suggestions?
Thanx!
The Oregon State University SLIP group.
Don Willits
Erik Bennett
Tony Petrossian
Terry Skaggs
INTERNET: slip@ulysses.cs.orst.edu
UUCP: tektronix!orstcs!bennete
mjolnir!bennete@cs.orst.edu
-----------------------------
From: Nick Crossley <nick@ccicpg.uucp>
Subject: troff and eof
Date: 4 Mar 89 09:07:26 GMT
Keywords: troff, .em, .bp
To: info-unix@sem.brl.mil
I need to get some text printed after the end of a troff document.
So, I use .em to set up an end-of-input trap, and in that I put my
text. So far, so good. However, I want that text on a new page.
So, I add a .bp request before the text. Unfortunately, this does not
work. n/troff (and ditroff) exit *within* the .bp call and never process
the additional text I want on the next page.
Actually, it is a bit more complex than that. There is a page footer
trap, invoked during the .bp in my .em macro. This page footer does get
processed. It does a 'bp, and that is the one which never returns.
Does anyone know of some way of getting a .em macro to add a trailing page
of text??
--
<<< standard disclaimers >>>
Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA. (714) 458-7282
uunet!ccicpg!nick / nick@ccicpg.UUCP
-----------------------------
From: Mike Hoegeman <mh@wlbr.eaton.com>
Subject: Re: X Terminals for Sun hosts over dial up phone lines
Date: 4 Mar 89 23:31:34 GMT
To: info-unix@sem.brl.mil
In article <16174@mimsy.UUCP> alberto@tove.umd.edu.UUCP (Jose Alberto Fernandez R) writes:
> The Idea of use POSTSCRIPT as the comunication Protocol is not a bad one.
> Actually, there is not a tool as this for NeWS?, must be very easy to
I think bruce schwartz made something like this for NeWS. check out the
SEX tape (sun user group software exchange tape) or the NeWS stuff
on tumtum.umd.edu
> implement. I like the ideas of NeWS very much (was my first window
> system), but the speed of the server make me change to X. I can't wait
> forever and ever each time I move a window.
I've found the Performance of NeWS to be just fine. What does "waiting forever
and ever to paint, each time i move a window mean ?" sounds to me like you're
not doing something right.
-----------------------------
From: Andrew Hume <andrew@alice.uucp>
Subject: Re: Socket question
Date: 4 Mar 89 23:57:09 GMT
To: info-unix@sem.brl.mil
i understand the problem to be that if you tear down a socket that you
got as a result of listening to an address that you 'bind'ed to
and then attempt to bind again, you get an address in use error.
this is annoyingly correct behaviour. some standard says the address
is taken for up to 4 minutes. i have a similar problem and i adopt
the sendmail approach (it has to be good for something, right?)
and set some socket option to reuse the address and then just rebind
over the top.
-----------------------------
From: Anthony Mutiso <anthony@alberta.uucp>
Subject: Re: linking "C" and FORTRAN functions together
Date: 5 Mar 89 00:38:10 GMT
To: info-unix@sem.brl.mil
In article <1599@aucs.UUCP>, 850181p@aucs.UUCP (STEVEN E. PARKER) writes:
> I am trying to find out how to link a fortran library
> subroutine "SVD" into a "C" program.
> I know that you have to compile the souce
> to .o files but what do you do next???
Have a look at your Unix programmers manual "Fortran and Friends". It
does say something about how to solve your problem, if memory serves.
In general here is what you need to understand:-
(1) Fortran data types are passed to functions by default in
a manner that is different to the default C manner (especially
text string, which have to include a byte length).
(2) The f77 compiler will compile fortran code to names with
two underscores. e.g.. the fortran procedure "map" will
compile to the identifier "__map", while the C name "map"
will compile to the identifier "_map". So to access the
fortran subroutine in a C file the name "_map" will have
to be used to reach the fortran name "map". Watch out of
course for subroutine naming conventions, ie. calling a C
function from the fortran program.
I hope this is sufficient to get you going.
Anthony.
--------------------------------------------------------------------------------
Anthony Mutiso Email
Department of Computing Science. anthony@UAlberta.AB.CA
University of Alberta or anthony@alberta.UUCP
Edmonton, Alberta
CANADA
Tel: (office) 403-432-2821
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Disclaimer:
...... angle and ministers of grace defend us all......
...... lord protect the foolish.....
--------------------------------------------------------------------------------
-----------------------------
From: aviz@lanai.cs.ucla.edu
Subject: Shell..
Date: 5 Mar 89 03:03:07 GMT
Sender: news@cs.ucla.edu
To: info-unix@sem.brl.mil
How can I run a shell command in C? Like running UUCP, or SendMail, or any
other program?
And can I make the C program work interactively with the other application?
thanks...
-----------------------------
From: rkumar@buddha.usc.edu
Subject: cleanup script needed
Date: 4 Mar 89 19:54:47 GMT
Sender: news@oberon.usc.edu
To: info-unix@sem.brl.mil
This may be quite silly to the UNIX wizards.
1) Frequently I need to erase unnecessary files to save space.
It would be nice to have a script which removes all
the files with a specified extension, e.g., .dvi or .aux
not only in the current directory, but in all the
children directories recursively.
Will rm -r *.dvi do the job? Since it is an "rm" command,
I don't want to try it out ...
2) Sometimes I create a file in a directory which is deep
down in a directory hierarchy. Any quick way to search for
a file, given its name/template?
Thanks
Ravi
--- :-)
Pardon me, but UNIX *is* male chauvinistic. Look at all those
*man* commands!
--- :-(
-----------------------------
From: Scot E Wilcoxon <sewilco@datapg.mn.org>
Subject: sh script hangs after first external command
Date: 5 Mar 89 02:03:19 GMT
To: info-unix@sem.brl.mil
A program is doing a system(3) call to execute a shell script.
The script hangs after doing the first command which is not a shell
builtin. Any ideas what can do that?
This problem is taking place in a System V.2 Honeywell-Bull XPS-100
(X-20, I think), with a single 68020 processor.
A `ps -ef` shows two processes, "sh -c /usr/sewilco/script" and
"/usr/sewilco/script". This second process uses cpu time quickly,
about one second cpu per elapsed second.
The script sets some environment variables, then does
date >>/tmp/sew1
date >>/tmp/sew1
The first date reaches /tmp/sew1, but not the second. If "pwd" or
"echo" (both shell builtins) is substituted their output both reach
/tmp/sew1, and the script hangs further along at the next external
command.
The parent program is fairly active, so I checked number of open files
and file locking, among other things:
I'm not running out of file descriptors, as a close(1)
loop reported only 9 files closed before executing
system(3)..and the script still hung.
There are no mandatory file locks in use.
A shared memory segment was detached before executing
system(3), so that can't be a problem.
Two nephew processes and other terminals continue running, so
the system has not crashed.
When the parent is killed, the two system(3) processes continue to
exist until `kill -9` used. If the problem was process limit, the
hung process should have continued when the parent and nephews
exited. There are fewer than 10 related processes simultaneously
active, and process limit seems to be much higher than that.
Any ideas what can cause a shell script to spin, eating cpu?
--
Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco
Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco
I'm just reversing entropy while waiting for the Big Crunch.
-----------------------------
End of INFO-UNIX Digest
***********************
From: Mike Muuss (UNIX Wizards) <unix-wizards-request@BRL.MIL>
To: Will Martin <iunix1@st-louis-emh2.army.mil>
cc:
Subject: Re: Request for missing issues