Unix - Frequently Asked Questions (Contents) [Frequent posting]

Archive-name: unix-faq/faq/contents
Version: $Id: contents,v 2.9 1996/06/11 13:08:13 tmatimar Exp $

The following seven articles contain the answers to some Frequently Asked
Questions often seen in comp.unix.questions and comp.unix.shell.
Please don't ask these questions again, they've been answered plenty
of times already - and please don't flame someone just because they may
not have read this particular posting. Thank you.

This collection of documents is Copyright (c) 1994, Ted Timar, except
Part 6, which is Copyright (c) 1994, Pierre Lewis and Ted Timar.
All rights reserved. Permission to distribute the collection is
hereby granted providing that distribution is electronic, no money
is involved, reasonable attempts are made to use the latest version
and all credits and this copyright notice are maintained.
Other requests for distribution will be considered. All reasonable
requests will be granted.

All information here has been contributed with good intentions, but
none of it is guaranteed either by the contributors or myself to be
accurate. The users of this information take all responsibility for
any damage that may occur.

Many FAQs, including this one, are available on the archive site
rtfm.mit.edu in the directory pub/usenet/news.answers.
The name under which a FAQ is archived appears in the "Archive-Name:"
line at the top of the article. This FAQ is archived as
"unix-faq/faq/part[1-7]".

These articles are divided approximately as follows:

1.*) General questions.
2.*) Relatively basic questions, likely to be asked by beginners.
3.*) Intermediate questions.
4.*) Advanced questions, likely to be asked by people who thought
they already knew all of the answers.
5.*) Questions pertaining to the various shells, and the differences.
6.*) An overview of Unix variants.
7.*) An comparison of configuration management systems (RCS, SCCS).

The following questions are answered:

1.1) Who helped you put this list together?
1.2) When someone refers to 'rn(1)' or 'ctime(3)', what does
the number in parentheses mean?
1.3) What does {some strange unix command name} stand for?
1.4) How does the gateway between "comp.unix.questions" and the
"info-unix" mailing list work?
1.5) What are some useful Unix or C books?
1.6) What happened to the pronunciation list that used to be
part of this document?

2.1) How do I remove a file whose name begins with a "-" ?
2.2) How do I remove a file with funny characters in the filename ?
2.3) How do I get a recursive directory listing?
2.4) How do I get the current directory into my prompt?
2.5) How do I read characters from the terminal in a shell script?
2.6) How do I rename "*.foo" to "*.bar", or change file names
to lowercase?
2.7) Why do I get [some strange error message] when I
"rsh host command" ?
2.8) How do I {set an environment variable, change directory} inside a
program or shell script and have that change affect my
current shell?
2.9) How do I redirect stdout and stderr separately in csh?
2.10) How do I tell inside .cshrc if I'm a login shell?
2.11) How do I construct a shell glob-pattern that matches all files
except "." and ".." ?
2.12) How do I find the last argument in a Bourne shell script?
2.13) What's wrong with having '.' in your $PATH ?
2.14) How do I ring the terminal bell during a shell script?
2.15) Why can't I use "talk" to talk with my friend on machine X?
2.16) Why does calendar produce the wrong output?

3.1) How do I find the creation time of a file?
3.2) How do I use "rsh" without having the rsh hang around
until the remote command has completed?
3.3) How do I truncate a file?
3.4) Why doesn't find's "{}" symbol do what I want?
3.5) How do I set the permissions on a symbolic link?
3.6) How do I "undelete" a file?
3.7) How can a process detect if it's running in the background?
3.8) Why doesn't redirecting a loop work as intended? (Bourne shell)
3.9) How do I run 'passwd', 'ftp', 'telnet', 'tip' and other interactive
programs from a shell script or in the background?
3.10) How do I find the process ID of a program with a particular
name from inside a shell script or C program?
3.11) How do I check the exit status of a remote command
executed via "rsh" ?
3.12) Is it possible to pass shell variable settings into an awk program?
3.13) How do I get rid of zombie processes that persevere?
3.14) How do I get lines from a pipe as they are written instead of
only in larger blocks?
3.15) How do I get the date into a filename?
3.16) Why do some scripts start with #! ... ?

4.1) How do I read characters from a terminal without requiring the user
to hit RETURN?
4.2) How do I check to see if there are characters to be read without
actually reading?
4.3) How do I find the name of an open file?
4.4) How can an executing program determine its own pathname?
4.5) How do I use popen() to open a process for reading AND writing?
4.6) How do I sleep() in a C program for less than one second?
4.7) How can I get setuid shell scripts to work?
4.8) How can I find out which user or process has a file open or is using
a particular file system (so that I can unmount it?)
4.9) How do I keep track of people who are fingering me?
4.10) Is it possible to reconnect a process to a terminal after it has
been disconnected, e.g. after starting a program in the background
and logging out?
4.11) Is it possible to "spy" on a terminal, displaying the output
that's appearing on it on another terminal?

5.1) Can shells be classified into categories?
5.2) How do I "include" one shell script from within another
shell script?
5.3) Do all shells have aliases? Is there something else that
can be used?
5.4) How are shell variables assigned?
5.5) How can I tell if I am running an interactive shell?
5.6) What "dot" files do the various shells use?
5.7) I would like to know more about the differences between the
various shells. Is this information available some place?

6.1) Disclaimer and introduction.
6.2) A very brief look at Unix history.
6.3) Main Unix flavors.
6.4) Main Players and Unix Standards.
6.5) Identifying your Unix flavor.
6.6) Brief notes on some well-known (commercial/PD) Unices.
6.7) Real-time Unices.
6.8) Unix glossary.
6.9) Acknowledgements.

7.1) RCS vs SCCS: Introduction
7.2) RCS vs SCCS: How do the interfaces compare?
7.3) RCS vs SCCS: What's in a Revision File?
7.4) RCS vs SCCS: What are the keywords?
7.5) What's an RCS symbolic name?
7.6) RCS vs SCCS: How do they compare for performance?
7.7) RCS vs SCCS: Version Identification.
7.8) RCS vs SCCS: How do they handle with problems?
7.9) RCS vs SCCS: How do they interact with make(1)?
7.10) RCS vs SCCS: Conversion.
7.11) RCS vs SCCS: Support
7.12) RCS vs SCCS: Command Comparison
7.13) RCS vs SCCS: Acknowledgements
7.14) Can I get more information on configuration management systems?

If you're looking for the answer to, say, question 2.5, look in
part 2 and search for the regular expression "^2.5)".

While these are all legitimate questions, they seem to crop up in
comp.unix.questions or comp.unix.shell on an annual basis, usually
followed by plenty of replies (only some of which are correct) and then
a period of griping about how the same questions keep coming up. You
may also like to read the monthly article "Answers to Frequently Asked
Questions" in the newsgroup "news.announce.newusers", which will tell
you what "UNIX" stands for.

With the variety of Unix systems in the world, it's hard to guarantee
that these answers will work everywhere. Read your local manual pages
before trying anything suggested here. If you have suggestions or
corrections for any of these answers, please send them to to
tmatimar@isgtec.com.

--
Ted Timar - tmatimar@isgtec.com
ISG Technologies Inc., 6509 Airport Road, Mississauga, Ontario, Canada L4V 1S7

Archive-name: unix-faq/faq/part1
Version: $Id: part1,v 2.9 1996/06/11 13:07:56 tmatimar Exp $

These seven articles contain the answers to some Frequently Asked
Questions often seen in comp.unix.questions and comp.unix.shell.
Please don't ask these questions again, they've been answered plenty
of times already - and please don't flame someone just because they may
not have read this particular posting. Thank you.

This collection of documents is Copyright (c) 1994, Ted Timar, except
Part 6, which is Copyright (c) 1994, Pierre Lewis and Ted Timar.
All rights reserved. Permission to distribute the collection is
hereby granted providing that distribution is electronic, no money
is involved, reasonable attempts are made to use the latest version
and all credits and this copyright notice are maintained.
Other requests for distribution will be considered. All reasonable
requests will be granted.

All information here has been contributed with good intentions, but
none of it is guaranteed either by the contributors or myself to be
accurate. The users of this information take all responsibility for
any damage that may occur.

Many FAQs, including this one, are available on the archive site
rtfm.mit.edu in the directory pub/usenet/news.answers.
The name under which a FAQ is archived appears in the "Archive-Name:"
line at the top of the article. This FAQ is archived as
"unix-faq/faq/part[1-7]".

These articles are divided approximately as follows:

1.*) General questions.
2.*) Relatively basic questions, likely to be asked by beginners.
3.*) Intermediate questions.
4.*) Advanced questions, likely to be asked by people who thought
they already knew all of the answers.
5.*) Questions pertaining to the various shells, and the differences.
6.*) An overview of Unix variants.
7.*) An comparison of configuration management systems (RCS, SCCS).

This article includes answers to:

1.1) Who helped you put this list together?
1.2) When someone refers to 'rn(1)' or 'ctime(3)', what does
the number in parentheses mean?
1.3) What does {some strange unix command name} stand for?
1.4) How does the gateway between "comp.unix.questions" and the
"info-unix" mailing list work?
1.5) What are some useful Unix or C books?
1.6) What happened to the pronunciation list that used to be
part of this document?

If you're looking for the answer to, say, question 1.5, and want to skip
everything else, you can search ahead for the regular expression "^1.5)".

While these are all legitimate questions, they seem to crop up in
comp.unix.questions or comp.unix.shell on an annual basis, usually
followed by plenty of replies (only some of which are correct) and then
a period of griping about how the same questions keep coming up. You
may also like to read the monthly article "Answers to Frequently Asked
Questions" in the newsgroup "news.announce.newusers", which will tell
you what "UNIX" stands for.

With the variety of Unix systems in the world, it's hard to guarantee
that these answers will work everywhere. Read your local manual pages
before trying anything suggested here. If you have suggestions or
corrections for any of these answers, please send them to to
tmatimar@isgtec.com.

----------------------------------------------------------------------

Subject: Who helped you put this list together?
Date: Thu Mar 18 17:16:55 EST 1993

1.1) Who helped you put this list together?

This document was one of the first collections of Frequently Asked
Questions. It was originally compiled in July 1989.

I took over the maintenance of this list. Almost all of the work
(and the credit) for generating this compilation was done by
Steve Hayman.

We also owe a great deal of thanks to dozens of Usenet readers who
submitted questions, answers, corrections and suggestions for this
list. Special thanks go to Maarten Litmaath, Guy Harris and
Jonathan Kamens, who have all made many especially valuable
contributions.

Part 5 of this document (shells) was written almost entirely by
Matthew Wicks <wicks@dcdmjw.fnal.gov>.

Part 6 of this document (Unix flavours) was written almost entirely by
Pierre (P.) Lewis <lew@bnr.ca>.

Where possible the author of each question and the date it was last
updated is given at the top. Unfortunately, I only started this
practice recently, and much of the information is lost. I was also
negligent in keeping track of who provided updates to questions.
Sorry to those who have made valuable contributions, but did not
receive the credit and recognition that they legitimately deserve.

I make this document available in *roff format (ms and mm macro
packages). Andrew Cromarty has also converted it into Texinfo format.
Marty Leisner <leisner@sdsp.mc.xerox.com> cleaned up the Texinfo
version.

Major contributors to this document who may or may not be
recognized elsewhere are:

Steve Hayman <shayman@Objectario.com>
Pierre Lewis <lew@bnr.ca>
Jonathan Kamens <jik@mit.edu>
Tom Christiansen <tchrist@mox.perl.com>
Maarten Litmaath <maart@nat.vu.nl>
Guy Harris <guy@auspex.com>

The formatted versions are available for anonymous ftp from
ftp.wg.omron.co.jp under pub/unix-faq/docs .

------------------------------

Subject: When someone refers to 'rn(1)' ... the number in parentheses mean?
Date: Tue, 13 Dec 1994 16:37:26 -0500

1.2) When someone refers to 'rn(1)' or 'ctime(3)', what does
the number in parentheses mean?

It looks like some sort of function call, but it isn't. These
numbers refer to the section of the "Unix manual" where the
appropriate documentation can be found. You could type
"man 3 ctime" to look up the manual page for "ctime" in section 3
of the manual.

The traditional manual sections are:

1 User-level commands
2 System calls
3 Library functions
4 Devices and device drivers
5 File formats
6 Games
7 Various miscellaneous stuff - macro packages etc.
8 System maintenance and operation commands

Some Unix versions use non-numeric section names. For instance,
Xenix uses "C" for commands and "S" for functions. Some newer
versions of Unix require "man -s# title" instead of "man # title".

Each section has an introduction, which you can read with "man #
intro" where # is the section number.

Sometimes the number is necessary to differentiate between a
command and a library routine or system call of the same name.
For instance, your system may have "time(1)", a manual page about
the 'time' command for timing programs, and also "time(3)", a
manual page about the 'time' subroutine for determining the
current time. You can use "man 1 time" or "man 3 time" to
specify which "time" man page you're interested in.

You'll often find other sections for local programs or even
subsections of the sections above - Ultrix has sections 3m, 3n,
3x and 3yp among others.

------------------------------

Subject: What does {some strange unix command name} stand for?
Date: Thu Mar 18 17:16:55 EST 1993

1.3) What does {some strange unix command name} stand for?

awk = "Aho Weinberger and Kernighan"

This language was named by its authors, Al Aho, Peter
Weinberger and Brian Kernighan.

grep = "Global Regular Expression Print"

grep comes from the ed command to print all lines matching a
certain pattern

g/re/p

where "re" is a "regular expression".

fgrep = "Fixed GREP".

fgrep searches for fixed strings only. The "f" does not stand
for "fast" - in fact, "fgrep foobar *.c" is usually slower than
"egrep foobar *.c" (Yes, this is kind of surprising. Try it.)

Fgrep still has its uses though, and may be useful when searching
a file for a larger number of strings than egrep can handle.

egrep = "Extended GREP"

egrep uses fancier regular expressions than grep. Many people
use egrep all the time, since it has some more sophisticated
internal algorithms than grep or fgrep, and is usually the
fastest of the three programs.

cat = "CATenate"

catenate is an obscure word meaning "to connect in a series",
which is what the "cat" command does to one or more files. Not
to be confused with C/A/T, the Computer Aided Typesetter.

gecos = "General Electric Comprehensive Operating Supervisor"

When GE's large systems division was sold to Honeywell,
Honeywell dropped the "E" from "GECOS".

Unix's password file has a "pw_gecos" field. The name is a
real holdover from the early days. Dennis Ritchie has reported:

"Sometimes we sent printer output or batch jobs
to the GCOS machine. The gcos field in the password file
was a place to stash the information for the $IDENT card.
Not elegant."

nroff = "New ROFF"
troff = "Typesetter new ROFF"

These are descendants of "roff", which was a re-implementation
of the Multics "runoff" program (a program that you'd use to
"run off" a good copy of a document).

tee = T

From plumbing terminology for a T-shaped pipe splitter.

bss = "Block Started by Symbol"

Dennis Ritchie says:

Actually the acronym (in the sense we took it up; it may
have other credible etymologies) is "Block Started by
Symbol." It was a pseudo-op in FAP (Fortran Assembly [-er?]
Program), an assembler for the IBM 704-709-7090-7094
machines. It defined its label and set aside space for a
given number of words. There was another pseudo-op, BES,
"Block Ended by Symbol" that did the same except that the
label was defined by the last assigned word + 1. (On these
machines Fortran arrays were stored backwards in storage
and were 1-origin.)

The usage is reasonably appropriate, because just as with
standard Unix loaders, the space assigned didn't have to be
punched literally into the object deck but was represented
by a count somewhere.

biff = "BIFF"

This command, which turns on asynchronous mail notification,
was actually named after a dog at Berkeley.

I can confirm the origin of biff, if you're interested.
Biff was Heidi Stettner's dog, back when Heidi (and I, and
Bill Joy) were all grad students at U.C. Berkeley and the
early versions of BSD were being developed. Biff was
popular among the residents of Evans Hall, and was known
for barking at the mailman, hence the name of the command.

Confirmation courtesy of Eric Cooper, Carnegie Mellon University

rc (as in ".cshrc" or "/etc/rc") = "RunCom"

"rc" derives from "runcom", from the MIT CTSS system, ca. 1965.

'There was a facility that would execute a bunch of
commands stored in a file; it was called "runcom" for "run
commands", and the file began to be called "a runcom."

"rc" in Unix is a fossil from that usage.'

Brian Kernighan & Dennis Ritchie, as told to Vicki Brown

"rc" is also the name of the shell from the new Plan 9
operating system.

Perl = "Practical Extraction and Report Language"
Perl = "Pathologically Eclectic Rubbish Lister"

The Perl language is Larry Wall's highly popular
freely-available completely portable text, process, and file
manipulation tool that bridges the gap between shell and C
programming (or between doing it on the command line and
pulling your hair out). For further information, see the
Usenet newsgroup comp.lang.perl.misc.

Don Libes' book "Life with Unix" contains lots more of these
tidbits.

------------------------------

Subject: How does the gateway between "comp.unix.questions" ... work ?
Date: Thu Mar 18 17:16:55 EST 1993

1.4) How does the gateway between "comp.unix.questions" and the
"info-unix" mailing list work?

"info-unix" and "unix-wizards" are mailing list versions of
comp.unix.questions and comp.unix.wizards respectively.
There should be no difference in content between the
mailing list and the newsgroup.

To get on or off either of these lists, send mail to
info-unix-request@brl.mil or unix-wizards-request@brl.mil.
Be sure to use the '-Request'. Don't expect an immediate response.

Here are the gory details, courtesy of the list's maintainer,
Bob Reschly.

==== postings to info-UNIX and UNIX-wizards lists ====

Anything submitted to the list is posted; I do not moderate
incoming traffic -- BRL functions as a reflector. Postings
submitted by Internet subscribers should be addressed to the list
address (info-UNIX or UNIX- wizards); the '-request' addresses
are for correspondence with the list maintainer [me]. Postings
submitted by USENET readers should be addressed to the
appropriate news group (comp.unix.questions or
comp.unix.wizards).

For Internet subscribers, received traffic will be of two types;
individual messages, and digests. Traffic which comes to BRL
from the Internet and BITNET (via the BITNET-Internet gateway) is
immediately resent to all addressees on the mailing list.
Traffic originating on USENET is gathered up into digests which
are sent to all list members daily.

BITNET traffic is much like Internet traffic. The main
difference is that I maintain only one address for traffic
destined to all BITNET subscribers. That address points to a list
exploder which then sends copies to individual BITNET
subscribers. This way only one copy of a given message has to
cross the BITNET-Internet gateway in either direction.

USENET subscribers see only individual messages. All messages
originating on the Internet side are forwarded to our USENET
machine. They are then posted to the appropriate newsgroup.
Unfortunately, for gatewayed messages, the sender becomes
"news@brl-adm". This is currently an unavoidable side-effect of
the software which performs the gateway function.

As for readership, USENET has an extremely large readership - I
would guess several thousand hosts and tens of thousands of
readers. The master list maintained here at BRL runs about two
hundred fifty entries with roughly ten percent of those being
local redistribution lists. I don't have a good feel for the
size of the BITNET redistribution, but I would guess it is
roughly the same size and composition as the master list.
Traffic runs 150K to 400K bytes per list per week on average.

------------------------------

Subject: What are some useful Unix or C books?
Date: Thu Mar 18 17:16:55 EST 1993

1.5) What are some useful Unix or C books?

Mitch Wright (mitch@cirrus.com) maintains a useful list of Unix
and C books, with descriptions and some mini-reviews. There are
currently 167 titles on his list.

You can obtain a copy of this list by anonymous ftp from
ftp.rahul.net (192.160.13.1), where it's "pub/mitch/YABL/yabl".
Send additions or suggestions to mitch@cirrus.com.

Samuel Ko (kko@sfu.ca) maintains another list of Unix books.
This list contains only recommended books, and is therefore
somewhat shorter. This list is also a classified list, with
books grouped into categories, which may be better if you are
looking for a specific type of book.

You can obtain a copy of this list by anonymous ftp from
rtfm.mit.edu, where it's "pub/usenet/news.answers/books/unix".
Send additions or suggestions to kko@sfu.ca.

If you can't use anonymous ftp, email the line "help" to
"ftpmail@decwrl.dec.com" for instructions on retrieving
things via email.

------------------------------

Subject: What happened to the pronunciation list ... ?
Date: Thu Mar 18 17:16:55 EST 1993

1.6) What happened to the pronunciation list that used to be part of this
document?

From its inception in 1989, this FAQ document included a
comprehensive pronunciation list maintained by Maarten Litmaath
(thanks, Maarten!). It was originally created by Carl Paukstis
<carlp@frigg.isc-br.com>.

It has been retired, since it is not really relevant to the topic
of "Unix questions". You can still find it as part of the
widely-distributed "Jargon" file (maintained by Eric S. Raymond,
eric@snark.thyrsus.com) which seems like a much more appropriate
forum for the topic of "How do you pronounce /* ?"

If you'd like a copy, you can ftp one from ftp.wg.omron.co.jp
(133.210.4.4), it's "pub/unix-faq/docs/Pronunciation-Guide".

------------------------------

End of unix/faq Digest part 1 of 7
**********************************

--
Ted Timar - tmatimar@isgtec.com
ISG Technologies Inc., 6509 Airport Road, Mississauga, Ontario, Canada L4V 1S7

Archive-name: unix-faq/faq/part4
Version: $Id: part4,v 2.9 1996/06/11 13:07:56 tmatimar Exp $

These seven articles contain the answers to some Frequently Asked
Questions often seen in comp.unix.questions and comp.unix.shell.
Please don't ask these questions again, they've been answered plenty
of times already - and please don't flame someone just because they may
not have read this particular posting. Thank you.

This collection of documents is Copyright (c) 1994, Ted Timar, except
Part 6, which is Copyright (c) 1994, Pierre Lewis and Ted Timar.
All rights reserved. Permission to distribute the collection is
hereby granted providing that distribution is electronic, no money
is involved, reasonable attempts are made to use the latest version
and all credits and this copyright notice are maintained.
Other requests for distribution will be considered. All reasonable
requests will be granted.

All information here has been contributed with good intentions, but
none of it is guaranteed either by the contributors or myself to be
accurate. The users of this information take all responsibility for
any damage that may occur.

Many FAQs, including this one, are available on the archive site
rtfm.mit.edu in the directory pub/usenet/news.answers.
The name under which a FAQ is archived appears in the "Archive-Name:"
line at the top of the article. This FAQ is archived as
"unix-faq/faq/part[1-7]".

These articles are divided approximately as follows:

1.*) General questions.
2.*) Relatively basic questions, likely to be asked by beginners.
3.*) Intermediate questions.
4.*) Advanced questions, likely to be asked by people who thought
they already knew all of the answers.
5.*) Questions pertaining to the various shells, and the differences.
6.*) An overview of Unix variants.
7.*) An comparison of configuration management systems (RCS, SCCS).

This article includes answers to:

4.1) How do I read characters from a terminal without requiring the user
to hit RETURN?
4.2) How do I check to see if there are characters to be read without
actually reading?
4.3) How do I find the name of an open file?
4.4) How can an executing program determine its own pathname?
4.5) How do I use popen() to open a process for reading AND writing?
4.6) How do I sleep() in a C program for less than one second?
4.7) How can I get setuid shell scripts to work?
4.8) How can I find out which user or process has a file open or is using
a particular file system (so that I can unmount it?)
4.9) How do I keep track of people who are fingering me?
4.10) Is it possible to reconnect a process to a terminal after it has
been disconnected, e.g. after starting a program in the background
and logging out?
4.11) Is it possible to "spy" on a terminal, displaying the output
that's appearing on it on another terminal?

If you're looking for the answer to, say, question 4.5, and want to skip
everything else, you can search ahead for the regular expression "^4.5)".

While these are all legitimate questions, they seem to crop up in
comp.unix.questions or comp.unix.shell on an annual basis, usually
followed by plenty of replies (only some of which are correct) and then
a period of griping about how the same questions keep coming up. You
may also like to read the monthly article "Answers to Frequently Asked
Questions" in the newsgroup "news.announce.newusers", which will tell
you what "UNIX" stands for.

With the variety of Unix systems in the world, it's hard to guarantee
that these answers will work everywhere. Read your local manual pages
before trying anything suggested here. If you have suggestions or
corrections for any of these answers, please send them to to
tmatimar@isgtec.com.

----------------------------------------------------------------------

Subject: How do I read characters ... without requiring the user to hit RETURN?
Date: Thu Mar 18 17:16:55 EST 1993

4.1) How do I read characters from a terminal without requiring the user
to hit RETURN?

Check out cbreak mode in BSD, ~ICANON mode in SysV.

If you don't want to tackle setting the terminal parameters
yourself (using the "ioctl(2)" system call) you can let the stty
program do the work - but this is slow and inefficient, and you
should change the code to do it right some time:

#include <stdio.h>
main()
{
int c;

printf("Hit any character to continue\n");
/*
* ioctl() would be better here; only lazy
* programmers do it this way:
*/
system("/bin/stty cbreak"); /* or "stty raw" */
c = getchar();
system("/bin/stty -cbreak");
printf("Thank you for typing %c.\n", c);

exit(0);
}

Several people have sent me various more correct solutions to
this problem. I'm sorry that I'm not including any of them here,
because they really are beyond the scope of this list.

You might like to check out the documentation for the "curses"
library of portable screen functions. Often if you're interested
in single-character I/O like this, you're also interested in
doing some sort of screen display control, and the curses library
provides various portable routines for both functions.

------------------------------

Subject: How do I check to see if there are characters to be read ... ?
Date: Thu Mar 18 17:16:55 EST 1993

4.2) How do I check to see if there are characters to be read without
actually reading?

Certain versions of UNIX provide ways to check whether characters
are currently available to be read from a file descriptor. In
BSD, you can use select(2). You can also use the FIONREAD ioctl,
which returns the number of characters waiting to be read, but
only works on terminals, pipes and sockets. In System V Release
3, you can use poll(2), but that only works on streams. In Xenix
- and therefore Unix SysV r3.2 and later - the rdchk() system call
reports whether a read() call on a given file descriptor will block.

There is no way to check whether characters are available to be
read from a FILE pointer. (You could poke around inside stdio
data structures to see if the input buffer is nonempty, but that
wouldn't work since you'd have no way of knowing what will happen
the next time you try to fill the buffer.)

Sometimes people ask this question with the intention of writing
if (characters available from fd)
read(fd, buf, sizeof buf);
in order to get the effect of a nonblocking read. This is not
the best way to do this, because it is possible that characters
will be available when you test for availability, but will no
longer be available when you call read. Instead, set the
O_NDELAY flag (which is also called FNDELAY under BSD) using the
F_SETFL option of fcntl(2). Older systems (Version 7, 4.1 BSD)
don't have O_NDELAY; on these systems the closest you can get to
a nonblocking read is to use alarm(2) to time out the read.

------------------------------

Subject: How do I find the name of an open file?
Date: Thu Mar 18 17:16:55 EST 1993

4.3) How do I find the name of an open file?

In general, this is too difficult. The file descriptor may
be attached to a pipe or pty, in which case it has no name.
It may be attached to a file that has been removed. It may
have multiple names, due to either hard or symbolic links.

If you really need to do this, and be sure you think long
and hard about it and have decided that you have no choice,
you can use find with the -inum and possibly -xdev option,
or you can use ncheck, or you can recreate the functionality
of one of these within your program. Just realize that
searching a 600 megabyte filesystem for a file that may not
even exist is going to take some time.

------------------------------

Subject: How can an executing program determine its own pathname?
Date: Thu Mar 18 17:16:55 EST 1993

4.4) How can an executing program determine its own pathname?

Your program can look at argv[0]; if it begins with a "/", it is
probably the absolute pathname to your program, otherwise your
program can look at every directory named in the environment
variable PATH and try to find the first one that contains an
executable file whose name matches your program's argv[0] (which
by convention is the name of the file being executed). By
concatenating that directory and the value of argv[0] you'd
probably have the right name.

You can't really be sure though, since it is quite legal for one
program to exec() another with any value of argv[0] it desires.
It is merely a convention that new programs are exec'd with the
executable file name in argv[0].

For instance, purely a hypothetical example:

#include <stdio.h>
main()
{
execl("/usr/games/rogue", "vi Thesis", (char *)NULL);
}

The executed program thinks its name (its argv[0] value) is
"vi Thesis". (Certain other programs might also think that
the name of the program you're currently running is "vi Thesis",
but of course this is just a hypothetical example, don't
try it yourself :-)

------------------------------

Subject: How do I use popen() to open a process for reading AND writing?
Date: Thu Mar 18 17:16:55 EST 1993

4.5) How do I use popen() to open a process for reading AND writing?

The problem with trying to pipe both input and output to an
arbitrary slave process is that deadlock can occur, if both
processes are waiting for not-yet-generated input at the same
time. Deadlock can be avoided only by having BOTH sides follow a
strict deadlock-free protocol, but since that requires
cooperation from the processes it is inappropriate for a
popen()-like library function.

The 'expect' distribution includes a library of functions that a
C programmer can call directly. One of the functions does the
equivalent of a popen for both reading and writing. It uses ptys
rather than pipes, and has no deadlock problem. It's portable to
both BSD and SV. See question 3.9 for more about 'expect'.

------------------------------

Subject: How do I sleep() in a C program for less than one second?
Date: Thu Mar 18 17:16:55 EST 1993

4.6) How do I sleep() in a C program for less than one second?

The first thing you need to be aware of is that all you can
specify is a MINIMUM amount of delay; the actual delay will
depend on scheduling issues such as system load, and could be
arbitrarily large if you're unlucky.

There is no standard library function that you can count on in
all environments for "napping" (the usual name for short
sleeps). Some environments supply a "usleep(n)" function which
suspends execution for n microseconds. If your environment
doesn't support usleep(), here are a couple of implementations
for BSD and System V environments.

The following code is adapted from Doug Gwyn's System V emulation
support for 4BSD and exploits the 4BSD select() system call.
Doug originally called it 'nap()'; you probably want to call it
"usleep()";

/*
usleep -- support routine for 4.2BSD system call emulations
last edit: 29-Oct-1984 D A Gwyn
*/

extern int select();

int
usleep( usec ) /* returns 0 if ok, else -1 */
long usec; /* delay in microseconds */
{
static struct /* `timeval' */
{
long tv_sec; /* seconds */
long tv_usec; /* microsecs */
} delay; /* _select() timeout */

delay.tv_sec = usec / 1000000L;
delay.tv_usec = usec % 1000000L;

return select( 0, (long *)0, (long *)0, (long *)0, &delay );
}

On System V you might do it this way:

/*
subseconds sleeps for System V - or anything that has poll()
Don Libes, 4/1/1991

The BSD analog to this function is defined in terms of
microseconds while poll() is defined in terms of milliseconds.
For compatibility, this function provides accuracy "over the long
run" by truncating actual requests to milliseconds and
accumulating microseconds across calls with the idea that you are
probably calling it in a tight loop, and that over the long run,
the error will even out.

If you aren't calling it in a tight loop, then you almost
certainly aren't making microsecond-resolution requests anyway,
in which case you don't care about microseconds. And if you did,
you wouldn't be using UNIX anyway because random system
indigestion (i.e., scheduling) can make mincemeat out of any
timing code.

Returns 0 if successful timeout, -1 if unsuccessful.

*/

#include <poll.h>

int
usleep(usec)
unsigned int usec; /* microseconds */
{
static subtotal = 0; /* microseconds */
int msec; /* milliseconds */

/* 'foo' is only here because some versions of 5.3 have
* a bug where the first argument to poll() is checked
* for a valid memory address even if the second argument is 0.
*/
struct pollfd foo;

subtotal += usec;
/* if less then 1 msec request, do nothing but remember it */
if (subtotal < 1000) return(0);
msec = subtotal/1000;
subtotal = subtotal%1000;
return poll(&foo,(unsigned long)0,msec);
}

Another possibility for nap()ing on System V, and probably other
non-BSD Unices is Jon Zeeff's s5nap package, posted to
comp.sources.misc, volume 4. It does require a installing a
device driver, but works flawlessly once installed. (Its
resolution is limited to the kernel HZ value, since it uses the
kernel delay() routine.)

Many newer versions of Unix have a nanosleep function.

------------------------------

Subject: How can I get setuid shell scripts to work?
Date: Thu Mar 18 17:16:55 EST 1993

4.7) How can I get setuid shell scripts to work?

[ This is a long answer, but it's a complicated and frequently-asked
question. Thanks to Maarten Litmaath for this answer, and
for the "indir" program mentioned below. ]

Let us first assume you are on a UNIX variant (e.g. 4.3BSD or
SunOS) that knows about so-called `executable shell scripts'.
Such a script must start with a line like:

#!/bin/sh

The script is called `executable' because just like a real (binary)
executable it starts with a so-called `magic number' indicating
the type of the executable. In our case this number is `#!' and
the OS takes the rest of the first line as the interpreter for
the script, possibly followed by 1 initial option like:

#!/bin/sed -f

Suppose this script is called `foo' and is found in /bin,
then if you type:

foo arg1 arg2 arg3

the OS will rearrange things as though you had typed:

/bin/sed -f /bin/foo arg1 arg2 arg3

There is one difference though: if the setuid permission bit for
`foo' is set, it will be honored in the first form of the
command; if you really type the second form, the OS will honor
the permission bits of /bin/sed, which is not setuid, of course.

----------

OK, but what if my shell script does NOT start with such a `#!'
line or my OS does not know about it?

Well, if the shell (or anybody else) tries to execute it, the OS
will return an error indication, as the file does not start with
a valid magic number. Upon receiving this indication the shell
ASSUMES the file to be a shell script and gives it another try:

/bin/sh shell_script arguments

But we have already seen that a setuid bit on `shell_script' will
NOT be honored in this case!

----------

Right, but what about the security risks of setuid shell scripts?

Well, suppose the script is called `/etc/setuid_script', starting
with:

#!/bin/sh

Now let us see what happens if we issue the following commands:

$ cd /tmp
$ ln /etc/setuid_script -i
$ PATH=.
$ -i

We know the last command will be rearranged to:

/bin/sh -i

But this command will give us an interactive shell, setuid to the
owner of the script!
Fortunately this security hole can easily be closed by making the
first line:

#!/bin/sh -

The `-' signals the end of the option list: the next argument `-i'
will be taken as the name of the file to read commands from, just
like it should!

---------

There are more serious problems though:

$ cd /tmp
$ ln /etc/setuid_script temp
$ nice -20 temp &
$ mv my_script temp

The third command will be rearranged to:

nice -20 /bin/sh - temp

As this command runs so slowly, the fourth command might be able
to replace the original `temp' with `my_script' BEFORE `temp' is
opened by the shell! There are 4 ways to fix this security hole:

1) let the OS start setuid scripts in a different, secure way
- System V R4 and 4.4BSD use the /dev/fd driver to pass the
interpreter a file descriptor for the script

2) let the script be interpreted indirectly, through a frontend
that makes sure everything is all right before starting the
real interpreter - if you use the `indir' program from
comp.sources.unix the setuid script will look like this:

#!/bin/indir -u
#?/bin/sh /etc/setuid_script

3) make a `binary wrapper': a real executable that is setuid and
whose only task is to execute the interpreter with the name of
the script as an argument

4) make a general `setuid script server' that tries to locate the
requested `service' in a database of valid scripts and upon
success will start the right interpreter with the right
arguments.

---------

Now that we have made sure the right file gets interpreted, are
there any risks left?

Certainly! For shell scripts you must not forget to set the PATH
variable to a safe path explicitly. Can you figure out why?
Also there is the IFS variable that might cause trouble if not
set properly. Other environment variables might turn out to
compromise security as well, e.g. SHELL... Furthermore you must
make sure the commands in the script do not allow interactive
shell escapes! Then there is the umask which may have been set
to something strange...

Etcetera. You should realise that a setuid script `inherits' all
the bugs and security risks of the commands that it calls!

All in all we get the impression setuid shell scripts are quite a
risky business! You may be better off writing a C program instead!

------------------------------

Subject: How can I find out which user or process has a file open ... ?
Date: Thu Mar 18 17:16:55 EST 1993

4.8) How can I find out which user or process has a file open or is using
a particular file system (so that I can unmount it?)

Use fuser (system V), fstat (BSD), ofiles (public domain) or
pff (public domain). These programs will tell you various things
about processes using particular files.

A port of the 4.3 BSD fstat to Dynix, SunOS and Ultrix
can be found in archives of comp.sources.unix, volume 18.

pff is part of the kstuff package, and works on quite a few systems.
Instructions for obtaining kstuff are provided in question 3.10.

I've been informed that there is also a program called lsof. I
don't know where it can be obtained.

Michael Fink <Michael.Fink@uibk.ac.at> adds:

If you are unable to unmount a file system for which above tools
do not report any open files make sure that the file system that
you are trying to unmount does not contain any active mount
points (df(1)).

------------------------------

Subject: How do I keep track of people who are fingering me?
>From: Jonathan I. Kamens
>From: malenovi@plains.NoDak.edu (Nikola Malenovic)
Date: Thu, 29 Sep 1994 07:28:37 -0400

4.9) How do I keep track of people who are fingering me?

Generally, you can't find out the userid of someone who is
fingering you from a remote machine. You may be able to
find out which machine the remote request is coming from.
One possibility, if your system supports it and assuming
the finger daemon doesn't object, is to make your .plan file a
"named pipe" instead of a plain file. (Use 'mknod' to do this.)

You can then start up a program that will open your .plan file
for writing; the open will block until some other process (namely
fingerd) opens the .plan for reading. Now you can feed whatever you
want through this pipe, which lets you show different .plan
information every time someone fingers you. One program for
doing this is the "planner" package in volume 41 of the
comp.sources.misc archives.

Of course, this may not work at all if your system doesn't
support named pipes or if your local fingerd insists
on having plain .plan files.

Your program can also take the opportunity to look at the output
of "netstat" and spot where an incoming finger connection is
coming from, but this won't get you the remote user.

Getting the remote userid would require that the remote site be
running an identity service such as RFC 931. There are now three
RFC 931 implementations for popular BSD machines, and several
applications (such as the wuarchive ftpd) supporting the server.
For more information join the rfc931-users mailing list,
rfc931-users-request@kramden.acf.nyu.edu.

There are three caveats relating to this answer. The first is
that many NFS systems won't recognize the named pipe correctly.
This means that trying to read the pipe on another machine will
either block until it times out, or see it as a zero-length file,
and never print it.

The second problem is that on many systems, fingerd checks that
the .plan file contains data (and is readable) before trying to
read it. This will cause remote fingers to miss your .plan file
entirely.

The third problem is that a system that supports named pipes
usually has a fixed number of named pipes available on the
system at any given time - check the kernel config file and
FIFOCNT option. If the number of pipes on the system exceeds the
FIFOCNT value, the system blocks new pipes until somebody frees
the resources. The reason for this is that buffers are allocated
in a non-paged memory.

------------------------------

Subject: Is it possible to reconnect a process to a terminal ... ?
Date: Thu Mar 18 17:16:55 EST 1993

4.10) Is it possible to reconnect a process to a terminal after it has
been disconnected, e.g. after starting a program in the background
and logging out?

Most variants of Unix do not support "detaching" and "attaching"
processes, as operating systems such as VMS and Multics support.
However, there are three freely redistributable packages which can
be used to start processes in such a way that they can be later
reattached to a terminal.

The first is "screen," which is described in the
comp.sources.unix archives as "Screen, multiple windows on a CRT"
(see the "screen-3.2" package in comp.sources.misc, volume 28.)
This package will run on at least BSD, System V r3.2 and SCO UNIX.

The second is "pty," which is described in the comp.sources.unix
archives as a package to "Run a program under a pty session" (see
"pty" in volume 23). pty is designed for use under BSD-like
system only.

The third is "dislocate," which is a script that comes with the
expect distribution. Unlike the previous two, this should run on
all UNIX versions. Details on getting expect can be found in
question 3.9 .

None of these packages is retroactive, i.e. you must have
started a process under screen or pty in order to be able to
detach and reattach it.

------------------------------

Subject: Is it possible to "spy" on a terminal ... ?
Date: Wed, 28 Dec 1994 18:35:00 -0500

4.11) Is it possible to "spy" on a terminal, displaying the output
that's appearing on it on another terminal?

There are a few different ways you can do this, although none
of them is perfect:

* kibitz allows two (or more) people to interact with a shell
(or any arbitary program). Uses include:

- watching or aiding another person's terminal session;
- recording a conversation while retaining the ability to
scroll backwards, save the conversation, or even edit it
while in progress;
- teaming up on games, document editing, or other cooperative
tasks where each person has strengths and weakness that
complement one another.

kibitz comes as part of the expect distribution. See question 3.9.

kibitz requires permission from the person to be spyed upon. To
spy without permission requires less pleasant approaches:

* You can write a program that rummages through Kernel structures
and watches the output buffer for the terminal in question,
displaying characters as they are output. This, obviously, is
not something that should be attempted by anyone who does not
have experience working with the Unix kernel. Furthermore,
whatever method you come up with will probably be quite
non-portable.

* If you want to do this to a particular hard-wired terminal all
the time (e.g. if you want operators to be able to check the
console terminal of a machine from other machines), you can
actually splice a monitor into the cable for the terminal. For
example, plug the monitor output into another machine's serial
port, and run a program on that port that stores its input
somewhere and then transmits it out *another* port, this one
really going to the physical terminal. If you do this, you have
to make sure that any output from the terminal is transmitted
back over the wire, although if you splice only into the
computer->terminal wires, this isn't much of a problem. This is
not something that should be attempted by anyone who is not very
familiar with terminal wiring and such.

* The latest version of screen includes a multi-user mode.
Some details about screen can be found in question 4.10.

* If the system being used has streams (SunOS, SVR4), the advise
program that was posted in volume 28 of comp.sources.misc can
be used. AND it doesn't requirethat it be run first (you do
have to configure your system in advance to automatically push
the advise module on the stream whenever a tty or pty is opened).

------------------------------

End of unix/faq Digest part 4 of 7
**********************************

--
Ted Timar - tmatimar@isgtec.com
ISG Technologies Inc., 6509 Airport Road, Mississauga, Ontario, Canada L4V 1S7