Unix-Wizards-Request@arpa.brl (Mike Muuss) (06/14/88)
UNIX-WIZARDS Digest Tue, 14 Jun 1988 V5#068
Today's Topics:
Re: redirection before wildcards
Re: trap causes longjmp botch
Re: Stdio (stderr) buffering question
4.2 vs 4.3 select() (ARRRRGH!)
Re: O'pain Software Foundation: (2) Why is it better than AT&T?
Bug (or wierd behavior) In C Shell
Re: Vax 11/780 performance vs Sun 4/280 performance
Parodies
Re: 4.2 vs 4.3 select() (ARRRRGH!)
Re: OSF: A Desperation Move?
AIX facts, history and status
Convergence of AIX and 4.3BSD
Re: Will 4.2 select() catch OOB socket messages?
Re: Vax 11/780 performance vs Sun 4/280 performance
Re: OSF: A Desperation Move?
Re: grep replacement (first match only per file)
Re: ksh incompatabilities with sh?
Re: assert(status(PCjr)==status(RT/PC))
mods to ksh for YP using getpwnam() (LLLOOOONNNNGGGGG)
Magic symlink syntax
Symlinks vs. NFS
Re: alloca & coroutining
Tool -flag considered harmful (was: grep replacement)
Re: grep replacement
egrep won't pick fields
Re: grep replacement
Re: grep replacement and /dev/stdin
Re: grep replacement (first match only per file)
Re: grep replacement
International Obfuscated C Code Contest winners to be announced
Re: grep replacement
-----------------------------------------------------------------
From: Andrew Klossner <andrew@frip.gwd.tek.com>
Subject: Re: redirection before wildcards
Date: 11 Jun 88 23:37:40 GMT
Sender: andrew@tekecs.tek.com
To: unix-wizards@SEM.BRL.MIL
[]
"for curiosity's sake, why exactly are redirections performed
*before* wildcard expansions?"
So that, in simple-minded shells without filename completion, I can type
filter <in* | lpr
to mean
filter <in_service_report.88Apr12.version2A | lpr
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: trap causes longjmp botch
Date: 13 Jun 88 07:18:10 GMT
Keywords: command line argument, Cshell, trap, longjmp
To: unix-wizards@SEM.BRL.MIL
In article <502@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
> Used to [use trap 'action' 0] myself that way too ... until one
>day the sh (/bin/sh; the Bourne shell on an Ultrix machine) complained
>about a 'longjmp botch'; I don't remember if there was a core dump.
Unless it was otherwise disabled (file `core' in current directory
unwritable, `limit coredumpsize 0', etc), there was.
> What is the problem with this trap? [explanation deleted]
The problem is that there is a bug in the 4.2BSD /bin/sh such that
`trap 0' outside of a script sometimes causes a longjmp to a stack
context that is no longer around. Most likely this bug has been around
since V7, but is only caught now that longjmp unwinds the stack and
aborts if the frame is gone.
The bug does not occur when the trap is inside a script.
The bug remains in the 4.3BSD /bin/sh.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: Stdio (stderr) buffering question
Date: 13 Jun 88 07:27:44 GMT
To: unix-wizards@brl-sem.arpa
In article <5027@sdcsvax.UCSD.EDU> hutch@net1.ucsd.edu (Jim Hutchison) writes:
>So how many things break if stderr is line buffered?
Not as much as if it is buffered a la stdout (line if tty, else fully),
but still not nothing. I change uucp with each new release to make it
line buffered; it requires adding fflush() calls in places so that you
can see send/expect strings in a timely manner.
Note that `tar tvf -' printed its `tv' output to stderr; this was one
of the worst offenders in the unbuffered stderr inefficiency game. The
4.3BSD tar has been fixed (mostly by BRL) by making its stderr line
buffered.
Chris
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Sean Casey <sean@e.ms.uky.edu>
Subject: 4.2 vs 4.3 select() (ARRRRGH!)
Date: 13 Jun 88 08:07:50 GMT
To: unix-wizards@SEM.BRL.MIL
I just tried out the select code that didn't work on 4.2 and
guess what? It works fine on a 4.3 system. ARRRGGGH! Why in the
hell did they distribute something that doesn't work as documented?
You know, when I was first experimenting with this stuff, I had to
go way out my way to find an undocumented ioctl() in 4.2 that
would correctly set the process group so that a process would get the
SIGURG that an OOB generated. Did the fcntl() work? Noooooo! Was
it available, yeeesss.
Now that I'm multiplexing, just getting a signal isn't good enough,
cause the program has to be able to figure out who sent the thing.
Does anyone know of a sneaky way to make this work on 4.2? Coding
around the problem is going to be a major unnecessary pain for me if I
can't find a way to make that select() work.
Sean
--
*** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet
*** The Empire select() Monster {backbone|rutgers|uunet}!ukma!sean
*** ``I'm not gonna mail it, YOU mail it. I'M not gonna mail it... Hey! Let's
*** send it to Rutgers! Yeah! They won't mail it. They return everything.''
-----------------------------
From: "Roger B.A. Klorese" <rogerk@mips.com>
Subject: Re: O'pain Software Foundation: (2) Why is it better than AT&T?
Date: 12 Jun 88 20:57:13 GMT
To: unix-wizards@SEM.BRL.MIL
In article <7942@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
>People, I have *yet* to meet a salesman who got technical issues right.
The person in question was a corporate MARKETING manager, not a salesman.
You know, product planning and marketing? The ones who TELL engineering which
of their brainstorms will and will not be shipped, in what guise, and to whom?
--
Roger B.A. Klorese MIPS Computer Systems, Inc.
{ames,decwrl,prls,pyramid}!mips!rogerk 25 Burlington Mall Rd, Suite 300
rogerk@mips.COM Burlington, MA 01803
I don't think we're in toto any more, Kansas... +1 617 270-0613
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.uucp>
Subject: Re: O'pain Software Foundation: (2) Why is it better than AT&T?
Date: 11 Jun 88 03:56:16 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@SEM.BRL.MIL
As quoted from <1017@sun.soe.clarkson.edu> by nelson@sun.soe.clarkson.edu (Russ Nelson):
+---------------
| I'm surprised that no one has come to the following conclusion:
|
| AT&T+Sun AND the OSF are gathering the wagons into circles because they're
| afraid of the GNUs. Think about what's going to happen when rms finishes
+---------------
WHO hasn't come to that conclusion? Check my "desperation move" article
again. GNU-style full openness is preferable to two lockouts.
+---------------
| the kernel? There is a tremendous market opportunity for a firm that
| simply offers support for GNUnix. They need no investment other than
| that needed to become a GNUnix wizard. And, because of the restrictions
| on derivatives of GNU, they will benefit from everyone else's work.
+---------------
Before anyone says "can't happen": ask yourself "what is mtXinu?" That's
right... it's been done before. It WILL be done if AT&T and/or the OSF
don't keep their mercenary tendencies in check.
--
Brandon S. Allbery | "Given its constituency, the only
uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about
Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is
comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
-----------------------------
From: Steve Simmons <simmons@applga.uucp>
Subject: Bug (or wierd behavior) In C Shell
Date: 9 Jun 88 18:12:50 GMT
Keywords: here script syntax oops
To: unix-wizards@brl-sem.arpa
Consider the following two scripts:
OK Buggy
#!/bin/csh | #!/bin/csh
if ( 1 ) then | if ( 0 ) then
cat << HERE | cat << HERE
else | else
HERE | HERE
else | else
echo There | echo There
endif | endif
Executing OK is fine -- it echos 'else'. Executing Buggy gives an error
HERE: Command not found.
It appears that in Buggy it is disregarding the here document *even though
it is syntactically correct*.
The Bourne and Korn shell equivalents to this script work fine, ie, buggy.sh
echos 'There'. Bug in the C shell? Or a wierdness of syntax that I can
use to convince people Korn is better? :-)
--
+- Steve Simmons UNIX Systems Mgr. Schlumberger CAD/CAM -+
+ simmons@applga.uucp ...umix!applga!simmons +
+- "Opinions expressed are all my own, etc, etc, etc, etc, etc, etc, etc." -+
-----------------------------
From: Don Speck <mangler@csvax.caltech.edu>
Subject: Re: Vax 11/780 performance vs Sun 4/280 performance
Date: 13 Jun 88 08:58:03 GMT
To: unix-wizards@SEM.BRL.MIL
I am reminded of this article from comp.arch:
In article <44083@beno.seismo.CSS.GOV>, rick@seismo.CSS.GOV (Rick Adams) writes:
> Well, to start with I've got a Vax 11/780 with 7 6250 bpi 125 ips
> tape drives on it. It performs adequately when they are all running.
> I STILL haven't found anything to replace it with for a reasonable amount
> of money. Nothing in the Sun price range can handle that I/O volume.
I've seen a PDP-11/70 with eight tape drives, too.
And as Barry Shein said, "An IBM mainframe is an awesome thing...".
One weekend, noticing the 4341 spinning a pair of GCR drives at over
half their rated 275 ips, I was shocked to learn that it was reading
the disk file-by-file, not track at a time. BSD filesystems just
can't compare to what this 2-MIPS machine could do with apparent ease.
How do they get that kind of throughput? I refuse to believe that it's
all hardware. Mainframe disks rotate at 3600 RPM like everybody else's
and their 3 MB/s transfer rate is only slightly higher than a SuperEagle.
A 2-MIPS CPU would be inadequate to run a BSD filesystem at those speeds,
so obviously their software overhead is a lot lower, while at the same
time wasting no disk time. What is VM doing efficiently that Unix does
inefficiently?
Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck
-----------------------------
From: der Mouse <mouse@mcgill-vision.uucp>
Subject: Parodies
Date: 13 Jun 88 10:48:00 GMT
Followup-To: poslfit only knows where
Posted: Mon Jun 13 06:48:00 1988
To: unix-wizards@SEM.BRL.MIL
In article <16097@brl-adm.ARPA>, rbj@icst-cmr.arpa (Root Boy Jim) writes:
> Repeat after me:
> We all live in a signal trampoline...
All right, you asked for it. Here's my contribution. Some of you may
know how mis-designed or mis-configured PACX systems tend to eat
control characters (commonly ^S and ^Q)....I was walking around the
house one day with tunes running through my head and this more or less
fell into place for me.
1 2 3 4
1 2
Let me tell you how it will be
There's 1 for you, 15 for me
'Cause I'm the PACX MAN
Yeeaaah, I'm the PACX MAN
Should two control chars seem too few
Be thankful any at all get through
'Cause I'm the PACX MAN
Yeeaaah, I'm the PACX MAN
If you dial from home, the pacx is there I'm not happy
If you blue-box in, it's in your hair with these four
And hardwired lines are awfully rare lines - any
So no matter what, there's a pacx right there suggestions?
PACX MAN
'Cause I'm the PACX MAN
Yeeaaah, I'm the PACX MAN
Don't ask me why I munch those chars
(Uh-uh, Mr. Ritchie...)
If you don't want to connect to Mars
(Uh-uh, Mr. Joy...)
'Cause I'm the PACX MAN
Yeeaaah, I'm the PACX MAN
And my advice for EMACS users
PACX MAN
Is to use vi like the rest of the lusers
PACX MAN
'Cause I'm the PACX MAN
Yeeaaah, I'm the PACX MAN
And you're typing to no one but me...
(PACX MAN...)
[Reference version of TAX MAN: _Revolver_ CD, CDP 7 46441 2 (DIDX 1481)]
Note the Followup-To: header. I couldn't think of a decent place to
point it, since this has nothing to speak of to do with UNIX and I
don't read r.m.b, r.a.p, or r.h nearly as regularly as c.w.u.... Mail
is the most reliable if you want me to see your reply.
der Mouse
uucp: mouse@mcgill-vision.uucp
arpa: mouse@larry.mcrcim.mcgill.edu
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: 4.2 vs 4.3 select() (ARRRRGH!)
Date: 13 Jun 88 11:00:24 GMT
To: unix-wizards@SEM.BRL.MIL
In article <9649@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes:
>I just tried out the select code that didn't work on 4.2 and
>guess what? It works fine on a 4.3 system. ARRRGGGH! Why in the
>hell did they distribute something that doesn't work as documented?
Because their funding contract said `thou shalt release by September'.
(Or whatever date it was. Anyway, as I understand it, the release
date hit, nothing was really ready, so they shipped anyway. There
were some fixes quitely applied to later tapes.)
>Now that I'm multiplexing, just getting a [SIGURG] signal [for out
>of band data] isn't good enough, cause the program has to be able to
>figure out who sent the thing. ... Does anyone know of a sneaky way
>to make this work on 4.2?
Do a receive for MSG_OOB anyway. If there is none, it ought to fail
with EWOULDBLOCK, or perhaps return 0.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: "G.Pavlov" <pavlov@hscfvax.harvard.edu>
Subject: Re: OSF: A Desperation Move?
Date: 13 Jun 88 08:44:09 GMT
Posted: Mon Jun 13 04:44:09 1988
To: unix-wizards@SEM.BRL.MIL
In article <23284@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes:
> From: pavlov@hscfvax.harvard.edu (G.Pavlov)
> >In article <23257@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes:
> >> IBM is a $60 Billion dollar corporation, the ENTIRE PC market, IBM,
> >> Compaq, Apple etc is perhaps several billion, IBM's share is probably
> >> on the order of $2...3B.
> > You're off by at least an order of magnitude.
> In which direction??? Which number (there are 3 in that quote)???
> (that was real helpful!)
> Actually, I doubt I'm off by much, cite? Major trade rags gladly
> accepted.
The micro nos; way too low. The best "trade rag" nos. will be in next Data-
mation's annual industry survey. Verifiable figures are that Apple is at
$3B annual sales, Compaq over $1B. Unverifiables for IBM are 10%-15% of
their total sales are in the "PC market". Tandy claims > $1B. Then there
are multi-100 millions such as Zenith, HP, Olivetti, etc, etc. This is a
huge market.
greg pavlov.
-----------------------------
From: Charlie Sauer <sauer@auschs.uucp>
Subject: AIX facts, history and status
Date: 9 Jun 88 23:14:21 GMT
Keywords: AIX
Posted: Thu Jun 9 18:14:21 1988
To: unix-wizards@SEM.BRL.MIL
Since a future version of AIX will be core technology for the OSF products,
I think it is useful to summarize publicly announced AIX facts and status. I
am speaking for AIX, not the OSF, and I am not going to talk about the
unannounced plans for AIX. Several of us in Austin have disclosed AIX
technology in development to the OSF seed team, and I expect that OSF will
announce OSF plans with respect to AIX technology when appropriate.
AIX on the RT is now in it's fifth release, known as AIX 2.2, which is
officially available on June 24. Another release on the RT (2.2.1) and
AIX PS/2 are scheduled for September availability, and AIX/370 is scheduled
for March availability.
AIX development personnel participate actively in the POSIX committees, and
AIX is committed to POSIX compliance.
AIX was originally derived from SVR1 and SVR2. We have endeavored
to maintain the functionality in the BA sections of SVID at the SVR2 level.
There are some incompatibilities, which I personally consider minor.
Evolutionary compatibility with BSD has been part of AIX development starting
with the initial release. An abstract on 4.3 convergence is being posted
separately.
AIX also includes many components from vendors, from other universities, and
from IBM development and research.
There is a recent overview paper on AIX[1], but I will list a few of the
areas where we have focused development and research effort:
virtual memory management and mapped files. The AIX/RT pager is derived
from work originally done in the CP.R project at IBM Watson Research Center.
services for managing "real time" devices and applications.
optimizing compiler technology based on the 801 project at IBM Research[2]
and related technology, e.g., the dynamic binding code used for device
handlers.
internationalization.
integrating SNA and related communications products with Unix.
distributed system support[3].
It is our plan that AIX be consistent in both interfaces and actual
source code base across the 386, RISC and 370 platforms. (There are some
areas where consistency is not achievable due to hardware differences, e.g.,
IEEE floating point vs. 370 floating point. Given resource and schedule
pragmatics, there will be functions not present in particular platforms in
particular releases.) The AIX Family Definition Overview, to be published
next month, summarizes the system call interfaces, library routines and
commands which are common across the AIX Family. This includes the BSD
compatibility described in the accompanying abstract, X11, NFS, Distributed
Services, TCP/IP, etc.
REFERENCES:
1. L.K. Loucks and C.H. Sauer, "Advanced Interactive Executive (AIX) Operating
System Overview," IBM Systems Journal 26, 4 (1987).
2. M. Auslander and M.E. Hopkins, "An Overview of the PL.8 Compiler," Proc. of
the SIGPLAN '82 Symposium on Compiler Writing, Boston, MA.
3. C.H. Sauer, D.W. Johnson, L.K. Loucks, A.A. Shaheen-Gouda and T.A.
Smith, "RT PC Distributed Services Overview," Operating Systems
Review 21, 3 (July 1987) pp. 18-29.
--
Charlie Sauer IBM AES/ESD, D18/802 uucp: ut-sally!ut-emx!ibmaus!sauer
11400 Burnet Road csnet: ibmaus!sauer@EMX.UTEXAS.EDU
Austin, Texas 78758 aesnet: sauer@auschs
(512) 823-3692 vnet: SAUER at AUSVM6
-----------------------------
From: Charlie Sauer <sauer@auschs.uucp>
Subject: Convergence of AIX and 4.3BSD
Date: 9 Jun 88 23:19:33 GMT
Keywords: AIX BSD 4.3
Posted: Thu Jun 9 18:19:33 1988
To: unix-wizards@brl-sem.arpa
Following is an abstract of a paper we plan to write:
CONVERGENCE OF AIX AND 4.3BSD
Charles H. Sauer (1)
Kathy A. Bohrer (1)
Tom Lang (1)
Conrad Minshall (2)
Gary L. Owens (1)
Kris Solem (3)
Bruce J. Walker (4)
(1) IBM Advanced Engineering Systems, Austin, TX
(2) IBM Technical Computing Systems, Palo Alto, CA
(3) formerly IBM Technical Computing Systems,
now MIPS Computer Systems
(4) LOCUS Computing Corporation, Santa Monica, CA
AIX started with a number of BSD features, e.g., 4.2 signals and concurrent
groups[1]. Over time, additional features associated with BSD, such as pty's,
select, sockets and sendmail have been added, with new features being added in
each release. Based on this experience, and experience with 4.3/RT, it
appeared that fairly strict BSD compatibility could be achieved, and the
authors and others set out to define such compatibility.
This paper describes methodology and decisions made in defining a convergence
of BSD 4.3 and AIX. This convergence will be reflected in the AIX Family
products and the version of AIX to be provided to the Open Software Foundation.
Among the goals of the work were
POSIX compliance
Base SVID functionality at the SVR2 level
Compatibility with documented and undocumented BSD 4.3 characteristics
and interfaces
Compatibility with existing AIX interfaces
Completeness - providing essentially all BSD 4.3 functions
Minimal redundancy - except in a few cases where redundancy seemed
inescapable, conflicts were resolved to provide a single merged
definition of system call, library and command interfaces. Users
and programmers should normally not be conscious of the historical
basis of the converged interface.
Portability - minimizing porting effort for users and applications
associated with existing AIX and 4.3 implementations.
In addition, many of the system administration facilities were addressed in
a converged manner. The effectiveness of the approach is demonstrated by
success with test suites originally designed for AIX/RT and 4.3/RT prior
to the convergence effort.
ACKNOWLEGEMENT
Many others contributed to this work, including, from IBM Advanced Engineering
Systems: Rob Cordell, Jim DeGroot, Patrick Goal, Carolyn Greene, Larry Loucks,
Jim Mott, Mike Schmidt, Doug Steves and Ken Witte, from IBM Data Systems
Division, Johnny Barnes and Heinz Graalfs, from IBM Research, Marc Auslander,
from IBM Technical Computing Systems, Larry Breed, Bruce Campbell, Sanjay
Challani, Tu-An Cheng, Tri Ha, Chirag Jain, Jason Kosol, Betty Lee, Derrick Mar,
Teri McConnell, Lisa Repka (now with Evans and Sutherland), Laura Richardson
and Dave Zittin (now with Sun Microsystems), from Lachman Associates
Incorporated, Jim Norris, from LOCUS Computing Corporation, Bob Peterson,
and from Sunday and Associates, Roy Gordon.
REFERENCE:
1. L.K. Loucks and C.H. Sauer, "Advanced Interactive Executive (AIX) Operating
System Overview," IBM Systems Journal 26, 4 (1987).
--
Charlie Sauer IBM AES/ESD, D18/802 uucp: ut-sally!ut-emx!ibmaus!sauer
11400 Burnet Road csnet: ibmaus!sauer@EMX.UTEXAS.EDU
Austin, Texas 78758 aesnet: sauer@auschs
(512) 823-3692 vnet: SAUER at AUSVM6
-----------------------------
From: Roy Smith <roy@phri.uucp>
Subject: Re: Will 4.2 select() catch OOB socket messages?
Date: 13 Jun 88 13:35:15 GMT
To: unix-wizards@SEM.BRL.MIL
sean@ms.uky.edu (Sean Casey) writes:
>I can't seem to pick up Out Of Band messages with select().
I'm not surprised. I sat down a while ago to do a rewrite of the
BSD rlogin client (which depends on OOB data) to run as a native suntool
(as opposed to having to do shelltool/csh/rlogin). Anyway, what I
discovered is that 1) the BSD OOB documentation is sketchy and incomplete
(and possibly wrong) and 2) the whole concept behind the BSD OOB code is
horrible. I'm not sure how the original "framers of TCP" intended OOB to
work, but I can't believe it's how Berkeley implemented it. Possibly the
problem was that Berkeley was trying to make OOB work on XNS as well as
TCP? Disclaimer: I'm far from a networking guru; I fully expect better
answers to come from the regular network wizards. Also, my answer is based
on my experiences with MtXinu 4.3BSD/NFS on a vax and SunOS-3.2 (a 4.2
derivitive, with some 4.3isms thrown in).
> I'm calling select() with a read fdset and an exception fdset [...] if a
> client sends an OOB, the select does not return as it should.
One possible problem is that IB (in band) and OOB data seem to get
stacked, and the reception of the SIGURG and/or select(exceptionfd)
returning is done when the networking software first finds out that OOB
data is pending. Unfortunately, depending on how much IB data is in the
input queue, you may not yet be able to read the OOB data. This seems
pretty bogus to me and may be part of your problem. One way around it is
to make sure that you read any queued IB data (do non-blocking reads until
you get EWOULDBLOCK) before trying to read the recv() the OOB data.
Another problem with OOB data is that, as far as I can tell, the
concept of "at the mark" is very poorly defined. If you do the following
in a server:
fd = socket();
for (1) {
select (fd for exceptions);
recv (fd, MSG_OOB);
};
and have the client send() a single OOB datum, the server will loop forever
reading the same OOB message as if you had given MSG_OOB|MSG_PEEK. As
mankin@gateway.mitre.org put it in a recent letter to me on this subject,
"The trick is that the system signals the mark both before and immediately
after the octet has been read. The mark signal only goes off when data
after the mark is read from the receive queue. The mark is, in effect, on
both sides of the urgent byte"
I cannot find any reason why such behavior should be considered the
correct way of doing things and can only conclude that OOB data, while a
very nice concept, is broken enough in BSD as to be virtually unusable. In
my case, I didn't have a choice; I had to interact with an existing server
which use OOB. If you have the freedom to design the entities on both
sides of the connection, I would say to stay away from OOB if at all
possible.
--
Roy Smith, System Administrator
Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
-----------------------------
From: Barry Shein <bzs@bu-cs.bu.edu>
Subject: Re: Vax 11/780 performance vs Sun 4/280 performance
Date: 13 Jun 88 15:56:30 GMT
To: unix-wizards@SEM.BRL.MIL
>How do they get that kind of throughput? I refuse to believe that it's
>all hardware. Mainframe disks rotate at 3600 RPM like everybody else's
>and their 3 MB/s transfer rate is only slightly higher than a SuperEagle.
>A 2-MIPS CPU would be inadequate to run a BSD filesystem at those speeds,
>so obviously their software overhead is a lot lower, while at the same
>time wasting no disk time. What is VM doing efficiently that Unix does
>inefficiently?
>
>Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck
I think a lot of it *is* hardware. I know the big mainframes better
than the small ones. I/O devices are attached indirectly thru channel
controllers. Channels have their own paths to/from memory (that's
critical, multiple DMAs simultaneously.) Also, channels are
intelligent, I remember people saying the channels for the 370/168 had
roughly the same computing power as the 370/158 (ie. one model down,
sort of like saying that Sun3/280's use Sun3/180's as disk
controllers, actually the compute power is very similar in that
comparison.)
Channels execute channel commands directly out of memory, sort of
linked list structs in C lingo, with commands, offsets etc embedded in
them (this has become more common in the mini market also, the UDA is
similar tho I don't know if it's quite as general.) Channels can also
do things like search disks for particular keys, hi/lo/equal, without
involving the central processor. I don't know how much this is used in
the various filesystems, obviously a general data base thing.
The channels themselves aren't all that fast, around 3MB/sec, but 16
of them pumping simultaneously to/from different blocks of memory can
certainly make it feel fast.
I heard IBM recently announced a new addition to the 3381 disk series
(these are multi-GB disks) with 256MB (1/4 GB) of cache in the disk.
Rich or poor it's better to be rich.
The file systems tend to be much simpler (they avoid indirection at
the lower levels), at least in OS, which I'm sure contributes to the
performance, I/O is very asynchronous from a software perspective so
starting multiple I/Os is a natural way to program and sit back
waiting for completions. Note that RMS in VMS tries to mimic this kind
of architecture, but no one ever accused a Vax of having fast I/O.
A lot of what we would consider application code is in the OS I/O
code, known as "access methods", so reading various file formats
(zillions, actually, VSAM, ISAM, BDAM, BSAM...) and I/O disciplines
(VTAM etc) can be optimized at the "kernel" level (there's also
microcode assist on various machines for various operations), it also
tends to push applications programmers towards "being kind" to the OS,
things like pre-allocation of resources is pretty much enforced so a
lot of the dynamic resource management is just not done during
execution.
There is little doubt that to get a lot of this speedup on Unix
systems you'd have to give up niceties like tree'd directories,
extending files whenever you feel like, dynamic file opening during
run-time (OS tends to do deadlock avoidance rather than detection or
recovery so it needs to know what files you plan to use before your
jobs starts, that explains a *lot* of what JCL is all about,
pre-allocation of resources), etc. You probably wouldn't like it, it
would look just like MVS :-)
You'd also have to give up what we call "terminals" in most cases, IBM
terminals (327x's) on big systems are much more like disks,
half-duplex, fill in a screen locally and then blast entire screens
to/from memory in one block I/O operation, no per-char I/O. Emacs
would die. It helps, especially when you have a lot of terminals. I
read about an IBM transaction system with 15,000 terminals logged in,
I said a lot of terminals.
But don't underestimate raw, frothing, manic hardware.
It's a big trade-off, large IBM mainframes are to I/O what Crays are
to floating point, but you really have to have the problem to want the
cure, for most folks it's unnecessary, MasterCard etc excepted.
-Barry Shein, Boston University
-----------------------------
From: Barry Shein <bzs@bu-cs.bu.edu>
Subject: Re: OSF: A Desperation Move?
Date: 13 Jun 88 16:01:31 GMT
To: unix-wizards@brl-sem.arpa
>In article <23284@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes:
>> From: pavlov@hscfvax.harvard.edu (G.Pavlov)
>> >In article <23257@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes:
>> >> IBM is a $60 Billion dollar corporation, the ENTIRE PC market, IBM,
>> >> Compaq, Apple etc is perhaps several billion, IBM's share is probably
>> >> on the order of $2...3B.
>> > You're off by at least an order of magnitude.
>> In which direction??? Which number (there are 3 in that quote)???
>> (that was real helpful!)
>> Actually, I doubt I'm off by much, cite? Major trade rags gladly
>> accepted.
>
> The micro nos; way too low. The best "trade rag" nos. will be in next Data-
> mation's annual industry survey. Verifiable figures are that Apple is at
> $3B annual sales, Compaq over $1B. Unverifiables for IBM are 10%-15% of
> their total sales are in the "PC market". Tandy claims > $1B. Then there
> are multi-100 millions such as Zenith, HP, Olivetti, etc, etc. This is a
> huge market.
>
> greg pavlov.
Sure is, sounds like several billion...(an order of magnitude would
make that, say, 50+Billion, I don't believe that, I think after the
biggies you named it drops off real fast.)
-Barry Shein, Boston University
-----------------------------
From: J Greely <jgreely@tut.cis.ohio-state.edu>
Subject: Re: grep replacement (first match only per file)
Date: 13 Jun 88 18:47:23 GMT
To: unix-wizards@SEM.BRL.MIL
In article <16148@brl-adm.ARPA> rbj@cmr.icst.nbs.gov (Root Boy Jim) writes:
>? From: J Greely <jgreely@dimetrodon.cis.ohio-state.edu>
>[replacement solution deleted]
>Don't forget about xargs.
Don't forget about non-SYSV sites! (There is a simple replacement for
xargs in comp.sources.unix Volume 3, but not everyone has this).
--
(jgreely@cis.ohio-state.edu; ...!att!cis.ohio-state.edu!jgreely)
Team Wheaties says: "Just say NO to rexd!"
/^Newsgroups: .*\,.*\,.*\,/h:j /[Ww]ebber/h:j
/[Bb]irthright [Pp]arty/j /[Pp]ortal/h:j
-----------------------------
From: "Lawrence V. Cipriani" <lvc@tut.cis.ohio-state.edu>
Subject: Re: ksh incompatabilities with sh?
Date: 13 Jun 88 20:53:42 GMT
To: unix-wizards@SEM.BRL.MIL
In article <16147@brl-adm.ARPA> rbj@ICST-CMR.ARPA (Root Boy Jim) writes:
?? From: "Lawrence V. Cipriani" <lvc@tut.cis.ohio-state.edu>
...
?? Many of our customers still use ^ for pipes, that's what they got used
?? to. They have been using various versions of UNIX for at least 12 years.
?? Old habits die hard as the saying goes.
?What I want to know is how they got used to it. Hasn't `|' *always* been
?the symbol for a pipe? When was `^' introduced? A history lesson please!
Before the Bourne shell there was the Mashey shell. It supported ^ for
the pipe symbol not |. This was a very primitive shell. A lot of its
functionality was in separate programs due to limited memory size.
For example wild card were expanded in a separate process, yuck.
When the Bourne shell was written it inherited the ^, not sure why
the change occurred. Maybe it wasn't universally available, or perhaps
it was just easier to type on Bourne's terminal :-).
--
Larry Cipriani, AT&T Network Systems and Ohio State University
Domain: lvc@tut.cis.ohio-state.edu
Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (strange but true)
-----------------------------
From: Charlie Sauer <sauer@auschs.uucp>
Subject: Re: assert(status(PCjr)==status(RT/PC))
Date: 13 Jun 88 12:08:34 GMT
Posted: Mon Jun 13 08:08:34 1988
To: unix-wizards@SEM.BRL.MIL
Assertion failed: status(PCjr)==status(RT/PC), file comp.unix.wizards, line ...
The PCjr is no longer manufactured or marketed.
The RT/PC is actively manufactured, marketed and sold. There have been ongoing
announcements and shipments of enhancements to the RT, and there is active
development of the RT and follow on RISC products. Bill Lowe, President of IBM
Entry Systems Division, has been quoted as saying "We are investing as much
hardware development resource enhancing our RISC-based products as we are
on PS/2."
--
Charlie Sauer IBM AES/ESD, D18/802 uucp: ut-sally!ut-emx!ibmaus!sauer
11400 Burnet Road csnet: ibmaus!sauer@EMX.UTEXAS.EDU
Austin, Texas 78758 aesnet: sauer@auschs
(512) 823-3692 vnet: SAUER at AUSVM6
-----------------------------
From: King Ables <ables@hi3.aca.mcc.com.uucp>
Subject: mods to ksh for YP using getpwnam() (LLLOOOONNNNGGGGG)
Date: 13 Jun 88 16:36:14 GMT
Posted: Mon Jun 13 11:36:14 1988
To: unix-wizards@SEM.BRL.MIL
Re: fixing ksh to understand ~username when running YP
Well, I got quite a few suggestions to fix my problem.
Unfortunately, no one of them actually fixed anything for me.
I think that is a function of the fact that we have a fairly
old version of ksh. We are investigating getting the newest
one, but bad things happen when our Purchasing group gets
together with AT&T, so I decided I'd better pursue a solution
given the version we already have!
First, I'd like to thank everyone who contributed ideas. I received
a number of suggestions as well as some pleas for me to send whatever
I learned along to others. So I am doing just that. Below I include
the ideas I received along with my experiences trying them out on my
problems. This is going to be a LONG message!
I did finally manage to figure out the various problems involved and
using a couple of these fixes plus one of my own I now have a working
version of ksh. This is the last time I decide to start a "20 minute
project" on a Friday afternoon!!! ;-)
> Date: Wed, 1 Jun 88 20:37:52 EDT
> From: Glenn Barry <glenn@emory.arpa>
> Subject: ksh yp tilde fix
>
> Hi King,
>
> I fixed the latest version of ksh (ksh-i) to handle the yp tilde stuff.
> I'm pretty sure the same fix will work for your older version of ksh.
> A friend says that Dave Korn said it will really be fixed in the next
> release. You will need SunOS 3.X source code (which I think you mentioned
> you had) for this to work. BTW, this works on SunOS 3.4 but
> should work under 3.5, too.
>
> The recipe is below. Let me know if you have any problems.
>
> Glenn T. Barry | {sun!sunatl,gatech}!emory!glenn UUCP
> Emory University | glenn@emory BITNET
> Dept of Math and CS | glenn@emory.ARPA ARPA,CSNET
> Atlanta, GA 30322 | Phone: (404) 727-5637
>
> --------------------------------------------------------------------------
>
>
> 1) Replace passwdent() in ksh/shlib/tilde.c with the following code:
>
> #include <pwd.h>
> static char buf_pwf[BUFSIZ];
>
> /*
> * This new version of passwdent() uses getpwnam(3) to read the passwd
> * file rather than reading the file itself. It is necessary
> * inorder for yp passwd file id extensions (+,-,@) to work correctly.
> * emory!glenn 3/18/88
> */
> static int passwdent(user)
> char *user;
>
> {
> struct passwd *pw_ent;
>
> if((pw_ent=getpwnam(user))==NULL)
> return(-1);
> else
> {
> strcpy(u_logdir, pw_ent->pw_dir);
> strcpy(u_name, user);
> return(0);
> }
> }
>
> 2) Get the getpwent.c (contains getpwnam(3) stuff) file from SunOS 3.X source
> (I used 3.3). Delete the '#include <stdio.h>' and '#include <pwd.h>'
> lines from the beginning of the file. Add the following line to
> setpwent() after the 'pwf = fopen(PASSWD, "r");' line:
>
> setbuf(pwf, buf_pwf);
>
> This is the key. The 'setbuf' makes 'buf_pwf' be used for the stdio buffer
> for stream 'pwf', rather than the buffer coming via malloc (which
> is trouble because ksh does its own memory management).
>
> 3) Now add the modified getpwent.c to the end of the tilde.c file and
> remake and it should work.
This is very close to what I needed, but it didn't fix absolutely
everything. After I made this fix, I began to have a problem where
it would work for a few "echo ~username" commands and THEN bomb.
But I began to understand the problem. It is closely related to
the fact that ksh has it's own malloc() and free() among other
things! This has been discussed on the net recently so I won't
venture an opinion on it (yes, I will, I think it SUCKS!). Ahem.
Excuse me. ;-)
The fixes for me were a little different since my version of ksh
had no passwdent() routine. I've got a tilde.c which has tilde()
and logdir(). logdir() is where /etc/passwd was opened and read,
so I added the getpwnam() call there and stripped out much of that
routine that dealt with /etc/passwd.
Someone also suggested the following fix:
1) add a copy of fopen that calls fdopen.
2) fix io.h so that _N_STATIC_IOBS or whatever it is is set to 20
instead of 3.
which someone might want to try on the newer versions. This did
me no good since my io.h didn't contain _N_STATIC_IOBS or anything
close to it. I played around with fopen() and fdopen() for a bit
but couldn't make anything good come of it. Since my basic problem
was buffers stepping on each other, I can see how this would fix
the problem since ksh has it's own fdopen(), too.
> Date: Fri, 3 Jun 88 13:07:39 EDT
> From: keenan@inmet (Keenan Ross )
> Subject: Ksh for the suns
>
> I haven't actually done any of this, but here are a couple of mail
> messages from a co-worker which describe what he did to ksh to get
> it to work on the suns, addressing the '~' problem specifically.
> Hope this helps.
> --keenan ross UUCP: {bellcore,ima,ihnp4}!inmet!keenan
> Intermetrics, Inc. INTERNET: keenan@inmet.inmet.com
> 733 Concord Ave.
> Cambridge, MA 02138 PHONE: (617) 661-1840
>
> >>>>>>erikl@pba.inmet.com Thu Apr 30 13:47:49 1987
>
> I don't know if you care, but I fixed the tilde '~' problem in ksh
> on the suns. Instead of opening the file /etc/passwd, I open a pipe
> with the command "ypcat passwd". The following two lines (appropriately
> placed in src/shlib/tilde.c) will do the trick:
>
> At line 114 replace:
> if((fd=fdopen(open("/etc/passwd",0),"r"))==NULL)
> with
> if((fd=popen("ypcat passwd","r"))==NULL)
>
> At line 153 replace:
> fclose(fd);
> with
> pclose(fd);
>
> To bring ksh up on the RCE Suns I had to make the following changes:
>
> ================ File: sh/io.h =============
> 44a45,47
> > #ifndef _NFILE /* true for bsd 4.3 */
> > #define _NFILE 20
> > #endif
> sh/makesh:
> 66c66
> < then NOBUF=-DNOBUF DATA='data$$'
> ---
> > then NOBUF=-DNOBUF DATA='data$$' D4_2=-DBSD_4_2 JOBLIB=
> ================ File: sh/io.c =============
> 33,35c33,35
> < # ifdef BSD4_2
> < # include <fcntl.h>
> < # endif BSD4_2
> ---
> > # ifdef BSD_4_2
> > #include <fcntl.h>
> > # endif BSD_4_2
> ================ File: sh/makefile =============
> 30c30
> < # D4_2 = -DBSD_4_2
> ---
> > D4_2 = -DBSD_4_2
> 84c84
> < $(C) -O -S -c ctype.c ;\
> ---
> > $(C) -O -S ctype.c ;\
> 95c95
> < $(C) -O -S -c msg.c ;\
> ---
> > $(C) -O -S msg.c ;\
I thought of this solution early and was keeping it my back
pocket if it was the only way. But it sure slows things down
a lot! It has the virtue of working in all cases, however.
This one was posted, but in the interest of completeness I will
include it...
> From: dupuy@douglass.columbia.edu (Alexander Dupuy)
> Newsgroups: comp.unix.wizards
> Subject: Re: Speaking of ksh
> Date: 4 Jun 88 11:35:28 GMT
>
> In article <300@hi3.aca.mcc.com.UUCP> King Ables writes: We recently converted
> >a sun server to run YP (like the rest of the ones in our department) and I was
> >asked to fix ksh so that ~username would work again (since there is no
> >significant passwd file on the clients of that server anymore).
>
> >I thought to myself "no big deal... probably just a recompile so the
> >getpwnam() call works with YP." WRONG. Of course, ksh opens the passwd file
> >and reads it. OK. Big deal, I yank that code and I put in a call to
> >getpwnam() instead... seemed real simple. But ever since then I've been
> >getting segmentation faults down in the bowels of the YP code.
>
> >Has anybody "fixed" ksh anywhere to do this? I can't believe it can be *THAT*
> >difficult...
>
> Here's the fix: (credit to Chris Maio for finally tracking this down - why he
> has to wait until we started running YP on his workstation I don't know :-)
>
> First rip out the crap in shlib/tilde.c and make it use getpwnam() instead.
> (It sounds like you have already done this).
>
> Then, patch sh/io.c (your line numbers will vary).
>
> *** old/io.c Wed Nov 18 11:17:03 1987
> --- io.c Sat Dec 5 18:19:57 1987
> ***************
> *** 606,611 ****
> --- 610,622 ----
>
> if ((iop->_flag&_IOREAD) == 0)
> return(EOF);
> +
> + #if BUGFIX
> + /* will this let us call getpwnam? */
> + if (iop->_base == 0)
> + _findbuf(iop);
> + #endif BUGFIX
> +
> if(fnobuff(iop))
> {
> /* unbuffered reads needed for pipes */
>
> This patch is for ksh-i, but it ought to work for the older ksh as well.
>
> @alex
> --
> inet: dupuy@columbia.edu
> uucp: ...!rutgers!columbia!dupuy
This was the key to my eventual success. The fact that the iop
buffer doesn't seem to be allocated at this point is were my problems
began. This fix combined with Glenn Barry's above (including code
from YP with a minor fix in it) fixed my interactive ksh. I thought I was
all done at that point until I ran ksh on a file of commands (ksh script)
to test many many of these things. It bombed then with the SAME OLD PROBLEM.
Obviously there was something different about running ksh interactively
and running it on a file. I began to suspect that the above problem also
applied to the file descriptor being opened when reading from a file.
I then set about looking for the same type of operation as above on
a file descriptor planning to make the same fix.
In io.c, I found the ksh copy of fdopen() and found that they
create a buffer iop and assign iop->_base to NULL. I took a shot
and added another _fillbuf(iop) call after that and then the script
worked! SUCCESS!
This one was posted too, but is included (again) in the interest
of completeness.
> From: cliff@hcx1.SSD.HARRIS.COM
> Newsgroups: comp.unix.wizards
> Subject: Re: Speaking of ksh
> Date: 3 Jun 88 11:27:00 GMT
>
> ... summary of original message deleted ...
>
> We solved this problem (on our HCX series of machines running HCX/UX 3.0)
> by using getpwnam() just as you did. We found that the first call takes
> a long time since the _filbuf() used in ksh is incompatible with the standard
> one. All open()'s in ksh are immediately followed by a setbuf() call. The
> open() buried inside of getpwnam() is not. The _filbuf() built into
> ksh does not allocate a buffer for a buffered file if one is needed. We
> extracted the code from the standard _filbuf() which does this and
> don't have any performance, functionality, or realiability problems.
> -------------------------------------------------------------------------
> Cliff Van Dyke cliff@ssd.harris.com
> Harris Computer System cliff%ssd.harris.com@eddie.mit.edu
> 2101 W. Cypress Creek Rd. ...!{mit-eddie,uunet,novavax}!hcx1!cliff
> Ft. Lauderdale, FL 33309-1892
> Tel: (305) 974-1700
This message helped me to understand what the basic problem
throughout all the various versions of ksh was... there seem to
be a number of different ways to solve it, but the same common
thread seems to run through all the dialogue I received. The
i/o buffers aren't allocated in a consistent manner (probably due
to the duplicated system calls) and we get in trouble.
Also posted:
> Date: Fri, 3 Jun 88 10:30:14 BST
> Subject: Re: Speaking of ksh
> Newsgroups: comp.unix.wizards
> From: mcvax!cs.bham.ac.uk!BattenIG@uunet.UU.NET
>
> In article <300@hi3.aca.mcc.com.UUCP> you write:
> > We recently converted a sun server to run YP (like the
>
> There is a known bug in the YP code get getpwent-type operations if (1) the
> password required is NOT in the local /etc/passwd has "really" has to
> come across the net and (2) you have more than, I think, 128 entries in
> the YP table "passwd". A (source) fix was posted to sunspots a while
> back ....
>
> ian
While we haven't noticed this problem at our site, I am planning to
investigate this one a little more. However, it seems not to be
related to our ksh problems.
Thanks again to all who responded. For those of you who simply asked
to be informed of what I found out, I hope this helps. To take some
of the confusion out of the above multiple fixes, below are the diffs
*I* made to our version of ksh from the distribution to make it work
under BSD with YP. I hope this helps someone somewhere.
---------------------------------sh/Makefile----------------------
20c20
< DBSD = -BSD
---
> # DBSD = -BSD
---------------------------------sh/io.c----------------------
84a85,87
> #ifdef BSD
> register char *s;
> #else
85a89
> #endif BSD
186d189
<
193,201d195
<
< /*
< * --MCC--
< *
< * opening the fd has the same problem of assigning
< * the buffer incorrectly... we know iop->_base is null, so...
< */
< _findbuf(iop);
<
604,612d597
< /*
< * --MCC--
< * added code to fix getpwnam() bomb
< */
< if (iop->_base == NULL)
< _findbuf(iop);
< /*
< * END
< */
---------------------------------sh/io.h----------------------
1c1
< /* @(#)io.h 1.3 */
---
> /* @(#)io.h 1.2 */
9,10d8
<
< #include <sys/param.h>
---------------------------------sh/makefile----------------------
27,28c27,28
< DBSD = -DBSD
< LFLAGS = -z
---
> # DBSD = -DBSD
> # LFLAGS = -z
30c30
< D4_2 = -DBSD_4_2
---
> # D4_2 = -DBSD_4_2
40c40
< NOBUF=-DNOBUF
---
> # NOBUF=-DNOBUF
85,87c85
< # sed 's/^\([ ]*\.*\)$(DATA)/\1$(FIXDATA)/g' ctype.s > temp.s ;\
< # don't do the above, just use the file as is ;\
< cp ctype.s temp.s ;\
---
> sed 's/^\([ ]*\.*\)$(DATA)/\1$(FIXDATA)/g' ctype.s > temp.s ;\
98,100c96
< # sed 's/^\([ ]*\.*\)$(DATA)/\1$(FIXDATA)/g' msg.s > temp.s ;\
< # don't do the above, just use the file as is ;\
< cp msg.s temp.s ;\
---
> sed 's/^\([ ]*\.*\)$(DATA)/\1$(FIXDATA)/g' msg.s > temp.s ;\
---------------------------------sh/makesh----------------------
65,71c65
< #
< # they were checking to see if the /usr/suntool directory existed
< # to see if we were a sun .. maybe it used to on suns, but it doesn't
< # now, so we'll check for existence of executable /usr/bin/suntools
< # instead... the old test was "test -d /usr/suntool"
< #
< if test -x /usr/bin/suntools #sun workstations
---
> if test -d /usr/suntool #sun workstations
---------------------------------shlib/tilde.c----------------------
12a13,16
> *
> * Additions by King Ables, June 1988.
> * Make it work for YP in ACA at MCC.
> * (look for "--MCC--")
15d18
<
86a90,98
> *
> * --MCC--
> * They originally read the passwd file... and DIDN'T call getpwnam()!
> * So of course, under YP it didn't work... call getpwnam() instead
> * so that it works either way!
> *
> * Not trivial because some buffers step on each other since ksh
> * has it's own malloc() and free() (among other things)!! Must
> * include some YP source code slightly modified to make it work.
88a101,107
> /*
> * --MCC--
> *
> * add /usr/include/pwd.h for getpwnam()
> */
> #include <pwd.h>
>
92,98c111,113
< register FILE *fd;
< register char *sp=user;
< register int c;
< char *rval = NULL;
< char buff[BUFSIZ];
< int ncol = 4; /* number of colons before home directory entry */
< if(strlen(sp)>=UNAME)
---
> struct passwd *pw_ent;
>
> if(strlen(user)>=UNAME)
100c115,116
< if(strcmp(sp,u_name)==0)
---
>
> if(strcmp(user,u_name)==0)
102,143d117
< if((fd=fdopen(open("/etc/passwd",0),"r"))==NULL)
< return(NULL);
< setbuf(fd,buff);
< /* one line at a time */
< do
< {
< /* read until eof or end-of-field or name doesn't match */
< while((c=getc(fd))!=EOF && c!=':' && *sp++==c);
< if(c==':'&& *sp==0)
< {
< /* match with user found, skip to logdir entry */
< sp = u_logdir;
< while((c=getc(fd))!=EOF && c!= '\n')
< {
< if(c==':' && --ncol==0)
< {
< /* now copy into u_logdir */
< while((c=getc(fd))!=EOF && c!=':'&& c!='\n')
< {
< *sp++ = c;
< /* see if too big */
< if(sp >= (u_logdir+LOGDIR))
< goto leave;
< }
< break;
< }
< }
< *sp = 0;
< strcpy(u_name,user);
< rval = u_logdir;
< goto leave;
< }
< /* skip to end-of-line */
< while((c=getc(fd))!=EOF && c != '\n');
< sp = user;
< }
< while(c != EOF);
< leave:
< setbuf(fd,NULL);
< fclose(fd);
< return(rval);
< }
144a119,128
> pw_ent = getpwnam(user);
> if (pw_ent == NULL) {
> return (NULL);
> }
> else {
> strcpy(u_logdir, pw_ent->pw_dir);
> strcpy(u_name, user);
> return(u_logdir);
> }
> }
---------------------------comments about tilde.c------------------
I didn't include the diffs for the rest since it would have included
the entire contents of getpwent.c since it wasn't there before.
I append the contents of getpwent.c to the end of tilde.c but make
the following changes:
1) remove #includes for stdio.h and pwd.h (would redefine)
2) remove definition "extern char *strcpy()" (would also redefine)
3) add definition for a buffer after "static FILE *pwf = NULL;"
that says:
static char buf_pwf[BUFSIZ];
4) in the routine setpwent() I changed the following
statement:
if (pwf == NULL)
pwf = fopen(PASSWD, "r");
else
rewind(pwf);
to:
if (pwf == NULL) {
pwf = fopen(PASSWD, "r");
setbuf(pwf, buf_pwf);
}
else
rewind(pwf);
-----------------------------------------------------------------
King Ables
Microelectronics and Computer Technology Corporation (MCC)
3500 West Balcones Center Drive
Austin, TX 78759
(512) 338-3494 (office)
(512) 343-0978 (switchboard)
ARPA: ables@mcc.com
UUCP: {gatech,ihnp4,nbires,seismo,ucb-vax}!ut-sally!im4u!milano!ables
-----------------------------
From: David Elliott <dce@mips.com>
Subject: Magic symlink syntax
Date: 13 Jun 88 15:55:48 GMT
Keywords: nami hack, namei hack
To: unix-wizards@SEM.BRL.MIL
We are in the process of considering a system modification that systems
folks lovingly refer to as the "nami hack" (or "namei hack" for BSD folks).
This is the modification that allows one to put a variable inside of
a symbolic link target so that people can choose default execution
"universes" or "modes" or "system types".
I believe that the Apollo Domain/IX syntax was '($name)' or '$(name)'.
I'd like to get a list of those currently available, as well as the
pros and cons of each syntax.
Also, if other people have come up with functionally similar systems
that use a different mechanism, I'd like to hear about those as well.
--
David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
-----------------------------
From: David Elliott <dce@mips.com>
Subject: Symlinks vs. NFS
Date: 13 Jun 88 16:15:08 GMT
To: unix-wizards@brl-sem.arpa
We have run across a problem with NFS and symlinks that we would like
to solve.
Assume you have a remote path that is actually a symlink.
If that symlink is absolute, the filesystem resolves this path to the
local machine. That is, if the link is to "/etc/passwd", the
resolution is to my /etc/passwd instead of the one on the remote
machine.
If the symlink is relative, the resolution depends on how I have the
filesystems mounted. Assume that the link is in the directory /usr/foo
on the other machine, and that the link is to "../../etc/passwd". Now,
if my system has the remote /usr and remote / mounted in the "typical"
relationship (that is, /usr is mounted on /), and that /usr/foo and
/etc on that machine are set up typically as well, everything works as
expected. If, on the other hand, I have the remote /usr/foo mounted in
my /usr just so I can use it, the link resolves to my local /etc/passwd
again.
What kind of solutions exist for this problem? Do these solutions
take into account the possibility that the target of the symlink may
not be on a mounted filesystem?
--
David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
-----------------------------
From: Neil Webber <nw@palladium.uucp>
Subject: Re: alloca & coroutining
Date: 12 Jun 88 16:06:08 GMT
Followup-To: comp.lang.c
To: unix-wizards@SEM.BRL.MIL
In article <16126@brl-adm.ARPA> ted%nmsu.csnet@relay.cs.net writes:
>
>But isn't the following idiom for co-routines useful?
>
> [ sample coroutine implementation deleted ]
>
Not on a vax running 4.3BSD it isn't:
Script started on Sun Jun 12 11:20:08 1988
% cc -o coroutines coroutines.c
% ./coroutines
a b c
longjmp botch
Illegal instruction (core dumped)
%
script done on Sun Jun 12 11:20:28 1988
This happens because, as Chris Torek points out:
>longjmp is not suitable for coroutines because it is valid
>for longjmp to attempt to unwind the stack in order to find
>the corresponding setjmp, and it is therefore legal for
>longjmp to abort if it is attempting to jump the `wrong way'
>on the stack.
I don't believe that there is a portable way to *implement* a
coroutining library in C, short of first implementing a processor
emulation and then writing code for that processor :-). Perhaps
someone can prove otherwise.
The coroutining code posted by ted%nmsu.csnet@relay.cs.net does
work on our Sun 3, *with the Sun compiler*. It does not work with the
Greenhills compiler unless you take care to throw all the right
compiler switches (force frame pointers, no delayed stack adjustments).
David DiGiacomo (david@sun.uucp) suggests that the C compiler
recognize alloca() as a special case. This certainly appears to
be the way of the, er, umm, future. After all, inlining those
strcpy calls gets the Dhrystone numbers way up ;-}
--
Neil Webber / Epoch Systems, Marlboro MA / (617) 481-3717
{harvard!cfisun, linus!alliant}!palladium!nw
-----------------------------
From: "Bruce G. Barnett" <barnett@vdsvax.steinmetz.ge.com>
Subject: Tool -flag considered harmful (was: grep replacement)
Date: 13 Jun 88 14:20:30 GMT
Posted: Mon Jun 13 10:20:30 1988
To: unix-wizards@brl-sem.arpa
I am disturbed by the growing trend by AT&T to remove as many flags as
possible from common utilities. I understand that too much baggage
can slow down a finely tuned utility used for time-consuming shell
scripts.
But when *I* have a problem I want to solve, I want to solve it as
fast as possible.
If there is a 'variation' that I need that I don't know how to do, I
read the manual page of the program that is closest to the
functionality that I can think of. That is, if I want to look for a
particular pattern, I start with grep. If it does what I want, fine.
(Example: print the first match and exit).
But if grep doesn't do what I want, I have to hunt for a new command,
or write my own.
It is not obvious that a "stream editor" has the functionality of
grep. Even after reading the manual page, this is NOT OBVIOUS.
I also don't (always) have time to study the manual pages for hours,
trying to decipher the *real* intent of the tools.
If I want to use grep to test for a pattern, I shouldn't have to
remember that two years ago in *.wizards, article <7962@alice.UUCP>
suggested that
grep -1 pattern >/dev/null
was the same as
grep -s pattern
I mean, how many extra lines would supporting both options cost?
Conversely, how many scripts will break with the new set of options?
If I want to create a patch, I use diff.
If diff loses the -c (context) option, I have to be familiar with
two commands instead of one. One being diff, one being context diff.
Why should I have to know about two different commands that do the
same thing - compare two files?
Flame me if you will, but when I use these tools in an interactive
session, I don't care if 'cat -v' is slow. Or 'diff -c'. Or grep -whatever.
I just want to find out the answers as quickly as possible.
The grep on my system is one of the fast versions. If it gets a flag
it doesn't understand, it calls up the original version for compatibility.
So it executed two programs instead of one. This is still faster
(on my own wall clock) than
1. Searching the whatis database to find the 'right' command
2. Reading the manual page for the 'right' command
3. Writing a simple shell script because the manual pages don't
have examples.
4. Beating my head against the wall when I realize that the
new command doesn't do what I wanted EITHER.
With the use of Shared libraries, tools should improve. The idea of
one library with the same regexp package shared by all of the
utilities should do wonders for consistant tools.
I am all for progress. Just remember, that there are tools used by the
system, and tools used by humans. Maybe I am a Neanderthal, because
I have this rock here that I do everything with...... :-)
--
Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP>
uunet!steinmetz!barnett
-----------------------------
From: Andrew Klossner <andrew@frip.gwd.tek.com>
Subject: Re: grep replacement
Date: 13 Jun 88 22:49:19 GMT
Sender: andrew@tekecs.tek.com
Posted: Mon Jun 13 18:49:19 1988
To: unix-wizards@brl-sem.arpa
[]
"so far, gre will have only one limit, a line length of 64K.
(NO, i am not supporting arbitrary length lines (yet)!)"
Why not a flag to let the user specify the max line length? Just the
thing for that database hacker, and diminishes the demand for arbitrary
length.
"there will be a -G flag to take patterns a la old grep and a
-F to take patterns a la fgrep"
I hope that -F is a permanent, not temporary, flag. I don't see it in
the summary list of supported flags, shudder.
"a unix without /dev/stdin is largely bogus but as a sop to the
poor barstards having to work on BSD, gre will support - as
stdin (at least for a while)."
It's not just BSD; I haven't seen /dev/stdin in any released edition.
I just looked over the sVr3.1 tape and didn't turn up anything.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
-----------------------------
From: Andrew Klossner <andrew@frip.gwd.tek.com>
Subject: egrep won't pick fields
Date: 13 Jun 88 22:52:24 GMT
Sender: andrew@tekecs.tek.com
Posted: Mon Jun 13 18:52:24 1988
To: unix-wizards@brl-sem.arpa
> grep '^........foo'
> picks up any line which has `foo' in columns 9-11..
True for grep, but egrep will say "Regular expression too long" if
there are six or more periods. I hope this problem goes away with gre.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.uucp>
Subject: Re: grep replacement
Date: 13 Jun 88 21:51:49 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@SEM.BRL.MIL
As quoted from <5007@sdcsvax.UCSD.EDU> by hutch@net1.ucsd.edu (Jim Hutchison):
+---------------
| 4537@vdsvax.steinmetz.ge.com, barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett)
| >In <1036@cfa.cfa.harvard.EDU> wyatt@cfa.harvard.EDU (Bill Wyatt) writes:
| >|> There have been times when I wanted a grep that would print out the
| >|> first occurrence and then stop.
| >|
| >|grep '(your_pattern_here)' | head -1
| >
| >There are times when I want the first occurrence of a pattern without
| >reading the entire (i.e. HUGE) file.
|
| I realize this is dependent on the way in which processes sharing a
| pipe act, but this is a point worth considering before we get yet
| another annoying burst of "cat -v" type programs.
|
| grep pattern file1 ... fileN | head -1
|
| This should send grep a SIGPIPE as soon as the first line of output
| trickles through the pipe. This would result in relatively little
| of the file actually being read under most Unix implementations.
+---------------
Not true. The SIGPIPE is sent when "grep" writes the second line, *not*
when "head" exits! If there *is* only one line containing the pattern, grep
will happily read all of the (possibly large) files without getting SIGPIPE.
This is not pleasant, even if it's only one large file -- say a
comp.sources.unix posting which you're grepping for a Subject: line.
--
Brandon S. Allbery | "Given its constituency, the only
uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about
Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is
comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.uucp>
Subject: Re: grep replacement and /dev/stdin
Date: 13 Jun 88 22:12:48 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@brl-sem.arpa
As quoted from <11821@mimsy.UUCP> by chris@mimsy.UUCP (Chris Torek):
+---------------
| In article <8022@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
| >By the way, I hope the new grep when asked to always produce
| >the filename will use "-" for stdin's name, and the context
| >tool would also follow the same convention. Even though the
| >Research systems have /dev/stdin, other sites may not,
|
| Why not? We (chris@mimsy.umd.edu and fred@mimsy.umd.edu) have posted
| an implementation at least twice. (Still could not get Berkeley to
+---------------
Sigh. Not all sites on the Usenet are 4.xBSD source sites, much less all
Unix sites. Ncoast is System III, telo1000 is System V.3.1. Neither will
run your BSD version, and while ncoast can have device drivers added it's a
pain in the butt to do. And some sites may not have a means of adding
device drivers at all.
--
Brandon S. Allbery | "Given its constituency, the only
uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about
Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is
comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
-----------------------------
From: Guy Harris <guy@gorodish.sun.com>
Subject: Re: grep replacement (first match only per file)
Date: 13 Jun 88 20:27:09 GMT
Sender: news@sun.uucp
To: unix-wizards@SEM.BRL.MIL
> ? This works, and is indeed faster. However, it shares one problem with
> ? all of the others: '*' expansion. As an (uncomfortable) example,
> ? /usr/spool/news/talk/bizarre has over 2500 articles in it at our site,
> ? and the shell can't expand that properly (SunOS 3.4, if it matters).
"Fixed in 4.0", perhaps: from 4.0's "sys/param.h":
#define NCARGS 0x100000 /* (absolute) max # characters in exec arglist */
(I don't know which versions of the shell can cope with 1MB argument lists, if
any.)
> Don't forget about xargs.
Assuming, of course, that your system has it; SunOS has it in releases 3.2 or
later (if you install the "System V Optional Software"; it's in "/usr/bin"),
but vanilla 4.xBSD doesn't, for example. I would not be at all surprised to
hear that there is some public-domain reimplementation out there somewhere.
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: grep replacement
Date: 14 Jun 88 03:54:41 GMT
To: unix-wizards@SEM.BRL.MIL
In article <44370@beno.seismo.CSS.GOV> keith@seismo.CSS.GOV
[at seismo?!?] (Keith Bostic) writes:
> -- The next full release of BSD will contain "/dev/stdin" and friends.
> It is not part of the 4.3-tahoe release because it requires changes
> to stdio.
Well, only because
freopen("/dev/stdin", "r", stdin)
unexpectedly fails: it closes fd 0 before attempting to open /dev/stdin,
which means that stdin is gone before it can grab it again. When I
`fixed' this here it broke /usr/ucb/head and I had to fix the fix!
The sequence needed is messy:
old = fileno(fp);
new = open(...);
if (new < 0) {
close(old); /* maybe it was EMFILE */
new = open(...);/* (could test errno too) */
if (new < 0)
return error;
}
if (new != old) {
if (dup2(new, old) >= 0) /* move it back */
close(new);
else {
close(old);
fileno(fp) = new;
}
}
Not using dup2 means that freopen(stderr) might make fileno(stderr)
something other than 2, which breaks at least perror().
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Landon Curt Noll <chongo@amdahl.uts.amdahl.com>
Subject: International Obfuscated C Code Contest winners to be announced
Date: 14 Jun 88 02:57:51 GMT
Keywords: IOCCC, BOF, Usenix
To: unix-wizards@brl-sem.arpa
The winners of the 1988 International Obfuscated C Code Contest will be
announced during the Usenet BOF. The Usenet BOF is currently scheduled
for Wed 6pm to 8pm. The IOCCC winners will be presented at 7pm during
the Usenet BOF.
The winners will be posted to the net after the Usenix conference, say
on June 27 or there abouts to comp.unix.wizards and comp.lang.c.
If you won't be at Usenix, and you won't be able to read the posting
then send a request to:
judges@uts.amdahl.com -or- ...!{uunet,sun,decwrl,ames}!amdahl!judges
chongo <happy hacking> /\cc/\
--
[views above shouldn't be viewed as Amdahl views, or as views from Amdahl, or
as Amdahl views views, or as views by Mr. Amdahl, or as views from his house]
-----------------------------
From: Keith Bostic <keith@seismo.css.gov>
Subject: Re: grep replacement
Date: 13 Jun 88 19:12:20 GMT
To: unix-wizards@SEM.BRL.MIL
In article <7962@alice.UUCP>, andrew@alice.UUCP writes:
> 22) support a filename of - to mean standard input.
> a unix without /dev/stdin is largely bogus but as a sop to the poor
> barstards having to work on BSD, gre will support -
> as stdin (at least for a while).
>
> Andrew Hume
> research!andrew
A few comments:
-- As far I'm aware, V9 is the only system that has "/dev/stdin" at the
moment. For those who haven't heard of it, V9 is a research version
of UN*X developed and in use at the Computing Science Research Center,
a part of AT&T Bell Laboratories, and available to a small number of
universities. It was preceded by V8, which, interestingly enough, was
built on top of 4.1BSD.
-- System V does not suppport "/dev/stdin".
-- The next full release of BSD will contain "/dev/stdin" and friends.
It is not part of the 4.3-tahoe release because it requires changes
to stdio. I do not expect, however, commands that currently support
the "-" syntax to change, for compatibility reasons. V9 itself
continues to support such commands.
To sum up, let's try and keep this, if not actually constructive, at least
bearing some distant relationship to the facts.
Keith Bostic
-----------------------------
End of UNIX-WIZARDS Digest
**************************