Mail not delivered yet, still trying
SMTP MAILER
postmaster at nusc.arpa
Sat Dec 3 04:52:35 AEST 1988
----Mail status follows----
Have been unable to send your mail to <baynes at drum>,
will keep trying for a total of three days.
At that time your mail will be returned.
----Transcript of message follows----
Date: 1 Dec 88 08:10:00 EST
From: <info-unix at BRL.MIL>
Subject: INFO-UNIX Digest V6#031
To: "baynes" <baynes at drum>
Received: from SEM.BRL.MIL by nusc.arpa with SMTP ; Thu, 1 Dec 88 08:09:16 EST
Received: from SEM.BRL.MIL by SEM.brl.MIL id ab04903; 1 Dec 88 3:26 EST
Received: from sem.brl.mil by SEM.BRL.MIL id aa04894; 1 Dec 88 2:46 EST
Date: Thu, 01 Dec 88 02:46:12 EST
From: The Moderator (Mike Muuss) <Info-Unix-Request at BRL.MIL>
To: INFO-UNIX at BRL.MIL
Reply-To: INFO-UNIX at BRL.MIL
Subject: INFO-UNIX Digest V6#031
Message-ID: <8812010246.aa04894 at SEM.BRL.MIL>
INFO-UNIX Digest Thu, 01 Dec 1988 V6#031
Today's Topics:
Adventure shell
Troff "grap" question
Re: ls -l
Re: * Question
Re: Info needed on workstations
Re: GCOS field
System 5.3.1 signal() replacement?
signals to running processes
Re: How to mimic the terminal driver?
Pre-formatted tapes for HP drives
A UUCP question
SVR3 Manuals
Re: GCOS field
Re: A UUCP question
Re: * Question
Re: How to mimic the terminal driver?
Re: * Question
Re: Adventure shell
Re: GCOS field
Re: Troff "grap" question
Re: Anonymous ftp's
Nroff/Troff Floating Displays
Re: Pre-formatted tapes for HP drives
Re: ls -l
Re: * Question
Re: ls -l
Re: SCCS: how to handle multiple developers/streams
Re: ls -l
Re: fio library routines
-----------------------------------------------------------------
From: Jon Joshua <jjoshua at topaz.rutgers.edu>
Subject: Adventure shell
Date: 30 Nov 88 06:27:13 GMT
Keywords: anyone got it?
To: info-unix at sem.brl.mil
I heard someone mention a shell called the adventure shell.
This shell turned Unix into an adventure game where you could pick up
files and drop them elsewhere etc... Does anyone have more info on
this shell? Better yet, does anyone have a copy?
JOn.
--
_____________________________________________________________________________
|o| Jonathan Joshua jjoshua at topaz.rutgers.edu Why not... |o|
|o| Nothing better to do |o|
|o| Anything is possible, |o|
\o| except for skiing through a revolving door. |o|
\_ ____/ \ |o|
\/ \ _______________________________ ______________________|o|
\___ / \/
\/
-----------------------------
From: Erik Ekkel <ekkel at idca.tds.philips.nl>
Subject: Troff "grap" question
Date: 29 Nov 88 11:44:55 GMT
To: info-unix at sem.brl.mil
I want to use the troff "grap" preprocessor to plot a graph. The problem is
that the input has as x-coordinate weeknumbers. So the range of the
x-axis is e.g. 8801:8852, 8901:8952, ..........
How can i tell "grap" that there is a gap in the x-axis; that week 8901 is the
successor of week 8852 and NOT 8900 !
--
__
/ Erik Ekkel, Philips PTDSN (+31 55 433301)
/-- __ o / Domain: ekkel at idca.tds.philips.nl
/___ _/ (_(_ /( Uucp : ...!mcvax!philapd!ekkel
-----------------------------
From: James Logan III <logan at vsedev.vse.com>
Subject: Re: ls -l
Date: 30 Nov 88 04:01:12 GMT
Keywords: ls
To: info-unix at sem.brl.mil
In article <838 at nih-csl.UUCP> ted at nih-csl.UUCP (ted persky) writes:
#
# When a user enters the command "ls -l" on a directory, a slew of
# information is given with such things as last-modified time,
# number of links, owner, group, etc. Such data is usually stored
# in the inode. My question is this: does the "ls" program need to
# open each file, to look at its inode in order to display this
# data to standard output?
#
No, the "inode" is stored in an "inode table" stored near the
beginning of a disk partition. It is basically an array of
structures containing the information supplied by the stat(2)
call (links, mode, UID, GID, etc.) plus a block number map for
the file.
This block number map consists of 13 block numbers. The first 9
block numbers refer to the first 9 blocks of the file's data.
The 10th block number, known as the "single indirect" is the
block number of another block on the disk containing more of the
file's block numbers.
The 11th, known as the "double indirect" is the block number of a
disk block containing a list of block numbers that refer to disk
blocks that contain more of the file's block numbers.
The 12th, know as the "triple indirect" is the block number of a
disk block containing a list of block numbers that refer to disk
blocks that contain block numbers of disk blocks containing more
block numbers of the file's data.
Confused? I thought so.
Of course, short files would not require all of these block
numbers, but the blocks are there if you ever need a large file.
(Try a 4 gigabyte file to be exact...)
Anyway, the simple answer to your question is: "Yes, Virginia,
there IS a Santa Clause." No, Wait... um... oh yeah, the "ls"
command simply calls the stat(2) system call for each file you
specified and the stat(2) call reads the inode table entry
associated with that filename. The "ls" command does NOT read
a single byte of the file's data.
-Jim
--
Jim Logan logan at vsedev.vse.com
(703) 892-0002 uucp: ..!uunet!vsedev!logan
inet: logan%vsedev.vse.com at uunet.uu.net
-----------------------------
From: James Logan III <logan at vsedev.vse.com>
Subject: Re: * Question
Date: 30 Nov 88 04:27:29 GMT
To: info-unix at sem.brl.mil
In article <17661 at adm.BRL.MIL> wmartin at almsa-1.arpa (Will Martin -- AMXAL-RI) writes:
#I have a query about filename generation/wildcard expansion. I have looked
#in the man pages and in several UNIX books, and talked about this locally,
#but haven't found an explanation. I've tested it on both Sys V (on a Sperry
#Unisys) and 4.3 BSD (on a VAX 750). It seems to be a consistent difference
#between sh and csh.
#
#Given the situation where you are trying to redirect output to a directory
#in some path structure, where you do have write access, but want to save
#time in typing:
#
#Say my login directory is /usr/wm. I also own a directory in another filesystem:
#"/data/save-backups". I am sitting in /usr/wm and want to put some data into
#that other directory, but want to avoid typing out "save-backups" all the time.
#There is nothing else under /data that begins with "sa".
#
#So I do this:
#
#cat foo > /data/sa*/bar or cat foo >> /data/sa*/bar
#
#Under "sh", no matter whether or not "bar" exists in that destination
#directory, this won't work. I get the response:
#
#sh: /data/sa*/bar: cannot create
#
#The shell will not expand that "*" to fill out the directory name. I have to
#type out the full "/data/save-backups/bar" pathname to get it to work.
#
Every version of the Bourne shell that I have seen does not
interpret the filename expansion characters after a redirection
symbol. I believe this is to prevent
cat foobar >/data/sa*/bar
from expanding into
cat foobar >/data/sally/bar /data/sandy/bar
which would effectively be the same as
cat foobar /data/sandy/bar >/data/sally/bar
which was probably not intended.
The Korn shell gets this right by expanding the wildcard only if one
file matches. If more than one file matches, the wildcard is used
literally.
-Jim
--
Jim Logan logan at vsedev.vse.com
(703) 892-0002 uucp: ..!uunet!vsedev!logan
inet: logan%vsedev.vse.com at uunet.uu.net
-----------------------------
From: "G.Pavlov" <pavlov at hscfvax.harvard.edu>
Subject: Re: Info needed on workstations
Date: 30 Nov 88 05:20:50 GMT
Posted: Wed Nov 30 00:20:50 1988
To: info-unix at sem.brl.mil
In article <6060017 at hpcupt1.HP.COM>, markd at hpcupt1.HP.COM (Mark Diekhans) writes:
> I am considering buying a Unix workstation in the less than $15K department.
> So far, the Sun-3s and the IBM PC RT look likely contenders. Does anyone have
> any input on these or other UNIX workstations, both hardware and the versions
> of UNIX for each? Thanks,
How about an HP 9000 Model 340 ?
greg pavlov, fstrf, amherst, ny
-----------------------------
From: Jean-Pierre Radley <jpr at dasys1.uucp>
Subject: Re: GCOS field
Date: 30 Nov 88 04:03:40 GMT
To: info-unix at sem.brl.mil
In article <1257 at vsedev.VSE.COM> logan at vsedev.VSE.COM (James Logan III) writes:
>Does anyone know what GCOS really stands for and where it came from?
In my flavor of unix, that's described as the "Comment" field.
In volume 1 of the Unix Programmer's Manual, the old green books, that
field was listed as
GCOS job number, box number, optional GCOS user-id
and the manual page went on to state:
The GCOS field is used only when communicating with that system,
and in other installations can contain any desired information.
Elsewhere in the old green books, I get the implicit, not explicit,
information that GCOS referred to a typesetting system at Murray Hill at
the time that Osanna & Co. were inventing troff.
--
Jean-Pierre Radley Honi soit jpr at dasys1.UUCP
New York, New York qui mal ...!hombre!jpradley!jpr
CIS: 76120,1341 y pense ...!hombre!trigere!jpr
-----------------------------
From: Timothy Reed <treed at dasys1.uucp>
Subject: System 5.3.1 signal() replacement?
Date: 30 Nov 88 04:28:17 GMT
To: info-unix at sem.brl.mil
I don't have access to a 5.3.1 system, but I understand that signal()
has been replaced by a new set of signal handlers. Could someone kindly
mail me a man page (I think that the replacement is sigset()?) or
a brief summary of snytax and usage (and signals!) - doing so will
make my life much easier!!!
Thanks!
Timothy Reed
--
NAME : Timothy Reed
PHONE: 7188527454
UUCP : ..!cmcl2!phri!dasys1!treed || ..!uunet!dasys1!treed
MAIL : 300 Union St^MBkyn, NY^M11231
-----------------------------
From: Jonathan Sweedler <cjosta at taux01.uucp>
Subject: signals to running processes
Date: 30 Nov 88 07:01:28 GMT
To: info-unix at sem.brl.mil
I have a program that takes a long time to finish running. From time
to time (sometimes never, sometimes more frequently) I would like to
find out the current status. The way I accomplish this is to send one
of the user defined signals (SIGUSR1 - no. 30) to the process. The
process has a signal handler that catches this signal and writes out
the current state (number of loops done, how long it has been running,
when it will finish, etc.). This all works fine but only I (the owner
of the process) can send the signal. If my boss, for example, wants to
look at the status of the process, he can't.
My questions are these:
1) Is there any way for someone who is not the owner of a process to
send the process a signal?
2) Or, is there another way for a random user to cause a program to
asynchronously print out a status report (or perform some action) once
it has started running?
I know I can have the program print out a status report every
x minutes/hours/loops/whatever, but I don't want this. I want the
report to be printed out only when specified to do so.
I could also probably (haven't done this yet) write a shell script that
would send the signal and is setuid to me but then if different people
run the program (other than me), there must be different shell scripts
that are setuid to each person who might run the program. For example,
if either user A or user B might run the program, but it is user C that
wants the progress report, then there must be a shell script setuid'ed
to A and one setuid'ed to B. Is there a cleaner approach?
--
Jonathan Sweedler === National Semiconductor Israel
UUCP: ...!{amdahl,hplabs,decwrl}!nsc!taux01!cjosta
Domain: cjosta at taux01.nsc.com
-----------------------------
From: The Demented Teddy Bear <dieter at titan.nmt.edu>
Subject: Re: How to mimic the terminal driver?
Date: 30 Nov 88 10:47:39 GMT
Sender: dieter at nmtsun.nmt.edu
To: info-unix at sem.brl.mil
In article <35 at umvlsi.ECS.UMASS.EDU>, vishwana at umvlsi (Chidambaram Vishwanath) writes:
>
> I have taken upon myself the following task, viz.,: I want to add
> an extra feature to the C-shell whereby I can recall earlier commands
> by pressing an arrow-key.
By far the easiest solution to this problem is to use "ile", which was
posted to comp.unix.wizards on July 7, 1988 by bpendlet at esunix.uucp.
(Bob Pendleton, message id 907 at esunix.uucp, to be exact). It fits
between the user and his program by grabbing a pty and looking at
everything that goes by.
There are three problems with this package that I'm aware of.
1) Your version of unix must understand the concept of pty. This seems
to be fairly common these days, so it isn't too much of a problem.
2) It grabs a pty, but doesn't update /etc/utmp, which upsets "talk" and
other programs that do a getlogin (). This is pretty easy to fix (I
just finished doing that about 4 hours ago, you see).
3) To keep things from getting real confused, the tty never echoes (i.e.,
the child's end doesn't echo), but the pty does. Therefore, there's
no way for ile to know that the child would like echoing turned off.
Translation: passwords echo. I haven't figured out a nice way around
this yet.
4) There's no clear concept of "current directory". Since this would
require something of a Know-What-I-Mean function, there's not much
that can be done about it.
Some advantages:
1) Ile notices when the child puts the tty into raw mode, and gets out of
the way. Things like Emacs still work.
2) You now have an Emacs-like user interface. Things like ^A, ^E, ^T
ESC-u, etc, all work. You can change the default key bindings to
whatever you prefer. Characters insert by default.
3) File name completion exists, but only on absolute paths (start with
a / or ~). I haven't figured out how to get an escape through to the
shell for its completion yet, assuming it's possible.
4) *All* line-oriented programs suddenly have history, with a nice line
editing capability. Ile maintains its own history list (accessed via
^P and ^N by default), and doesn't distinguish between what subprocess
is reading from the pty. It's real convenient being able to pop up
the history list and grab the command line you typed at the wrong program
and give it to the right program. You don't need one of those
"...relentlessly interactive, icon-based, rodent-infested, dumb-user-
friendly, smart-user-crippling systems..."[*] any more.
I have the original message (as you probably guessed from the exactness
in identification given at the top). The diffs for diddling utmp nicely
(cleans up after itself and such) are fairly small, and on their way to
the original author.
Please note that I will not be at this email address after Dec 12, so
either get any requests in to me quickly, or send a note off to Mr.
Pendleton.
[*] Thanks to Mike Van Pelt for that description.
Dieter Muller
--
Welcome to the island. You are number six.
dieter%nmt at relay.cs.net
dieter at jupiter.nmt.edu
-----------------------------
From: Pierre Mathieu <mathieu at ists.yorku.ca>
Subject: Pre-formatted tapes for HP drives
Date: 28 Nov 88 18:35:45 GMT
Sender: news at istsists.ca
Keywords: tape drive
To: info-unix at sem.brl.mil
Here are a couple of questions about HP tape drives.
We have an HP 9000 series 350 system running HP-UX 6.2
with an HP 9144A tape drive.
Question 1) Is it possible to load tapes into this drive that
are not pre-formatted and format them from HP-UX?
I have tried to use (non-HP) unformatted tapes
in this drive but it just went into spasms and locked
up totally refusing to use these tapes (which are
in every way identical to HP's except that they are not
pre-formatted).
Question 2) If it is not possible, then does anybody know if other
companies than HP make these pre-formatted tapes? We
found that at twice the price of the other tapes out
there, HP prices were a little excessive. :-)
Thanks in advance for any help,
Pierre Mathieu mathieu at ists.yorku.ca
Institute for Space and Terrestrial Science mathieu at yunexus.yorku.ca
Center for Research in Exp. Space Science
York University, Ontario, Canada.
-----------------------------
From: Mario Dorion <mdorion at cmtl01.uucp>
Subject: A UUCP question
Date: 29 Nov 88 19:23:26 GMT
Keywords: 'ALARM' messages
To: info-unix at sem.brl.mil
Hi!
I've got a UUCP problem. There's a uucp link (through standard modems)
between my site (X02) and site cmtl01. This link has been used for a few months
now for E-mail and file transfering without any problems.
For a few weeks, cmtl01 have been giving me a news feed. Since then our commu-
nications have been failing with depressing regularity. A (very) good number of
our sessions end with *alarms* messages.
Since I really have no ideas of what these messages mean I really don't know
where to look!
Any suggestions???
Here's a few lines from the uucico log and the uucp log. I am using HDP's UUCP
with a system V system.
*************************** uucico log ***************************************
pkgetpack: Connodata=1
rec h->cntl 37777777602
send 40
pkgetpack: Connodata=1
rec h->cntl 37777777612
alarm 1
alarm 2
send 40
alarm 3
send 40
alarm 4
send 40
alarm 5
send 40
alarm 6
send 40
alarm 7
send 40
alarm 8
send 40
alarm 9
send 40
alarm 10
send 40
alarm 11
send 40
tries = 10
send 10
send 10
r short 2 want 3
rcount = 0
xcount = 0
cntrl - -1
send OO 0,imsg >exit code -1
Conversation Complete: Status FAILED
**************************** uucp log ************************************
TM_cnt: 1
tm_name: /usr/spool/uucp/cmtl01/TM.10495.000
uucp cmtl01 (11/29-13:10:36,10495,0) FAILED (LOGIN FAILED)
uucp cmtl01 (11/29-13:11:29,10495,0) FAILED (LOGIN FAILED)
uucp cmtl01 (11/29-13:12:22,10495,0) FAILED (LOGIN FAILED)
uucp cmtl01 (11/29-13:12:57,10495,0) SUCCEEDED (call to cmtl01 )
uucp cmtl01 (11/29-13:12:59,10495,0) OK (startup)
uucp cmtl01 (11/29-13:13:00,10495,0) REMOTE REQUESTED (cmtl01!D.cmtl07d72574 --> X02!D.cmtl07d72574 (news))
news cmtl01 (11/29-13:16:03,10495,1) IN SEND/SLAVE MODE (INPUT FAILURE)
news cmtl01 (11/29-13:16:03,10495,1) FAILED (conversation complete)
uucp cmtl01 (11/29-13:25:58,10557,0) FAILED (LOGIN FAILED)
uucp cmtl01 (11/29-13:26:47,10557,0) CAUGHT (SIGNAL 15)
--
Mario Dorion | E-mail: mdorion at X02.UUCP
XIOS Systems | ...uunet!attcan!cmtl01!X02!mdorion
Montreal, Canada |
1 (514) 744-3410 | No thanks, no penguin, I already got one!
-----------------------------
From: John Gayman <john at wa3wbu.uucp>
Subject: SVR3 Manuals
Date: 30 Nov 88 03:38:15 GMT
To: info-unix at sem.brl.mil
I recall seeing an advertisement a few months back from an outfit
like Sams, Hayden, etc. offering a set of manuals for SVR3 much like
those that are out for SVR2. Would anyone have a telephone number and
or title/ISDN numbers for these ? I beleive it was about 3-4 books.
Thanks.
John
--
John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john
1869 Valley Rd. | ARPA: john at wa3wbu.uu.net
Marysville, PA 17053 | Packet: WA3WBU @ AK3P
-----------------------------
From: pim at mrevox.uucp
Subject: Re: GCOS field
Date: 30 Nov 88 14:46:00 GMT
Nf-ID: #R:dasys1:-799600:mrevox:4400001:000:351
Nf-From: mrevox!pim Nov 30 09:46:00 1988
To: info-unix at sem.brl.mil
Someone just the other day saw the GCOS(GECOS) field
being prompted for and remarked that he hadn't seen
that name for a while. He said that it stood for:
General Electric Computer Operating System
or
General Electric Comprehensive Operating System
It seems far fetched, but interesting.
Paul MacMurdo
pim at mrevox.bellcore.com
...!bcr!mrevox!pim
-----------------------------
From: pim at mrevox.uucp
Subject: Re: A UUCP question
Date: 30 Nov 88 14:53:00 GMT
Nf-ID: #R:cmtl01:-13700:mrevox:4400002:000:271
Nf-From: mrevox!pim Nov 30 09:53:00 1988
To: info-unix at sem.brl.mil
We used to have the same problem when passing through a
DATAKIT node.
The problem was resolved when XON was shut off the line
set up for UUCP.
Paul MacMurdo pim at mrevox.bellcore.com
Bellcore ...!bcr!mrevox!pim
MRE 1C-343
435 South Street
Morristown NJ 07960-1961
-----------------------------
From: "Richard A. O'Keefe" <ok at quintus.uucp>
Subject: Re: * Question
Date: 30 Nov 88 11:17:51 GMT
Sender: news at quintus.uucp
To: info-unix at sem.brl.mil
In article <17661 at adm.BRL.MIL> wmartin at almsa-1.arpa (Will Martin -- AMXAL-RI) writes:
>Under "csh", if "bar" doesn't exist, I get: "/data/sa*/bar: No match",
>but, if "bar" DOES exist, and I do either:
>
>cat foo > /data/sa*/bar or cat foo >> /data/sa*/bar
>
>it will work OK! So "csh" expands the wildcard * correctly in this case.
>
>And, if "csh" lets this work
>as shown, why does it NOT work when creating the file initially?
When you give a wildcard pattern in Csh, there has to be at least one
thing in the file system which matches the complete pattern. Suppose
you have an empty directory /data/savewhatsit/ and no other directories
matching /data/sa* . Where then is there anything that matches the
**whole** pattern /data/sa*/bar ?
If you just want to save yourself a lot of typing, use a shell variable:
Csh: set sa=/data/sa*
echo works first time >$sa/bar
Sh: sa=`echo /data/sa*`
echo works first time >$sa/bar
Your message was /usr/spool/news/comp/unix/questions/7149 here.
In the Bourne shell, I did
$ NEWS=/usr/spool/news
$ cd $NEWS/comp/unix
$ echo que*/7149
$ echo $NEWS/co*/un*/que*/7149
and both echos worked. This was on a Sequent, and the test worked in both
the "att" and the "ucb" universes. For some real fun, I went to my home
directory and made a subdirectory zabbo containing a file fred.
$ echo trouble >zab*/fred
zab*/fred: cannot create
$ x=zab*/fred
$ echo $x
zabbo/fred
$ echo real trouble >$x
zab*/fred: cannot create
Let's get this last one out of the way first.
$ echo "$x"
zab*/fred
We see from this that when a variable is assigned a value, that value
is not wild-card expanded ("globbed"). But if you use the value of the
variable later in a context where globbing is done, the value will be
globbed then. That's why I wrote sa=`echo /data/sa*` above.
What about ">zab*/fred"? Why didn't that work? Well, you have to read
the Sh manual page with extreme attention to detail. Several sorts of
"evaluation" happen to a command line.
Command SUBSTITUTION
`command` is called and the output substituted
Parameter SUBSTITUTION
$thingies are replaced by their values
File Name GENERATION
"globbing", "wild-cards". The manual page says clearly that
this happens after command and parameter substitution and
blank interpretation.
Now when we come to input/output redirection, we are told about
<word
>word
>>word
and so on that "SUBSTITUTION" happens to the word before it is used.
That's *all* that happens; file name generation (globbing, wild-card
processing) is not done, and blank interpretation is not done either.
$ y="BIG trouble"
$ echo $y >$y
$ ls
BIG trouble
fred
$ ls $y
BIG not found
trouble not found
$ rm "$y"
You can see why the Bourne shell works this way: before command and
parameter substitution the "word" is *one* thing; blank interpretation
and file name generation could turn it into more than one thing, and
what would that mean? The C shell handles it differently:
% set y="BIG trouble"
% echo $y >$y
$y: Ambiguous.
As should be clear by now, assignment to keyword parameters is another
context where substitution is done but file name generation is not.
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: How to mimic the terminal driver?
Date: 30 Nov 88 19:18:12 GMT
To: info-unix at sem.brl.mil
In article <35 at umvlsi.ECS.UMASS.EDU> vishwana at umvlsi.ECS.UMASS.EDU (Chidambaram Vishwanath) writes:
> I have taken upon myself the following task, viz.,: I want to add
>an extra feature to the C-shell whereby I can recall earlier commands
>by pressing an arrow-key. [etc.]
Why reinvent the wheel? The so-called "Tenex Cshell" already has similar
support built in. I think it may even have become the standard 4.3BSD
Cshell. You can also get this in the Korn shell and the BRL Bourne shell.
A terminal editing wrapper process was posted to one of the newsgroups
only a few months ago, if you want to use the separate-process approach.
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: * Question
Date: 30 Nov 88 19:22:31 GMT
To: info-unix at sem.brl.mil
In article <17661 at adm.BRL.MIL> wmartin at almsa-1.arpa (Will Martin -- AMXAL-RI) writes:
>cat foo > /data/sa*/bar
>What I don't understand is why the expansion doesn't work under "sh".
It was a deliberate design decision. The target of > should be just one
word, not the potential multiple words that wildcard expansion might
produce. To avoid unpleasant surprises, "sh" doesn't expand wildcards
in such contexts.
However, note that you can save typing using the BRL Bourne shell by
using the filename completion feature to automatically fill in the
rest of a pathname segment once you've typed the unambiguous prefix
for it. I actually prefer this approach anyway, since I get to see
the full expansion before the command is executed.
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: Adventure shell
Date: 30 Nov 88 20:36:10 GMT
To: info-unix at sem.brl.mil
In article <Nov.30.01.27.00.1988.14076 at topaz.rutgers.edu> jjoshua at topaz.rutgers.edu (Jon Joshua) writes:
> I heard someone mention a shell called the adventure shell.
>This shell turned Unix into an adventure game where you could pick up
>files and drop them elsewhere etc... Does anyone have more info on
>this shell? Better yet, does anyone have a copy?
I mailed you the one I devised a few years ago. Mine was inspired by
somebody's joke, but it really does work and some people even claim to
like it as a shell (they must be crazy). It's a huge Bourne shell
script. The version I sent requires shell functions, which is an SVR2
or later feature. If you have an obsolete shell, you will need to
change the use of those functions (which manipulate lists) to in-line
shell code. There are also some definitions at the start of the file
for paginators, etc. that you'll need to configure properly. I think
my distribution kit includes source code for the "ask" utility which
is used to get responses to yes/no questions.
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: GCOS field
Date: 30 Nov 88 20:41:13 GMT
To: info-unix at sem.brl.mil
In article <7996 at dasys1.UUCP> jpr at dasys1.UUCP (Jean-Pierre Radley) writes:
>In article <1257 at vsedev.VSE.COM> logan at vsedev.VSE.COM (James Logan III) writes:
>>Does anyone know what GCOS really stands for and where it came from?
>In my flavor of unix, that's described as the "Comment" field.
That's what it has evolved to, since most current UNIX systems don't
spool printer output etc. to Honeywell (formerly GE) systems.
-----------------------------
From: Ken Keirnan <kjk at pbhyf.pacbell.com>
Subject: Re: Troff "grap" question
Date: 30 Nov 88 16:35:01 GMT
To: info-unix at sem.brl.mil
In article <618 at wc11.idca.tds.philips.nl> ekkel at idca.tds.PHILIPS.nl (Erik Ekkel) writes:
>I want to use the troff "grap" preprocessor to plot a graph. The problem is
>that the input has as x-coordinate weeknumbers. So the range of the
>x-axis is e.g. 8801:8852, 8901:8952, ..........
>
>How can i tell "grap" that there is a gap in the x-axis; that week 8901 is the
>successor of week 8852 and NOT 8900 !
If you know the number of points along the x-axis in advance, one way would be
to specify the number of x-axis intervals with the "coord" keyword and then
make the week numbers tick labels. For example if you have 52 points on the
x-axis:
coord x 0,52
ticks bot out at 1 "8801",2 "8802" ...
or whatever interval you want between ticks. I know this is messy, but nothing
else comes to mind.
--
Ken Keirnan - Pacific Bell - {att,bellcore,sun,ames,pyramid}!pacbell!pbhyf!kjk
San Ramon, California kjk at pbhyf.PacBell.COM
-----------------------------
From: Steve DeJarnett <steve at polyslo.calpoly.edu>
Subject: Re: Anonymous ftp's
Date: 30 Nov 88 06:51:59 GMT
To: info-unix at sem.brl.mil
In article <380001 at hpcea.CE.HP.COM> twakeman at hpcea.CE.HP.COM (Teriann Wakeman) writes:
>>Doug Comer has a good book out on the details of internetworking.
>Ah... Got any more info about this book? ie. name, publishing date/house?
>availablity?
Availability: Now
Title: Internetworking with TCP/IP -- Principles, Protocols, and
Architecture
Publisher: Prentice-Hall
Publishing Date: 1988
Cost: Around $40
Good book. Explains the concepts well to those who are unfamiliar with TCP/IP,
but doesn't insult your intelligence if you do know something about it.
-------------------------------------------------------------------------------
| Steve DeJarnett | Smart Mailers -> steve at polyslo.CalPoly.EDU |
| Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve |
| Cal Poly State Univ. |------------------------------------------------|
| San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork |
-------------------------------------------------------------------------------
-----------------------------
From: Doug Toppin <toppin at melpar.uucp>
Subject: Nroff/Troff Floating Displays
Date: 30 Nov 88 16:42:58 GMT
Keywords: Nroff,Troff
To: info-unix at sem.brl.mil
We are using nroff and the mm macros to generate
our documentation and often have to insert pages
created by other means (diagrams, etc).
We are using floating displays in the following fashion:
.nr De 1 \" follow output of floating page with page eject
.nr Df 2 \" output floating display at top of a new page
.DF
stuff
.De
This will cause the current page to fill and then
the next page will be reserved and ejected.
This works well but we have not been able to insert
successive floating displays without getting text
pages between them. If anyone knows what to do I
would appreciate it if they sent me an example
via mail at:
uunet!melpar!toppin
Thanks
Doug Toppin
-----------------------------
From: Mike Khaw <mkhaw at teknowledge-vaxc.arpa>
Subject: Re: Pre-formatted tapes for HP drives
Date: 30 Nov 88 18:17:22 GMT
To: info-unix at sem.brl.mil
<274 at istsists.ca>, by mathieu at ists.yorku.ca (Pierre Mathieu):
> Question 1) Is it possible to load tapes into this drive that
> are not pre-formatted and format them from HP-UX?
Not that I know of; in fact, if you write onto a pre-formatted tape
from a non-HP drive (e.g., a Sun) you destroy the formatted track(s?)
and can no longer use the tape in the HP drive.
> Question 2) If it is not possible, then does anybody know if other
> companies than HP make these pre-formatted tapes? We
3M makes them. They are DC600HC tapes.
Mike Khaw
--
internet: mkhaw at teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|ames|hplabs}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
-----------------------------
From: Guy Harris <guy at auspex.uucp>
Subject: Re: ls -l
Date: 30 Nov 88 18:49:25 GMT
Keywords: ls
To: info-unix at sem.brl.mil
>When a user enters the command "ls -l" on a directory, a slew of information
>is given with such things as last-modified time, number of links, owner, group,
>etc. Such data is usually stored in the inode. My question is this: does the
>"ls" program need to open each file, to look at its inode in order to display
>this data to standard output?
No, it doesn't have to open the file; it can list the information about
files you're not allowed to open.
It uses the "stat" (or "lstat", on systems that have symbolic links if
you're telling "ls" not to follow links) system call to get the
information in question. This involves doing a lot of the same
operations that an "open" does, namely looking up the pathname and
reading the inode, in the case of a local file on a UNIX file system.
>The only reason this has interested me is that it seems that, even for
>long directory listings, the command takes a very short amount of time
>to complete, considering all the file opening and closing I guess it's
>doing.
Your system is probably doing a reasonable job of caching information in
memory. All UNIX implementations of local UNIX file systems with which
I am familiar will cache data blocks of directory files, so to look up a
file it may not have to read the directory blocks into memory. (In
fact, since "ls" reads the directory itself, the blocks in question may
already be *in* memory by the time it gets around to "stat"ting the
file.) Similarly, blocks of the i-list will also be cached in memory.
Since many inodes fit in a block, reading one block will get several
inodes. Implementations of the 4.2BSD file system try to keep inodes
for files within the same directory in the same blocks of the i-list, so
the other inodes are more likely to be useful.
In addition, there may be other caches, such as caches of directory
entries (present in at least 4.3BSD, SunOS, and systems that have
adopted recent versions of the SunOS VFS/NFS code) and caches of inodes
that were used recently but are not currently in use.
-----------------------------
From: Guy Harris <guy at auspex.uucp>
Subject: Re: * Question
Date: 30 Nov 88 19:41:56 GMT
To: info-unix at sem.brl.mil
>And, if "csh" lets this work as shown, why does it NOT work when
>creating the file initially?
Because a "starname" must match something that already exists. The
starname "foo/*/bar" will match all files named "bar" in any
subdirectory of "foo" (except those whose name begins with "."). When
creating the file initially, it doesn't exist yet....
-----------------------------
From: "Richard A. O'Keefe" <ok at quintus.uucp>
Subject: Re: ls -l
Date: 30 Nov 88 13:20:03 GMT
Sender: news at quintus.uucp
Keywords: ls
To: info-unix at sem.brl.mil
In article <4952 at boulder.Colorado.EDU> wu at spot.Colorado.EDU (WU SHI-KUEI) writes:
>In article <838 at nih-csl.UUCP> ted at nih-csl.UUCP (ted persky) writes:
>>My question is this: does the "ls" program need to open each file,
>
>No - the inumbers are stored in the *directory* file, NOT in the individual
>files. Try 'ls -i' and then 'od -c .' to prove this to yourself.
The question was about "ls -l" (dash-lower-case-ELL) not about
"ls -i" (dash-lower-case-EYE). ls -i does indeed have to inspect only
the directory. ls -l, however, has to look a bit harder.
There is a system call named stat() which says "tell me all about this file".
It has to read the *inode*, but that is not the same as opening the *file*.
That's done by the open() system call. For example, you can get stat()
information about a file you do not have permission to read.
-----------------------------
From: Mark Runyan <runyan at hpirs.hp.com>
Subject: Re: SCCS: how to handle multiple developers/streams
Date: 29 Nov 88 22:24:07 GMT
To: info-unix at sem.brl.mil
>/ tpc at bnr-fos.UUCP (Tom Chmara) / 10:17 am Nov 24, 1988 /
I'm not an expert in SCCS, so I may not be of any help, but you have
found a problem that everyone using SCCS will encounter eventually...
>1. Scenario: Building a new load. Problem: devoted developer has a
> module checked out for editing. I don't WANT the new version; I want the
> old one. "-c" gets the old version, "-G" specifies a new path into
> which I dump the file. Ergo, I need a new copy of my source
> directory structure? Or does every file need an "alias" for loadbuilding?
I'm not sure I understand the problem the way it is phrased. (I also don't
appear to have the "-G" option you mentioned). If your developers are
all working in the same directory, the problems you face are very
significant. SCCS alone may not be the solution. Perhaps each developer
needs their own workspace (yes, that uses a lot of disk). With links,
you could reduce the disk space, but managing the links would be
difficult.
>2. Scenario: Doing maintenance. A bug has been reported in existing
> (read: non-current) software. Do I have to rebuild (recompile) the
> world to be able to restore that environment? Do I have to maintain
> a copy of the directory hierarchy for every released version?
Again, separate work spaces are the only answer I see for this. Once
you have found the fix, checking the fix in on a branch would be a way
to store it. The environment is a *major* problem. While SCCS stores
the source for a file, it doesn't keep the environment (i.e. compilers,
header files, etc) needed to rebuild the exact bits. I strongly suggest
that a database (which could be something as simple as a flat file and
some awk scripts) be considered for keeping track of which revisions of
which files and programs create a particular environment. Storing the
old compilers, loaders, etc. into special directories might be
required.
>2. Scenario: Doing development. Do I need to do development in the
> current directory (i.e. parent to SCCS directory) and aggravate the
> loadbuilders (see #1)? What happens if two of us are doing development
> in the same directory? I'd like to use the old (read: loadbuilt)
> objects to avoid having to recompile the world; so would s/he.
> We're constantly going to see each other's sources. This looks like
> a problem for the Makefiles... Unless I actively sccs info each
> subdirectory, I don't know who else is doing development -- and that
> information itself is volatile...
If the SCCS directory in *your* working directory is simply a link (symbolic
or otherwise) to the "real" SCCS directory, each work space will use the
same SCCS files but be separate. This uses a *lot* of disk space when
someone checks everything out. One solution to this is to have a program
which manages links (i.e. everything is checked out into some location
and linked. When you want your own copy, break the link. Need a way to
keep track of which are broken links and which aren't).
>I DO know that both SUN & HP use SCCS at some stage of their development
>efforts, so presumably maintenance of old software streams is a subject
>near (though maybe not dear) to their respective hearts. Others are also
>likely to be equally knowledgeable. I'm slowly going nuts trying to envision
>parallel "shadow" directories, (and subdirectories, and...). Is there
>an easy way out? Is there a sane way out? What are my alternatives?
Well... <cough, cough> I don't think that either SUN or HP uses *just*
SCCS. (I don't think HP uses SCCS too much, but I could be wrong :-)
SCCS only provides management of the revisions of a file. Frontends and
support programs must exist to handle work spaces and networking. Knowing
this will start a "Holy War", I'll mention that RCS allows a person to
manage a group of files, but again, RCS only manages revisions. The
work space and networking ( and environment ) problems are not solved
by either RCS or SCCS.
If a solution exists, I would really like to hear about it... I believe
that solutions may arise soon as software configuration becomes more
important, but I'm not aware of any solution available to the customer
at the moment.
Mark Runyan
-----------------------------
From: "William P. Reeder" <reeder at ut-emx.uucp>
Subject: Re: ls -l
Date: 30 Nov 88 23:26:02 GMT
Keywords: ls
Posted: Wed Nov 30 17:26:02 1988
To: info-unix at sem.brl.mil
In article <838 at nih-csl.UUCP>, ted at nih-csl.UUCP (ted persky) writes:
> it seems that, even for long directory listings, the command takes a very short
> amount of time to complete, considering all the file opening and closing I guess
My experience has been that ls can take a very long time to run on
large directories. Several posters have already explained that ls
doesn't have to open each file in the directory; but no one has talked
about ls sorting the information before displaying it. I think one
version of ls we had used a bubble sort, which made it unbearable in
some directories (containing around 800 files). One of my (former)
co-workers modified ls to use quicksort, and it helped a lot.
--
DISCLAIMER: I speak only for myself, and usually only to myself.
-----------------------------
From: Andrew Hume <andrew at alice.uucp>
Subject: Re: fio library routines
Date: 29 Nov 88 20:33:39 GMT
To: info-unix at sem.brl.mil
a bundle of the fio man page and macros is available via anonymous ftp at arpa.att.com
robert elz (uunet!munnari!kre or something) has been talking to me about
a public domain implementation. the whole source is 600 lines of code so it
shouldn't be too hard.
-----------------------------
From: Andrew Hume <andrew at alice.uucp>
Subject: Re: fio library routines
Date: 29 Nov 88 20:49:26 GMT
To: info-unix at sem.brl.mil
anyone who gets the mk distribution (from AT&T toolchest)
has the fio source.
-----------------------------
End of INFO-UNIX Digest
***********************
More information about the Comp.unix.questions
mailing list