UNIX-WIZARDS Digest V5#077
Mike Muuss
Unix-Wizards-Request at arpa.brl
Thu Jun 23 17:45:19 AEST 1988
UNIX-WIZARDS Digest Thu, 23 Jun 1988 V5#077
Today's Topics:
Re: new grep
Re: UNIX-WIZARDS Digest V5#066
sh(1) command substitution and here documents
Re: new grep
Re: I'm going to hate myself
Re: back to the (ivory) tower
Re: I'm going to hate myself
Re: sh(1) command substitution and here documents
Re: Spooling to an Encore annex via lpd
Re: determine the current directory of a son-process (longish)
Re: ksh weird files
Re: Stdio (stderr) buffering question
Re: sh(1) command substitution and here documents
Re: Tool -flag considered harmful
Re: How good is Apollo UNIX? (was: O'pain Software Foundation: (2))
Re: Spooling to an Encore annex via lpd
implementing pseudo-asynchronous io on SYS5
Re: sh(1) command substitution and here documents
Re: Curses & Color
Re: UNIX-WIZARDS Digest
cmp efficiency
Re: Stdio (stderr) buffering question
-----------------------------------------------------------------
From: Mohamed Ellozy <mohamed at hscfvax.harvard.edu>
Subject: Re: new grep
Date: 21 Jun 88 12:20:18 GMT
Posted: Tue Jun 21 08:20:18 1988
To: unix-wizards at SEM.BRL.MIL
In article <16237 at brl-adm.ARPA> williams at nrl-css.arpa writes:
> Al Aho and I are designing a replacement for grep, egrep
> and fgrep. The question is what flags should it support and
> what kind of patterns ...
>
> I have always thought it would be nice to print only the first match.
>
> (Root Boy) Jim Cottrell <rbj at icst-cmr.arpa>
>
>I'll second this. There have been many times when I simply wanted to
>detect the presence of a pattern in a file, then stop searching. Combining
>this with the -n option can also be useful.
Also times when I am searching for something that is close to the start
of a long file (e. g. a host that is close to the start of /etc/hosts).
I can save time by doing a head -NNN | grep, but I must guess a suitable
value for NNN, while a grep that quits after the first match does it for
me.
-----------------------------
From: Stephen Samuel <rroot at edm.uucp>
Subject: Re: UNIX-WIZARDS Digest V5#066
Date: 21 Jun 88 23:52:44 GMT
To: unix-wizards at SEM.BRL.MIL
>From article <8806120245.aa01039 at SEM.BRL.ARPA>, by Unix-Wizards-Request at arpa.brl (Mike Muuss):
>> ... This is not an attempt to pick on Henry Spencer...
> Who, me, criticize Berkeley? Nah. :-)
....
> useful changes; Berkeley's problem is an excess of enthusiasm for new
> and nifty ideas, without adequate consideration of whether they are
> *good* ideas. This enthusiasm is no problem -- indeed, it's desirable --
> in a research lab that produces papers instead of software. But when the
> end product is software that thousands of sites end up depending on, one
> could wish for a bit more restraint.
Yeah, but they WERE a research lab that produced papers. I have this funny
feeling that, when they started out, they weren't expecting the number of
people that ended up using BSD to do so..
It's kinda like FORTRAN: You can't really blame them for the wonderful leap
that they made possible, but you can sure as shootin' scream bloody murder
about all the stumbles that came after the leap.
The only reason we're here, complaining abbout 4.X now, is that it was good
enough that it's progeny are proliferating about the whole UNIX world
(both the good and the bad, but the bad are SLOOOL...Y being stomped out).
We can't throw out the baby with the bathwater, but I agree that we
shouldn't keep the bathwater just because the baby's in it.
--
-------------
Stephen Samuel
{ihnp4,ubc-vision,vax135}!alberta!edm!steve
or userzxcv at uofamts.bitnet
-----------------------------
From: Jack Nelson <jack at cadre.dsl.pittsburgh.edu>
Subject: sh(1) command substitution and here documents
Date: 19 Jun 88 19:48:20 GMT
To: unix-wizards at SEM.BRL.MIL
The following shell script prints out 0.75 on a line and ends, which
seems to follow the sh(1) manual.
#!/bin/sh
bc <<End
scale = 2
3 / 4
End
What I would like to do is incorporate this calculation result into a shell
variable using the here document:
#!/bin/sh
var=`bc <<End
scale=2
3 / 4
End
`
But this doesn't work; an error message "cannot open /tmp/sh01383"
always is produced, both on 4.3 and 2.10 systems. Is there a way
to do this? Can one deduce this behavior from the manual?
I ended up using a one-line perl script; I suppose awk would work just as
well. Expr(1) won't do floats.
--
John P. Nelson, M.D., 3811 O'Hara St, Pittsburgh, PA 15213, t:412-624-1769 Dept. of Psychiatry, U. of Pittsburgh
UUCP: { akgua | allegra | cmcl2 | idis | ihnp4 | mi-cec | pitt | psuvax1 | sun | sunrise | vax135 } ! cadre ! jack
ARPA: jack at cadre.dsl.pittsburgh.edu
-----------------------------
From: "XMRP50000[jcm]-a.v.reed" <avr at mtgzz.att.com>
Subject: Re: new grep
Date: 21 Jun 88 18:29:38 GMT
To: unix-wizards at SEM.BRL.MIL
In article <16237 at brl-adm.ARPA>, williams at nrl-css.arpa writes:
< Al Aho and I are designing a replacement for grep, egrep
< and fgrep. The question is what flags should it support and
< what kind of patterns ...
<
< I have always thought it would be nice to print only the first match.
< (Root Boy) Jim Cottrell <rbj at icst-cmr.arpa>
< I'll second this. There have been many times when I simply wanted to
< detect the presence of a pattern in a file, then stop searching. Combining
< this with the -n option can also be useful.
This would be a good time to make the flags orthogonal and
consistent. Ideally, all standard output should be requested in
the same way, by specifying the corresponding flag. The default
should be something like the -s option today; the way to specify
one's own favorite options would be by defining an alias, e.g.
mygrep="grep -i -l -n -m"
The options I'd like to see are:
-l List paths (names) of files with matches
-n Number: list numbers of lines that match
-b Block: list block number for each match
-m Matching lines: list matching lines
-c Display a count of maching lines in each file
-o One: Don't search beyond one match per file
plus the -v, -i, -e, and -f options as they are now. Ideally,
there should be a new name; if the new tool is called with one of
the names that exist today, then the behavior of the old tool of
that name ought to be emulated exactly.
Adam Reed (mtgzz!avr)
-----------------------------
From: uhclem at trsvax.uucp
Subject: Re: I'm going to hate myself
Date: 20 Jun 88 14:42:00 GMT
Nf-ID: #R:beta.lanl.gov:20355:trsvax:193500005:000:1619
Nf-From: trsvax.UUCP!uhclem Jun 20 09:42:00 1988
To: unix-wizards at SEM.BRL.MIL
<>
B>1. What ever happened to Digital Systems House?
Dunno.
B>2. If they are gone (likely), who inherited the trademark for
B> MINIX(tm)?
According to a letter I got in the US MAIL on Friday, offering to sell me
MINIX, MINIX(TM) is a registered trademark of Prentice Hall, Inc.
B>3. What happens to a trademark (such as MINIX(tm)) when a company
B> goes away??
Trademarks die hard. When companies are bought out, they usually transfer to
the new owner. If the company goes under, the creditors can sell it just
like any other asset, as long as it is still in force.
FYI, The MINIX software is available for $79.95 for these targets:
A. 640K IBM PC (full binaries and sources) #58387-2
B. 256K [ha!] IBM PC (same as above, except no C compiler is
present [double ha!] #58388-0
C. 512K IBM AT (full binaries and sources) #58386-4
D. 9-track industry standard magnetic tape for class use on a VAX
#58389-8
They are also pushing a book called "Design of the UNIX operating system"
by Maurice J. Bach, for $37.33. And another book "Operating Systems
Design and Implementation" #63740-5 for $39.33.
The business reply address is PRENTICE-HALL, Inc.
Book Distribution Center
Route 59 at Brook Hill Drive
West Nyack, New York, 10995
<I'm not a lawyer, but I sound like one, and I would like to tell you about
some wonderful tree-covered acreage I have available near Odessa Texas....>
"Thank you, Uh Clem."
Frank Durda IV @ <trsvax!uhclem>
...decvax!microsoft!trsvax!uhclem
...convex!infoswx!hal6000!trsvax!uhclem
...sys1!hal6000!trsvax!uhclem
-----------------------------
From: der Mouse <mouse at mcgill-vision.uucp>
Subject: Re: back to the (ivory) tower
Date: 22 Jun 88 14:09:31 GMT
Posted: Wed Jun 22 10:09:31 1988
To: unix-wizards at SEM.BRL.MIL
In article <500 at philmds.UUCP>, leo at philmds.UUCP (Leo de Wit) writes:
> But I have a nice alternative: lets always use alloca() and a new
> function, call it freea(), in pairs.
> For [compilers] that don't [support alloca]:
> #define alloca malloc /* the oldies */
> #define freea free
Then why bother with alloca, if the semantics are such that malloc can
be used instead?
> Everybody happy?
No. The people who use alloca to get automatic freeing on a longjmp
(or other stack unwind) won't be able to tolerate the malloc
replacement.
der Mouse
uucp: mouse at mcgill-vision.uucp
arpa: mouse at larry.mcrcim.mcgill.edu
-----------------------------
From: Andy Tanenbaum <ast at cs.vu.nl>
Subject: Re: I'm going to hate myself
Date: 21 Jun 88 21:43:46 GMT
Keywords: Trademarks
To: unix-wizards at brl-sem.arpa
In article <20347 at beta.lanl.gov> hwe at beta.lanl.gov (Skip Egdorf) writes:
>MINIX is a trademark of Digital Systems House
Interesting, interesting. Here comes one of those stories that only insiders
know. The derivation of UNIX is as follows. Ken Thompson was one of the
programmers on MULTICS, the MULTIplexed Information and Computing Service
projected started by MIT, Bell Labs and GE. After Bell Labs pulled out, Ken
found an unused PDP-7 and tried writing MULTICS on his one. Brian Kernighan
noted that it only supported 1 user, so it should be called Unics (Uni being
the Latin for 1). The spelling got garbled later.
My original name for this system was MONICS (the MONoplexed Information
and Computing Service, Mono being Greek for 1). The spelling later got
garbled to MONIX. All my students knew it under this name. Then Prentice-Hall
did a trademark search and discovered that MONIX was the trademark of some
French company. Bye MONIX. I then suggested MINIX, STUNIX, and various other
names. Then did trademark searches on them and MINIX was not anybody's
trademark, so we picked it.
I can't explain the Digital Systems House alleged trademark except to say they
must not have done a very good job of trademarking it since it didn't show up
in a very specific search for it.
Andy Tanenbaum (ast at cs.vu.nl)
--
Andy Tanenbaum (ast at cs.vu.nl)
-----------------------------
From: WU SHI-KUEI <wu at spot.colorado.edu>
Subject: Re: sh(1) command substitution and here documents
Date: 22 Jun 88 15:06:19 GMT
Sender: news at sigi.colorado.edu
To: unix-wizards at brl-sem.arpa
In article <1254 at cadre.dsl.PITTSBURGH.EDU> jack at cadre.dsl.pittsburgh.edu.UUCP (Jack Nelson) writes:
> . . . an explanation of what he wants to do
>What I would like to do is incorporate this calculation result into a shell
>variable using the here document:
> #!/bin/sh
> var=`bc <<End
> scale=2
> 3 / 4
> End
> `
> . . . error messages, why doen't it work etc.
You don't need or want the here document. The following will do just fine:
#!/bin/sh # not needed with REAL UNIX
var=`bc '
scale = 2
3 / 4
quit'`
The 'quit' is essential since bc keeps reading the standard input after the command have been read.
Carl Brandauer
ihnp4!nbires!bdaemon!carl
303-442-1731
-----------------------------
From: John Sloan <jsloan at wright.edu>
Subject: Re: Spooling to an Encore annex via lpd
Date: 22 Jun 88 11:19:25 GMT
To: unix-wizards at SEM.BRL.MIL
in article <10657 at ames.arc.nasa.gov>, medin at cincsac.arc.nasa.gov (Milo S. Medin) says:
> Don't worry about pscomm. R4.0 has a feature where you can run a
> reverse telnet daemon that creates a file that pscomm can open and read
> and write, etc... The daemon then does a TCP connect to the annex
> port of your choosing. A really nice idea.
>
> Fixed in 4.0!
>
> Milo
R4.0 of what? SunOS? Annex software from Encore? Transcript?
I embarressed to admit that shortly after I made my prior posting about
not being able to spool to a LaserWriter via an Annex serial port, it
occurred to me how in fact it might be done using a pty/tty pair. Dumb
dumb dumb. I'm debugging now. If/when it works as well as I think it
should, I'll ship the filter off to Rich Salz for comp.unix.sources,
unless is obsolesced by something else sooner.
--
John Sloan, The SPOTS Group Wright State University Research Building
CSNET: jsloan at SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420
UUCP: ...!wright!jsloan +1-513-259-1384 +1-513-873-2491
Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
-----------------------------
From: Wayne Mesard <mesard at bbn.com>
Subject: Re: determine the current directory of a son-process (longish)
Date: 22 Jun 88 15:46:05 GMT
Sender: news at bbn.com
Followup-To: comp.unix.wizards
To: unix-wizards at brl-sem.arpa
[ N.B. followups to wizards.]
>From article <579 at gmdzi.UUCP>, by valder at gmdzi.UUCP (Wilhelm Valder):
> Does anyone know how to determine the current working directory (CWD) of
> a son-process in UNIX. Any hints, comments, solutions are appreciated.
>
> The problem: In our current implementation of a command listener, we
> have one process that builds up a command line and sends it to a son
> process (normally /bin/sh or /bin/sh) that has been forked and exec'd
> during startup. The two processes communicate via pseudo ttys (pty's).
Geez, why don't you hack the shell source? Well, none of my business I
suppose.
Anyway, I was in the same situation when I was writing a UNIX [BSD]
tutorial last summer on CMU's Andrew system. I had the tutorial running
in one window, and a shell in another. The tutorial had to listen to what
the user typed and provid helpful information. The communication
worked almost like yours except I had a third program involved.
What I did was this:
o At startup, the tutorial opens a pipe stream to a "voyeur" program
which acts as an intermediary between the shell and the tutorial,
and between the user and the shell. Before making the call,
the tutorial ensures that its stderr goes to the same place as
its stdout (see below) (via dup(2)).
o The voyeur then sets up a pty and forks a shell which it could talk
and listen to via the pty.
------------ ------------ ------------
| | pipe | | pty | |
| Tutorial |<======= | Voyeur | <========> | Shell |
| | (V's | | (Shell's | |
------------ stdout) ------------ stdout,in ------------
^ | & err)
stdin | | stderr
| V
So, in voyeur's main loop:
o It does a select to wait for input from the keyboard (the user) or
from the pty (the shell).
o On shell output, voyeur first sends a copy to its stderr (which is the
screen) so that the user can see it (no flames, please). Remember,
that the shell is only talking to the pty and voyeur's stdout goes
to the tutorial.
Next it sends a copy to the tutorial (via it's stdout) along with
some control messages to advise the tutorial of where the incoming
data came from.
o On stdin (keyboard) input it sends a copy down the stdout to both
the shell and the tutorial.
Now to get to your question:
On keyboard input, it checks to see if the typed string is a request for
change of directory and if it is, voyeur (1) asks the shell for the new
directory name (2) warns the tutorial that important data is on the way
and to wait for it:
if (!strncmp(buf, "cd", 2) || !strncmp(buf, "chdir", 5) ||
!strncmp(buf, "pushdir", 7) || !strncmp(buf, "popdir", 6)) {
(void) write(ptyfd, "echo \007\007$cwd\001\n", 13);
(void) write(1, "\001\001WAIT\n", 7);
}
Meanwhile, there is a check in voyeur's shell output handler to watch
for messages with double Ctrl-G's. It knows that this is the answer to
its question, finds the useful information and sends it as a
control message to the tutorial.
if (sel & (1 << ptyfd)) { /* output from shell */
int n = read (ptyfd, buf, BUFSIZ);
[...]
if ((newdir = index(buf, '\007')) && *(newdir+1) == '\007') {
(void) write(1, "\001\001CWD:",6);
(void) write(1, newdir+2, (int)(index(buf, '\001') - newdir - 2));
(void) write(1, "\n", 1);
(void) write(2, buf, (int)(newdir - buf));
/* If we didn't get the prompt after $cwd, get it next time. */
okay_to_write = n - (int)(index(newdir,'\n')-buf) - 1;
*newdir = '\0';
}
else if (okay_to_write)
(void) write(2, buf, n);
else
okay_to_write = 1;
}
}
I wasn't sure whether or not to include the "okay_to_write" nonsense in
this article, but since I have, I might as well, explain it: The user
should have no idea that we're sneaking that echo command to his/her
shell. So of course we don't echo the output. But we also have to make
sure that the prompt which gets printed after the "echo" command is also
suppressed. Since this stuff comes down the pty asynchronously, it
might get read in one packet ("^G^G/usr/newdir^A\nprompt>") which is no
problem, or in two packets ("^G^G/usr/newdir^A\n", "prompt>") in which
case we have to wait for and suppress the second one.
Now, I realize that this routine can be easily defeated, and lose big in
some cases, but the general algorithm is a sound and efficient way to
preprocess input to and output from a command processor.
--
unsigned *Wayne_Mesard(); MESARD at BBN.COM BBN Labs, Cambridge, MA
Is it because of the people you hang around with that you say you do not
need dan rather?
M-x psychoanalyze-pinhead
(Gee, whataneditor!!)
-----------------------------
From: der Mouse <mouse at mcgill-vision.uucp>
Subject: Re: ksh weird files
Date: 22 Jun 88 17:36:41 GMT
Keywords: ksh shell scripts, not weird
Posted: Wed Jun 22 13:36:41 1988
To: unix-wizards at SEM.BRL.MIL
In article <1289 at ark.cs.vu.nl>, maart at cs.vu.nl (Maarten Litmaath) writes:
> In article <494 at philmds.UUCP> leo at philmds.UUCP (L.J.M. de Wit) writes:
>> When login or getty or whoever goes to exec the sh script, how does
>> it know which command interpreter to use (I don't think it knows of
>> #! lines, in fact it doesn't even know the c.i. issue) ?
> The magic number #! is well-known to the KERNEL!
This is system-dependent. BSD kernels (recent ones, at least) do
indeed handle #! on their own; I understand that SV kernels generally
do not. (I don't know about any others, eg V7/V8/V9, SIII, etc.)
>> And another question: how do you display text with
>> echo << END-OF-TEXT
>> text here
>> END-OF-TEXT
As you probably discovered, you don't: you use cat instead of echo.
Using echo here makes about as much sense as saying
cat textfile | echo
der Mouse
uucp: mouse at mcgill-vision.uucp
arpa: mouse at larry.mcrcim.mcgill.edu
-----------------------------
From: der Mouse <mouse at mcgill-vision.uucp>
Subject: Re: Stdio (stderr) buffering question
Date: 22 Jun 88 17:44:23 GMT
Posted: Wed Jun 22 13:44:23 1988
To: unix-wizards at brl-sem.arpa
In article <5027 at sdcsvax.UCSD.EDU>, hutch at net1.ucsd.edu (Jim Hutchison) writes:
> So how many things break if stderr is line buffered? (Meaning that
> when you get a \n or a full buffer WECF.)
Very little will actually break, but it will make stderr next to
useless for debugging. It would force the poor programmer to follow
ever fprintf(stderr,...) with fflush(stderr) to make up for it - why
uglify everyone's code for no good reason?
The efficiency argument is quite bogus (for stderr). Stderr is used
for two things: printing error messages (efficiency irrelevant,
buffering probably acceptable) and printing debugging messages
(efficiency irrelevant, buffering definitely harmful). There are
exceptions to this general rule (tar cvf - being notable), but they are
few enough that inserting a setbuf or setlinebuf call is no great pain.
der Mouse
uucp: mouse at mcgill-vision.uucp
arpa: mouse at larry.mcrcim.mcgill.edu
-----------------------------
From: Hitoshi Aida <aida at porthos.csl.sri.com>
Subject: Re: sh(1) command substitution and here documents
Date: 22 Jun 88 18:18:58 GMT
Sender: usenet at csl.csl.sri.com
To: unix-wizards at brl-sem.arpa
In article <6774 at sigi.Colorado.EDU> wu at spot.Colorado.EDU (WU SHI-KUEI) writes:
>The following will do just fine:
>
> #!/bin/sh # not needed with REAL UNIX
> var=`bc '
> scale = 2
> 3 / 4
> quit'`
Not quite correct. The following will do just fine:
#!/bin/sh # not needed with REAL UNIX
var=`echo '
scale = 2
3 / 4
quit' | bc`
"quit" can be omitted.
Hitoshi AIDA (aida at csl.sri.com)
Computer Science Lab, SRI International
-----------------------------
From: der Mouse <mouse at mcgill-vision.uucp>
Subject: Re: Tool -flag considered harmful
Date: 22 Jun 88 18:07:31 GMT
Posted: Wed Jun 22 14:07:31 1988
To: unix-wizards at brl-sem.arpa
In article <8090 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
> Hey, while we're at it, have an option to highlight the matched
> pattern(s) in STANDOUT MODE (i.e. add control characters based on
> getenv("TERM") or a -Tname option).
To take this in an entirely different way from what you intended....
I have a program which is like cat except that certain strings
(specified on the command line) get replaced with
underscore-backspace-character sequences. If the standard output is a
tty, it automagically pipes its output through ul to make it come out
in the appropriate standout mode for the terminal.
der Mouse
uucp: mouse at mcgill-vision.uucp
arpa: mouse at larry.mcrcim.mcgill.edu
-----------------------------
From: "Kenneth T. Smelcer" <kts at quintro.uucp>
Subject: Re: How good is Apollo UNIX? (was: O'pain Software Foundation: (2))
Date: 14 Jun 88 06:37:31 GMT
To: unix-wizards at SEM.BRL.MIL
In article <697 at vsi.UUCP> friedl at vsi.UUCP (Stephen J. Friedl) writes:
>Ron Natalie @ Rutgers notes:
>> The Apollo systems I've been forced to use do such a poor imitation
>> of UNIX that I have no wonder that you have problems with SVVS.
>
>A friend of mine who uses Apollo says the same thing as well.
>
>
>In Apollo's defense, Nathanial Mishkin (mishkin at apollo.uucp) says:
>> In at least some ways, SVVS as it is currently constituted
>> thus stifles innovation. I think stifling innovation is something
>> none of us want.
>
>Isn't it *wonderful* how people can make sunshine out of sh*t? :-)
>
This isn't the place for a "How good is Apollo Unix" war, but I just
had to put my $0.02 in defense of Domain/IX.
Despite their reputation, Apollo has been doing a fairly good job
in the past few years of integrating Unix into their environment.
The older Apollo releases (pre-9.0) had real problems, but the current
release (9.7) is quite Unix compatible (for both SysVR2 and BSD 4.2).
I have very few problems with programs from comp.sources.* (most run
without any modifications), and I think they've done a decent job
integrating SysV, BSD, and Aegis into a usable, coherent package.
I don't know about IBM and DEC, but Apollo has definitely demonstrated
their commitment to Unix, and to the unification of the various flavors
of Unix into a common platform.
As far as the SVVS is concerned, I'd be interested in hearing any details
about the problems Domain/OS (also known as SR10) had passing the
verification suite.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ken Smelcer Quintron Corporation - Quincy, Il.
UUCP: att-ih!spl1!quintro!kts
or {att-ih,uunet}!wucs1!wuibc!quintro!kts
-----------------------------
From: "Milo S. Medin" <medin at cincsac.arc.nasa.gov>
Subject: Re: Spooling to an Encore annex via lpd
Date: 22 Jun 88 23:47:03 GMT
Sender: usenet at ames.arc.nasa.gov
To: unix-wizards at SEM.BRL.MIL
R4.0 of the Annex software. It's in beta test now, and hopefully
will be out soon. You get the source for a program called rtelnet
on the tape. Works great. Kudo's to Encore for 'doing the right
thing'. I only wish all our vendors did...
Thanks,
Milo
-----------------------------
From: Evan Wallace <wallace at cme-durer.arpa>
Subject: implementing pseudo-asynchronous io on SYS5
Date: 22 Jun 88 16:09:40 GMT
Keywords: OSI
To: unix-wizards at brl-sem.arpa
We think it desirable to build a standard interface to OSI services
for our applications. The operating systems these applications
will operating on are Sun OS V3.X, SYS5 (Microport 386) and VMS.
The applications in question are actually high level services which
include communication and thus the peice of the applications doing
communications will be required to manage multiple transports
(channels).
While I can see how this could be supported in an inelegant way
with sockets and select(2) call on the Sun (which could be
simulated on the VAX, I can't find any way to support a
multi-channeled asynchronous service on SYS5. I would appreciate
info on how others have (would or will) solved this problem on SYS5.
Thanks,
Evan Wallace
Arpanet address: wallace at durer.cme.nbs.gov
-----------------------------
From: "William E. Davidsen Jr" <davidsen at steinmetz.ge.com>
Subject: Re: sh(1) command substitution and here documents
Date: 22 Jun 88 17:27:23 GMT
To: unix-wizards at brl-sem.arpa
In article <1254 at cadre.dsl.PITTSBURGH.EDU> jack at cadre.dsl.pittsburgh.edu.UUCP (Jack Nelson) writes:
| What I would like to do is incorporate this calculation result into a shell
| variable using the here document:
| #!/bin/sh
| var=`bc <<End
| scale=2
| 3 / 4
| End
| `
| But this doesn't work; an error message "cannot open /tmp/sh01383"
| always is produced, both on 4.3 and 2.10 systems. Is there a way
| to do this? Can one deduce this behavior from the manual?
This was fixed after V7. It works in SysIII sh, SysV sh, ksh, and sh
on Sun (which is mostly sysV I believe). It fails on V7 and every BSD
version I could try. Since Berkeley hasn't fixed it (and some similar
problems) perhaps you can get ksh.
--
bill davidsen (wedu at ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
-----------------------------
From: Larry Williamson <larry at focsys.uucp>
Subject: Re: Curses & Color
Date: 20 Jun 88 13:51:24 GMT
To: unix-wizards at SEM.BRL.MIL
In article <43200020 at uicsrd.csrd.uiuc.edu> davej at uicsrd.csrd.uiuc.edu writes:
>
> I need to do colors with curses. ...
I was looking for this same feature about a month ago. It turns out
that system V Release 3 is supposed to support colour. I don't know
first hand if this is true as I don't have a copy of Release 3 yet.
larry
--
Larry Williamson Focus Automation Systems
UUCP: watmath!focsys!larry 608 Weber St. N, Waterloo, Ontario N2V 1K4
+1 519 746 4918
-----------------------------
From: Mike Adams <mdadams at surya.waterloo.edu>
Subject: Re: UNIX-WIZARDS Digest
Date: 21 Jun 88 11:00:35 GMT
Sender: daemon at watale.waterloo.edu
To: unix-wizards at brl-sem.arpa
In article <16229 at brl-adm.ARPA> I wrote:
>Would you please add the following address to the UNIX-WIZARDS Digest
>subscription list:
> unix-wizards at surya.uwaterloo.ca
Please don't.
Sorry for the confusion.
Mike
-----------------------------
From: Nick Crossley <nick at ccicpg.uucp>
Subject: cmp efficiency
Date: 23 Jun 88 01:08:21 GMT
To: unix-wizards at brl-sem.arpa
> While we're on the subject of efficiency, cmp is coded wrong. It should
> first stat the two files to be compared. If the character count is different,
> so are the files. And files tend to be different more often than the same.
First, files given to cmp are quite likely to be the same, in my experience.
Second, if the files are not the same size, cmp will tell you if they have the
same contents up to the length of the shorter (cmp will say 'EOF on file 1/2').
I find this useful in some contexts, and would not want cmp just to give up
if the sizes differed.
--
<<< standard disclaimers >>>
Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA
Tel. (714) 458-7282, uucp: ...!uunet!ccicpg!nick
-----------------------------
From: Dave Jones <djones at megatest.uucp>
Subject: Re: Stdio (stderr) buffering question
Date: 23 Jun 88 03:38:48 GMT
To: unix-wizards at SEM.BRL.MIL
I'll play Devil's advocate for a bit, while I'm waiting for a phone
call.
>From article <1178 at mcgill-vision.UUCP), by mouse at mcgill-vision.UUCP (der Mouse):
In article <5027 at sdcsvax.UCSD.EDU), hutch at net1.ucsd.edu (Jim Hutchison) writes:
>> So how many things break if stderr is line buffered? (Meaning that
>>when you get a \n or a full buffer WECF.)
> Very little will actually break, but it will make stderr next to
> useless for debugging. It would force the poor programmer to follow
> ever fprintf(stderr,...) with fflush(stderr) to make up for it - why
> uglify everyone's code for no good reason?
Just end the fprintf's with \n. That's what I do. (We have Sun3, which
has line-buffered stderr.) Not too ughly.
> The efficiency argument is quite bogus (for stderr). Stderr is used
> for two things: printing error messages (efficiency irrelevant,
> buffering probably acceptable) and printing debugging messages
> (efficiency irrelevant, buffering definitely harmful).
I once worked with a computer (now defunct) which had one master cpu
and several slave cpu's -- the slaves were device controllers.
stderr was character-buffered, and each character required locking
the system bus, an interrupt to the master cpu, and a system call on
the master. When things were going badly, these one-character interruptions
could bring the system to its knees.
Admittedly an unusual case.
> There are
> exceptions to this general rule (tar cvf - being notable), but they are
> few enough that inserting a setbuf or setlinebuf call is no great pain.
>
No pain if you have the source code handy, and permission to change
/bin, and willingness to do it on every new release.
later,
Dave J.
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list