netnews@wnuxb.UUCP (Heiby) (04/23/85)
Unix Technical Digest Tue, 23 Apr 85 Volume 1 : Issue 44
Today's Topics:
Getting just a bell to output.
ls(1) on System V (3 msgs)
Oct. UNIX BSTJ - A Followup (3 msgs)
Process creation & "swap"
Wher is End Of File
Why do people use: if [ "x$FOO" = "x" ] .... ?
----------------------------------------------------------------------
Date: 16 Apr 85 19:54:46 GMT
From: hom@houxm.UUCP (H.MORRIS)
Subject: Getting just a bell to output.
I got one response which told how to output just a bell (without
a linefeed) in a portable and not too clumsy way. Namely
echo "^G" | tr -d "\012"
The rest of the responses mostly were to use `echo -n "^G"'
which works ONLY on UCB (whereas I want it to work on both UCB and SV).
Thanks to everyone.
------------------------------
Date: 11 Apr 85 07:15:10 GMT
From: guy@sun.uucp (Guy Harris)
Subject: ls(1) on System V
> Well, the problem is that in the readdir() routine, the code is doing
> strlen(dentry.d_name), and d_name isn't null-terminated if it's 14
> characters long (I think strlen returns 44 or so).
This is the second S5R2 bug that is fixed "for free" if you convert
to the Berkeley "directory library". The library provides directory
entries with null-terminated names, fixing this bug; the previous bug
was a shell problem caused, if I remember correctly, by testing whether
the result of an "open" of a directory was > 0 rather than whether it
was >= 0.
I've converted lots of S5R2 programs to use the library; it's very easy.
I'd vote for putting it into 1) the /usr/group standard, 2) the System V
Interface Definition (which currently, bless its soul, does *not* commit
to what directories look like when you open them), and therefore 3)
System V.
Guy Harris
sun!guy
------------------------------
Date: 14 Apr 85 11:12:31 GMT
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Subject: ls(1) on System V
I second the motion! Benefits include:
(1) Easier coding
(2) Cleaner coding
(3) Portable coding
(4) Faster operation due to buffering
Of course virtually ALL the UNIX System V Release 2 utilities have
been so converted in the BRL UNIX System V emulation for 4.2BSD
(out of necessity). If AT&T wants `em they can have `em. I also
previously posted a UNIX System V edition of the directory access
library routines. They should be added to the standard C library!
------------------------------
Date: 11 Apr 85 19:23:51 GMT
From: jsdy@hadron.UUCP (Joseph S. D. Yao)
Subject: ls(1) on System V
> mean time, a work-around is to use "ls -C *" instead of "ls -C". It
Suggest 'ls -Cd *' would do what you want. I've made the other
mistake too often.
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}
[Ed note: Quite right, my mistake! RWH.]
------------------------------
Date: 11 Apr 85 21:03:40 GMT
From: ras@rayssd.UUCP
Subject: Oct. UNIX BSTJ - A Followup
A few months ago there was a big discussion on the Net about the
price of the Special Edition of the Bell Systems Technical Journal,
and how the back-order price was more than $24.00, whereas the
yearly susbscription fee was only $34.00. Many people were irate,
and grumbled about it.
A user at our facility, (formerly the manager of our Technical Info
Library), read our subscription copy, wanted more, and soon found out
about the price difference. He then called the Director of AT&T
Computer Software Division, (O'Shea?), and asked about the wisdom of
penalizing those that were interested in an AT&T product. The
secretary there said the message would be forwarded, and he pretty much
forgot about it.
Today, to our surprise, a letter arrived from O. L. Wilson, Sales and
Marketing Manager at AT&T Technology Systems, saying:
"Thank you for brining the disparity in pricing for the special issue ...
... As a result of your inquiry, we are reducing the price to $17.00
per copy, with a volume discout of 30 percent.
Again, thank you for alerting me to the problem. Because of your
help, I hope you will accept the enclosed 6 colies of the special
issue, courtesy of AT&T. ...".
Anyway, you may want to re-investigate the pricing if you really
were interested in getting this journal. I'm sort of amazed...
--
Ralph Shaw, {allegra, decvax!brunix, linus, ccice5}!rayssd!ras
Raytheon Co, Submarine Signal Division., Portsmouth, RI 02871
------------------------------
Date: 13 Apr 85 02:33:04 GMT
From: jsgray@watmath.UUCP (Jan Gray)
Subject: Oct. UNIX BSTJ - A Followup
I would like to mention that the Oct. 84 UNIX BLTJ is available to
educational institutions for the very reasonable price of $5.00 ($7.50
foreign).
Jan Gray (jsgray@watmath.UUCP) University of Waterloo (519) 885-1211 x3870
------------------------------
Date: 22 Apr 85 05:30:47 GMT
From: conde.osbunorth@XEROX.ARPA
Subject: Oct. UNIX BSTJ - A Followup
For your information, the AT&T Technical Journal's circulation
department no longer distributes single issues. Instead, you could order
the special issues, including the recent UNIX issue from:
AT&T Customer Information Center
P.O. Box 19901
Indianapolis, Indiana 46219
(800) 432-6600
Foreign: 1-317-352-8557 or 8665
Two special issues of interest.
The October 1984, part 2 (Vol 63, #8, part 2) UNIX issue.
Order number is 500-477 and costs $17.00.
The January 1983, part 2 (Vol 62, #1, part 2) 3B20D issue.
Order number is 500-120, and costs $10.00.
Orders must be prepaid, and they will accept credit card orders over the
phone. (Telemarketing at work!)
------
Non-special issues are available from
University Microfilms, Inc.
300 North Zeeb Road
Ann Arbor, Michigan 48106
For Xerographic copies call (800) 732-0616
For microfilm copies call (800) 521-3044
Any further questions regarding the journal could be directed to the
circulation department at (201) 564-2582.
------------------------------
Date: 16 Apr 85 23:21:40 GMT
From: keith@reed.UUCP (Keith Packard)
Subject: Process creation & "swap"
In article <1028@ecsvax.UUCP> khj@ecsvax.UUCP (Kenneth H. Jacker) writes:
>
> I have been told that Data General's AOS creates new
>processes *first* in the "swap space" on disk and *then*
>transfers a copy to memory.
>
> My question: what does (2.9) UN*X do? Does it create the
>process (text, data, ...) in memory , transferring it to
>"swap" only if necessary? Or does it use the AOS approach?
>
> Kenneth H. Jacker
Well, there are 2 cases in 2.9 unix. If the machine is idle
(sitting on the wait instruction) then the fork is done in memory.
If the machine is loaded, however, the fork is done by writing it
out to disk; creating another entry in the proc table and changing
the in-core copy. This in-core copy becomes the *new* process; the
old process is the one on the disk (it makes some sense and is
the only way this works neatly - the copy on the disk doesn't
need to be changed at all while the process in memory needs to
have it's u-struct mucked about with.)
2.9 only does the in-memory option if the kernel is made with
UCB_FRCSWAP set - this name is rather non-mnemonic; if defined
it allows in-core forks and expands, else it always swaps.
keith packard
...!tektronix!reed!motel6!keith (a 2.9 machine!)
...!tektronix!reed!keith
...!tektronix!azure!keithp
------------------------------
Date: 15 Apr 85 03:32:26 GMT
From: rjk@mgweed.UUCP (Randy King)
Subject: Wher is End Of File
<><><>
>> How does "read()" know when it has found end of file?
>> If my file is 100 Bytes and I try to read 200 bytes
>> how does it know that it can only read 100?
When you call read(), either directly or through a stdio function like
fgets, an argument is passed specifying how many bytes you want returned
from the particular device driver you are using.
The device driver has access to kernel tables, so the open file table is
referenced by this driver. That table contains, among other things, the
size of your file. Now if you ask for, say, 200 bytes in read(), a user
variable called "u.u_count" reflects that. Since there are only 100 bytes,
the driver returns those 100 and decrements "u.u_count" by 100, and the
return from read() reflects the number of bytes actually read.
So what is an end of file? Simply stated, when read() returns a zero; and
it will do so on your next read() because there is nothing left to send.
And it keeps a running total of how much you've read in a variable called
"u.u_offset." Ever use lseek(fd, 0L, 0) or rewind()? Not macgically, all
that does is set your "u.u_offset" to zero.
This is one of the beauties of UNIX. There is no magic involved in the
actual storage of data on the disk. It's just byte after byte of your data,
all hooked together in one mapping area called the super block. And if you
don't like the way things are stored on a medium, you are free to implement
your own filesystem through your own primitives.
If you look closely at the kernel, you will see that tables and lists are
linked back and forth all over the place so that all of this information
is readily available when your process does a context switch to kernel mode.
Take this all with a grain of sodium chloride; it is a much-simplified
explanation of reality.
Randy King
AT&T-CP@MG
ihnp4!mgweed!rjk
------------------------------
Date: 19 Apr 85 00:32:04 GMT
From: wcs@homxb.UUCP (Bill Stewart HO 4K-437 x0705)
Subject: Why do people use: if [ "x$FOO" = "x" ] .... ?
Last week I posted an article asking why people use constructs
like the above instead of if [ -z "$FOO" ] or if [ "Known" = "$FOO" ]
Yeah, I should have worried about the case where $FOO has a value
special to test, such as "-z" or "=". The most interesting reply
pointed out that the answers were different on 4.2BSD.
For both ksh and SysV /bin/sh, the = operator has higher precedence
than -z or -n. For 4.2 BSD it doesn't.
if [ -z = -z ] ; then echo true ; else echo false ; fi
On SysV and ksh, this prints "true"; on 4.2BSD it prints "false".
On the other hand,
if [ -z = ] ; then echo true ; else echo false; fi
On 4.2BSD this prints "false"; on ksh and SysV it prints
"sh: test: argument expected"
So, those leftover-from-v6 constructs with the "x$FOO" are
still useful.
Bill Stewart, ho95c!wcs
--
"The {first,last} major program written in ADA will be a COBOL interpreter."
Stewart, 1984
Bill Stewart
AT&T Bell Labs, Holmdel NJ
HO 4K-435 x0705 (201-949-0705)
ho95b!wcs
ucbvax!ihnp4!ho95b!wcs
decvax1harpo!ho95b!wcs
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)