Diffs to the Frequently Asked Questions postings
Steve Hayman
sahayman at iuvax.cs.indiana.edu
Wed Apr 3 08:15:06 AEST 1991
Here are the most recent changes to parts 1 and 2 of the
Frequently Asked Questions articles, which have just been
posted. You can find the full articles elsewhere in
comp.unix.questions. You can also ftp the most recent version from
iuvax.cs.indiana.edu (129.79.254.192), where it's
"pub/Unix-Questions.part1" and "pub/Unix-Questions.part2".
(IUVax also runs a mail server, for those of you unable to ftp.
Send the line "HELP" to "mailserv at iuvax.cs.indiana.edu" to get started.)
*** /tmp/,RCSt1a09321 Tue Apr 2 17:13:57 1991
--- part2 Tue Apr 2 17:13:48 1991
***************
*** 1,6 ****
Subject: Frequently Asked Questions about Unix - with Answers [Monthly posting]
! [Last changed: $Date: 91/03/01 17:04:08 $ by $Author: sahayman $]
This article contains the answers to some Frequently Asked Questions
often seen in comp.unix.questions. Please don't ask these questions
--- 1,6 ----
Subject: Frequently Asked Questions about Unix - with Answers [Monthly posting]
! [Last changed: $Date: 91/04/02 17:13:41 $ by $Author: sahayman $]
This article contains the answers to some Frequently Asked Questions
often seen in comp.unix.questions. Please don't ask these questions
***************
*** 204,218 ****
crummy entry, and see if you can convince it and your local NFS
daemon to rename the file to something without slashes.
! If that doesn't work or isn't possible, drastic action by root is
! required. Use "ls -i" to find the inode number of this bogus
! file, then unmount the file system and use "clri" to clear the
! inode, and "fsck" the file system with your fingers crossed.
! This destroys the information in the file. If you want to
! keep it, you can try:
!
! create a new directory in the same parent directory as the
! one containing the bad file name;
move everything you can (i.e. everything but the file with
the bad name) from the old directory to the new one;
--- 204,218 ----
crummy entry, and see if you can convince it and your local NFS
daemon to rename the file to something without slashes.
! If that doesn't work or isn't possible, you'll need help from your
! system manager, who will have to try the one of the following.
! Use "ls -i" to find the inode number of this bogus file, then
! unmount the file system and use "clri" to clear the inode, and
! "fsck" the file system with your fingers crossed. This destroys
! the information in the file. If you want to keep it, you can try:
!
! create a new directory in the same parent directory as the one
! containing the bad file name;
move everything you can (i.e. everything but the file with
the bad name) from the old directory to the new one;
***************
*** 241,247 ****
by crawling around in the raw file system.
Use "fsdb", if you have it.
- If none of these work, find your system manager.
3) How do I get a recursive directory listing?
--- 241,246 ----
***************
*** 556,565 ****
for f in *; do
g=`expr "xxx$f" : 'xxx\(.*\)' | tr '[A-Z]' '[a-z]'`
mv "$f" "$g"
-
done
! The `expr' command will always print the filename, even if it equals`
`-n' or if it contains a System V escape sequence like `\c'.
Some versions of "tr" require the [ and ], some don't. It happens
--- 555,563 ----
for f in *; do
g=`expr "xxx$f" : 'xxx\(.*\)' | tr '[A-Z]' '[a-z]'`
mv "$f" "$g"
done
! The `expr' command will always print the filename, even if it equals
`-n' or if it contains a System V escape sequence like `\c'.
Some versions of "tr" require the [ and ], some don't. It happens
***************
*** 1339,1349 ****
unlucky.
There is no standard library function that you can count on in all
! environments for "napping" (the usual name for short sleeps). The
! following code is adapted from Doug Gwyn's System V emulation
! support for 4BSD and exploits the 4BSD select() system call. On
! System V you might be able to use poll() in a similar way.
/*
nap -- support routine for 4.2BSD system call emulations
--- 1337,1352 ----
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.
+ (You probably want to call it "usleep()" instead of "nap()" )
+
/*
nap -- support routine for 4.2BSD system call emulations
***************
*** 1369,1374 ****
--- 1372,1419 ----
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 */
+
+ 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((struct pollfd *)0,(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
***************
*** 1542,1548 ****
which often you don't want;
.[!.]* (Newer shells only; some shells use a "^" instead of
! the "!"; POSIX shells must accept the "!")
Matches all files that begin with a "." and are
followed by a non-"."; unfortunately this will miss
"..foo";
--- 1587,1596 ----
which often you don't want;
.[!.]* (Newer shells only; some shells use a "^" instead of
! the "!"; POSIX shells must accept the "!", but may
! accept a "^" as well; all portable application shall
! not use an unquoted "^" immediately following the "[")
!
Matches all files that begin with a "." and are
followed by a non-"."; unfortunately this will miss
"..foo";
***************
*** 1559,1567 ****
an external program or two and use backquote substitution.
This is pretty good:
! `ls -a | sed -e '/^\.$/d' -e '/^\.\.$/d'`
! but even it will mess up on files with newlines in their names.
32) How do I find the last argument in a Bourne shell script?
--- 1607,1618 ----
an external program or two and use backquote substitution.
This is pretty good:
! `ls -a | sed -e '/^\.$/d' -e '/^\.\.$/d'`
!
! (or `ls -A` in some Unix versions)
! but even it will mess up on files with newlines, IFS characters
! or wildcards in their names.
32) How do I find the last argument in a Bourne shell script?
***************
*** 1679,1685 ****
part of this document?
Since its inception in 1989, this FAQ document included a comprehensive
! pronunciation list created by Maarten Litmaath (thanks, Maarten!).
I've retired it, since it is not really relevant to the topic of
"Unix questions". You can still find it as part of the
--- 1730,1737 ----
part of this document?
Since its inception in 1989, this FAQ document included a comprehensive
! pronunciation list maintained by Maarten Litmaath (thanks, Maarten!).
! (Does anyone know who *created* it?)
I've retired it, since it is not really relevant to the topic of
"Unix questions". You can still find it as part of the
More information about the Comp.unix.questions
mailing list