Returned network mail
Postmaster
POSTMASTER%DICKINSN.BITNET at cornellc.cit.cornell.edu
Mon Oct 23 02:20:22 AEST 1989
This message was automatically generated.
Your mail message could not be delivered at Dickinson College in Carlisle,
Pennsylvania because the user address was not known at our site.
Addresses at Dickinson College are of the following format:
username at DICKINSN e.g., POSTMASTER at DICKINSN
or ALLAN_J at DICKINSN
or WOLTER at DICKINSN
Usernames are typically the first 8 letters of the person's last name,
frequently with the first initial added, and occasionally with an
underscore. As a result, it would be difficult to guess someone's username.
If you do not know the address of someone at Dickinson, please send a
message to POSTMASTER at DICKINSN asking for help.
----------------------------------------------------------------------
The following diagnostic is the reason for the return:
%BNET-W-NOSUCHRCVR, receiver LEYON_C cannot be located
Returned mail follows:
----------------------
Received: From PSUVM(MAILER) by DICKINSN with Jnet id 5076
for LEYON_C at DICKINSN; Sun, 22 Oct 89 11:07 EDT
Received: by PSUVM (Mailer R2.03B) id 4463; Sun, 22 Oct 89 11:06:40 EDT
Date: Sun, 22 Oct 89 02:45:26 EST
Reply-To: UNIX-WIZARDS at BRL.MIL
Sender: Unix-Wizards Mailing List <UNIX-WIZ at NDSUVM1>
From: Mike Muuss The Moderator <Unix-Wizards-Request at BRL.MIL>
Subject: UNIX-WIZARDS Digest V8#099
X-To: UNIX-WIZARDS at BRL.MIL
To: Chris Leyon <LEYON_C at DICKINSN.BITNET>
UNIX-WIZARDS Digest Sun, 22 Oct 1989 V8#099
Today's Topics:
Re: How do you tell a wizard?
Re: UNIX history made easy
The Great Vi Controversy
Re: ksh dumping core
modem programs for Unix
Re: Help! Altos 5.3.1 fork is failing!
Xenix driver for Univision 1024 video board
Re: BSD file system
Re: Real Time UNIX (was: Re: How do you tell a wizard?)
"evils of alloca" discussion
Re: How to write a new Unix-like kernel
Re: How do you tell a wizard?
Re: BSD file system
Re: What SHOULD go in the kernel
Bug/problem in ksh88b and/or SUN OS
ksh88 problem with substring expansion using "+( )" pattern
Re: Bug/problem in ksh88b and/or SUN OS
-----------------------------------------------------------------
From: Richard O'Keefe <ok at cs.mu.oz.au>
Subject: Re: How do you tell a wizard?
Date: 21 Oct 89 05:33:42 GMT
Sender: news at cs.mu.oz.au
To: unix-wizards at sem.brl.mil
In article <89Oct20.205428edt.19392 at me.utoronto.ca>, ip at me.utoronto.ca (Bevis
Ip) writes:
> In article <917 at uakari.primate.wisc.edu> bin at primate.wisc.edu writes:
> >I have *never* heard *anyone* call "vi" vee-eye. Including wizards.
> Even our chinese scholar who onlys know a few essential Unix commands to
> survive and quits "vi" by typing control-Z learned to call "vi" vee-eye!
There are two separate questions: "what does the manual say the program
is to be called" and "what might a wizard actually call it". Someone
who has read and understood the vi manual might know perfectly well what
the authors wanted it to be called, but use something less printable.
Just like people pronounce MS-DOS "mess-doss" or "em ess doesn't".
Too bad the C book didn't say how to pronounce "char" or I could tell
the people who pronounce it "care" that they aren't Real Wizards (TM)
even if they _can_ write code that works.
-----------------------------
From: Malaclypse the Elder <dwc at cbnewsh.att.com>
Subject: Re: UNIX history made easy
Date: 20 Oct 89 17:03:04 GMT
To: unix-wizards at sem.brl.mil
In article <10027 at alice.UUCP>, andrew at alice.UUCP (Andrew Hume) writes:
>
>
> this strand about ken is silly enough without me adding to it
> but ken is famous for more than unix. he did some important
> work early on (1960's) with regular expressions, establishing
> a formal method to transform finite-state machines into
> equivalent non-deterministic finite automata. this is related
> to the patent he holds for implementing regular expression recognisers.
its been about ten years since i took my finite state automata class
so i'm not clear about the difference between finite state machines
and finite automata, but are you referring to the method of transforming
a non-deterministic finite state automaton into a deterministic one?
it involves creating new states that are the cross products of the
states of the non-deterministic machine.
if so, i did not know that ken thompson was the "inventor" of this
method. i school, it was presented as a proof that the two are
equivalent in power.
which i guess brings me to my point. it is quite *centric (fill
in the * with anything that matches an appropriate personality) of
the people arguing about what constitutes a scientist. it is silly
to say that one is only a scientist if one knows what i know. but
there are a couple of things that are "useful" to know (in my *centric view):
scientific method and in a related way, where/how to find things out.
this is my opinion.
danny
att!hocus!dwc
-----------------------------
From: Brain in Neutral <bin at primate.wisc.edu>
Subject: The Great Vi Controversy
Date: 21 Oct 89 15:13:17 GMT
To: unix-wizards at sem.brl.mil
Ok, ok, ok, you can stop the flood of mail now.
Little did I realize what I hornet's nest I would stir up.
Anyway, my mail indicates that vee-eye is indeed the more prevalent
pronounciation, over vye (as in "curl up and die for pronouncing vi that
way" :-). There appears to be some evidence that there are regional
preferences, though of course the notorious mobility of computer professionals
would tend to mitigate that a bit.
A number of people pointed out that the vi manual says vee-eye is correct.
Actually, I've known that for over a decade, and have known it since shortly
after I heard of vi, having dug out the manual and read it cover-to-cover.
Since everyone I knew said vye (this included instructors, computer lab
personnel, etc.), I guess I imprinted to that pronounciation.
A few made scurrilous and brazen attacks, impugning the intelligence
and/or wizard-ness of those wizards I know who pronounce vi as vye.
I suppose this makes them feel big. Whoopie.
Paul DuBois
dubois at primate.wisc.edu
-----------------------------
From: Amos Shapir <amos at taux01.uucp>
Subject: Re: ksh dumping core
Date: 21 Oct 89 13:32:18 GMT
Hdate: 22 Tishrey 5750
To: unix-wizards at sem.brl.mil
It seems all your sessions use the same history file; one of them adds
to it, making the other's current pointer into it invalid.
It is easy to fix: just define HISTFILE=.hist$HOST$TTY in your .profile
(make sure $TTY and $HOST are defined first, of course). I do not use
it since it's sometime useful to keep history around from other sessions;
just pressing RETURN every now and then makes sure a session re-reads
the history file, so it does not stay behind too much.
--
Amos Shapir amos at taux01.nsc.com or amos at nsc.nsc.com
National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel
Tel. +972 52 522261 TWX: 33691, fax: +972-52-558322
34 48 E / 32 10 N (My other cpu is a NS32532)
-----------------------------
From: Jim Burwell <jimb at faatcrl.uucp>
Subject: modem programs for Unix
Date: 21 Oct 89 02:47:12 GMT
Followup-To: comp.unix.questions
Keywords: terminal modem sun sunos bsd telebit cds xmodem ymodem zmodem
To: unix-wizards at sem.brl.mil
Hi there..
Does anyone know of any terminal programs, besides "tip" or "cu" for
Unix systems ?
We have a Sun 3/160 and a Sparc with a Telebit T2500, and a CDS 224 hooked
to the serial ports.. I've looked everywhere, but I can't seem to find
ANY terminal programs for Unix that work with our system. Tip and cu just
don't cut it, since they don't have any file transfer protocols, etc. Are
there any modem programs for Unix systems which even come close to those
available for PCs ?
I did manage to find a program called "pcomm", a terminal which has the
"look and feel" of procomm. Alas, it was for System V, and even though I
got it to compile and run on the Sun, with the Sys V compatible compiler and
libraries, all it would do is dial the modem, and send stuff out. I could
see data coming in, but it wouldn't appear on my screen...
Any help would be appreciated!
Bye
Jim
--
+------------------------------------------------+--------------------------+
| James S. Burwell | |
| | "UseNet...A text network |
| UUCP: | in a binary world" - Me |
| ...!{ames!netsys|rutgers}!faatcrl | |
| !jimb | "How do you say |
| . | 'multitasking' in |
| Internet: . | MS-DOSish? Network |
| // jimb at faatcrl.UUCP . ** | File Server!" - Me |
| // . **** | |
| \\ // GEnie: Airwarior: . .** | <reserved for future> |
| \X/ JIMBURWELL Techrat . | <expansion.... > |
+------------------------------------------------+--------------------------+
-----------------------------
From: Malaclypse the Elder <dwc at cbnewsh.att.com>
Subject: Re: Help! Altos 5.3.1 fork is failing!
Date: 21 Oct 89 06:57:22 GMT
To: unix-wizards at sem.brl.mil
i originally sent a reply to the poster of the question stating
that the reason that getcpages is failing trying to get 1 contiguous
page is that there is probably no free memory for a page table.
its been a while since i looked at the problem but i seem to
remember that the reason getcpages() can fail without sleeping
is to prevent deadlock-type situations. on release 3, there are
certain process data structures that are not swapped out: the ublock
(depending on the version), the page tables and DBDs, and maybe more.
well, you can get into a situation of deadlock in which all memory
is committed to these data structures and no process can continue
because it they are all both holding memory and waiting for more.
allowing the sleep to happen is okay if you make the sleep interruptable.
then at least the user can attempt to abort his program voluntarily
(the problem is determining when you are in this deadlock situation...
you can't run user level programs to tell you this).
my solution to this was really very simple. at fork time, the parent
knows how much memory resources it will take to create this process
(ublock, page tables, dbds, etc.). with this information, the parent
can check freemem level and reserve the necessary amount of memory to
satisfy the fork and sleep until that amount of memory is available.
this sleep is safe since no resources have been committed to the child
yet (the child doesn't even exist). we prototyped this for release 3
and it was going to go into some future release when they decided to
use sun's VM architecture instead of regions. i suspect that release 4
will have a similar problem but i'm not sure.
if you don't have source to modify, i suggested to the original requestor
that he set a very high value for GETPGSLO and GETPGSHI. this will make
the paging daemon very active and MAY prevent you from hitting situations
where freemem goes to zero. its not guaranteed since requests for
freemem is VERY bursty and the reaction time of vhand is fairly slow.
danny chen
att!hocus!dwc
-----------------------------
From: "David L. Markowitz" <dav at genisco.uucp>
Subject: Xenix driver for Univision 1024 video board
Date: 21 Oct 89 00:01:47 GMT
Keywords: driver univision xenix 386
To: unix-wizards at sem.brl.mil
I am in the process of writing a driver for a Univision 1024 frame buffer,
and I have a few questions.
First the details. I have ten years of Unix experience, and have written
many drivers, but I've never worked with Xenix or DOS much. My background
is Vax/68000/Sparc and VME based, not Intel and AT bus based. The hardware:
Standard stuff:
SCO Xenix 2.3.2
Micronix 20MHz 386 + Cache
2 MB RAM
80 MB Hard Disk
Monochrome Video Board
I am adding:
Univision 1024x1024 frame buffer with VSB bus
Tecon DVX1024 Frame Grabber with VSB bus
I already have the Tecon mostly working (it won't interrupt, though).
I need to map in 64K chunks of the video memory on the AT bus.
The board includes registers to set up which piece of video RAM
is mapped to the bus, but I don't know how to interpret Intel-style
addresses like C400:0200 within a driver.
I do not need to use this as my console device, nor does it need
to interface to the standard video boards data structures (although
that would be nice). I really just want to use it as an alternate
stand-alone display, while also having the monochrome display hooked up.
Now, the questions:
1) Has anyone already written this? How about other memory mapped video
board drivers? Are there any floating around in source form that
people wouldn't mind letting me look at?
2) How do I access the bus at such an address from Xenix?
3) Is there a good manual/book somewhere on how Xenix deals with the
fractured concepts of the AT bus. (Or, "Gee - a real computer! Too
bad it can't talk to the rest of the world very well...") (When
Sun designed their 386i machines, they had to figure out how to
co-exist with the AT bus. Their solution? "We don't use it!")
4) Am I crazy?
Please reply by mail - I will summarize if there is enough interest.
David L. Markowitz
Genisco Technology Corporation
dav at genisco
--
David L. Markowitz
Genisco Technology Corporation
dav at genisco
-----------------------------
From: Robert Krawitz <rlk at think.com>
Subject: Re: BSD file system
Date: 21 Oct 89 18:29:19 GMT
Sender: news at think.com
To: unix-wizards at sem.brl.mil
In article <31003 at news.Think.COM>, dm at odin (Dave Mankins) writes:
]Symbolic links are just like hard links only with the ability to span
]filesystems (and, sadly, without the ability to know that, when you remove
]one name for a file (the target of the symbolic link) there is another name
]left dangling without a reference).
I find it more convenient to think of a symlink as nothing more than a
pointer to a named point in the filesystem. A hard link (remember, each
file is really a link) is a pointer to an inode (a filesystem object),
whereas a symlink is a pointer to a name.
--
ames >>>>>>>>> | Robert Krawitz <rlk at think.com> 245 First St.
bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142
harvard >>>>>> . Thinking Machines Corp. (617)876-1111
-----------------------------
From: RAMontante <bobmon at iuvax.cs.indiana.edu>
Subject: Re: Real Time UNIX (was: Re: How do you tell a wizard?)
Date: 21 Oct 89 19:35:23 GMT
To: unix-wizards at sem.brl.mil
der at cbnewsl.ATT.COM (david.e.rorke) <2396 at cbnewsl.ATT.COM> :
-
-Real time scheduling is available (or will be in a couple weeks)
I LOVE it!
-----------------------------
From: George Hartzell <hartzell at boulder.colorado.edu>
Subject: "evils of alloca" discussion
Date: 21 Oct 89 19:48:04 GMT
Sender: news at boulder.colorado.edu
Keywords: alloca
To: unix-wizards at sem.brl.mil
A few months back there was a long discussion of the
benefits/drawbacks of using alloca. I read it with interest, but
didn't save it and now that I really want to know more I find that I
didn't save it. Did anyone keep an archive of that discussion? Can
you point me to it/share it with me.
I am specifically interested about alloca on MIPS cpus.
g.
George Hartzell (303) 492-4535
MCD Biology, University of Colorado-Boulder, Boulder, CO 80309
hartzell at Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell
-----------------------------
From: "John F. Haugh II" <jfh at rpp386.cactus.org>
Subject: Re: How to write a new Unix-like kernel
Date: 21 Oct 89 18:27:31 GMT
To: unix-wizards at sem.brl.mil
In article <2046 at prune.bbn.com> rsalz at bbn.com (Rich Salz) writes:
>In <17166 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F. Haugh II) writes:
>> ... discouraging paging
>> the kernel is kinda wasteful the way kernels keep bloating.
>
>Take this sentence backwards, and it becomes a feature: since the kernel
>can't page, you can't puff lots of stuff into it. This has forced a
>certain economy of design (phrase lifted from one of the Unix papers, read
>them all and find out which one -- it'll be good for you) that has
>resulted in the initial success of Unix lo these many years ago.
Don't shoot the messenger! I haven't encouraged kernel bloat, I'm just
reporting the facts. I've frequently professed my admiration for the
7th Edition kernel in this newsgroup. And I have read the UNIX papers,
including the one which says that UNIX really isn't an operating system.
>I don't think this bloat is necessary, and as Dick Dunn has implied in
><1989Oct19.220105.10185 at ico.isc.com>, if you make it possible to have the
>kernel page, then all you do is make it possible to have every
>semi-competent bozo put everything they want in the kernel. Goodbye
>tasteful and understandable set of features, hello [VM][MV]S.
I agree. However, if we are going to be adding features to a minimal
kernel [ such as networking, graphics, security ] we are either going to
have to cleverly redefine what exactly is =the= kernel or find more
efficient methods of managing the memory we are consuming.
In my mind it is the customer who is driving this software obesity.
You can either argue that Sun is successful because the customers
like the software features and buy more Sun's, or you can argue the
Sun programmers keep adding features because the sales staff keeps
doing a better job of fooling Sun's customers. I'd love to see an
analysis of SunOS size versus Sun annual sales. If you care to point
out that every company is growing their OS, I might point out that the
ones that didn't stay on the leading edge of creeping featurism are
now, in the main, out of business.
Besides, who says VMS or MVS or VM/SP are not useful operating systems?
If the question is "How do I put 2000 users on one machine?", my answer
is probably going to be MVS. The question may be kinda stupid and
anyone who really wants a DASD farm deserves MVS, but it is a solution.
>On the other hand, if you let the kernel page, then you can take all the
>stuff that doesn't page and call that the "real" kernel. As long as it's
>paging the other parts, put them in user space, and give users the
>opportunity to put their own code in for their programs.
Here I disagree. Almost everything in a kernel is pagable. If you
remove everything that can be paged or replaced you get CP. Taking
a module out of the kernel and cleverly calling it the "real" kernel will
only populate the memory with "user" processes which are now paging.
The user -should- be able to select which file system they want bound
into their kernel. If you want big and fat, the Berkeley Fast File
System is available. If you want small and stupid, RT-11 comes to
mind ;-)
Create a standard interface model and code two or three file systems
to fit that model. Then do the same with network interfaces, graphics
interfaces, etc. I really should be able to have X in the kernel or
not. I may need 16MB just to boot, but I should be able to do it.
>I don't expect someone whose .signature says that Mach stands for
>messages are crufty hacks will like this design very much, but I'd
>rather avoid bloat, myself. (Do I have to say that this is intended
>to be a mild tweak and not one of the famous "Usenet ad hom.
>attacks"?)
Probably ;-) Do you like the new .signature better?
I feel strongly against message passing schemes for the same reason
I'm not totally sold on lightweight kernel processes. jsr's are cheaper
than messages or context switches. You haven't guaranteed my MACH
processes aren't going to be paged out, so you've gained nothing more
than this warm fuzzy feeling that MACH's 55KLOC kernel is more
understandable than SunOS 4.0 or AT&T's latest overweight offering.
In fact, I'll even argue MACH is dangerous because it now gives
everyone an entirely new level to populate with crap. I feel very
confident in stating that MACH will be big and crufty in even less
time than it took UNIX. Everyone is so much better at adding cruft.
--
John F. Haugh II +-Things you didn't want to know:------
VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of EMACS is ...
InterNet: jfh at rpp386.cactus.org | ... EMACS makes a computer slow.
UUCPNet: {texbell|bigtex}!rpp386!jfh +--<><--<><--<><--<><--<><--<><--<><---
-----------------------------
From: "Mark J. DeFilippis" <mark at promark.uucp>
Subject: Re: How do you tell a wizard?
Date: 21 Oct 89 01:11:12 GMT
To: unix-wizards at sem.brl.mil
I have worked with one flavor of Unix or another for several years, and
to this day will not call myself a wizard. I have long felt it was a form
of rationalization. Wizard implies "knows all", and Unix is ever growing
with each release of the operating system. BSD flavors that meet SVID.
System V with BSD extentions, different with every vendor.
However, I have found the following holds true for
most *very knowledegable Unix people* :
1 They have seen and/or modified Unix source at the kernel and
provided utilities level.
2 They have implimented, at least once, a device driver, or some
other kernel linkable code, and know how much fun it is to
debug this code.
3 They all have at least one beat up copy of the C bible, possibly
hard cover, or if not, the front or back cover is gone.
4 They have a copy of either the BSD or System V "Implimentation of
the Unix operating system."
5 All the above books have pages that are starting to bio-degrade
from age.
6 They have a copy of the SVID from AT&T if they work with SYSTEM V.
7 They all spell kernel as KERNEL, not KERNAL.
8 They don't call themselves wizards, but the people around them
usually do.
Each one of these alone does not constitute a wizard, especially 2, and 3.
But In the case of 2, it has been my experience that if they have been there
a few times, they know their way around pretty well.
--
Adelphi University, Garden City, NY 11530 (516) 663-1170
Department of Mathematics and Computer Science
markd at adelphi.UUCP or mark at promark.UUCP
UUCP: uunet!mimsy!rutgers!columbia!adelphi!markd
-----------------------------
From: Alan Watson <waw103 at tijc02.uucp>
Subject: Re: How do you tell a wizard?
Date: 20 Oct 89 12:37:12 GMT
Posted: Fri Oct 20 08:37:12 1989
To: unix-wizards at sem.brl.mil
>From article <917 at uakari.primate.wisc.edu>, by bin at primate.wisc.edu (Brain in
Neutral):
> From article <955 at umb.umb.edu>, by campbell at umb.umb.edu (Jim Campbell):
>> ie: NOVICE: Calls vi vye
> I have *never* heard *anyone* call "vi" vee-eye. Including wizards.
I have *never* heard *anyone* call "vi" vye. Including novices.
waw at rti!tijc02
-----------------------------
From: Guy Harris <guy at auspex.auspex.com>
Subject: Re: BSD file system
Date: 21 Oct 89 20:49:29 GMT
To: unix-wizards at sem.brl.mil
> Another way of looking at the multi-group capability is that
> a process has a main/primary group - the one listed in the
> password file and multiple secondary groups as determined by
> the group file. It makes sense to me to use the primary
> group for purposes of file ownership.
The problem is that it may not be a *valid* way of looking at the
multi-group capability, in that it doesn't fit reality; there may not be
some group that can reasonably act as a user's "primary group". A user
might work on several things during a session, and not want to use
"newgrp" whenever they change what they're working on to make some
different group be their "primary group".
> Directories such as /tmp typically are owned by groups of which
> users are not members, this has led to surprises at least once
> for me.
In SunOS 4.x and S5R4, the set-GID bit on a directory specifies whether
files created in that directory inherit the group from the parent
directory or get it from whatever of a user's groups happens, by chance,
to be the group in their password file entry. On such a system, you
could turn the set-GID bit off on "/tmp", or get the system
administrator to do it....
-----------------------------
From: Guy Harris <guy at auspex.auspex.com>
Subject: Re: What SHOULD go in the kernel
Date: 21 Oct 89 20:51:59 GMT
Keywords: device drivers
To: unix-wizards at sem.brl.mil
>> One could argue that device drivers don't belong in the kernel
>> at all.
>
>As device drivers continue to bloat in number and size,
>and as hardware becomes more sophisticated,
>this argument gains strength.
Yes, but...
>The NeXT Mach 1.0 operating system supports loadable device drivers.
>The MIDI interface, and other things like a SLIP (RS-232 TCP/IP) driver,
>are done that way. The driver is dynamically linked to the kernel,
>at which point it functions like an ordinary driver.
...down to being a part of the kernel.
Sorry, just making drivers loadable into and, possibly, unloadable from
the kernel doesn't keep them from being in the kernel - it just makes it
easier to control which ones you are in your particular kernel.
-----------------------------
From: Marnix van Ammers <mavanamm at pttesac.uucp>
Subject: Bug/problem in ksh88b and/or SUN OS
Date: 17 Oct 89 23:08:41 GMT
Followup-To: comp.unix.wizards
Keywords: KSH 88B SUN BUG
To: unix-wizards at sem.brl.mil
My ksh88b was dumping core on my SUN 3/50. It would happen
whenever the first command I executed was a particular function in
my $FPATH. I traced it down to the first echo command in my function.
When I recompiled ksh88b with ECHOPRINT set to 1 in the OPTIONS file,
the core dumps stopped.
I found out that when the core dump happened, the call to
path_absolute() at line 1084 of sh/name.c returned a NULL pointer
and that NULL pointer was then passed to strcmp() at line 1086.
The strcmp() function in SUN OS 4.0.3 apparently cannot take a NULL
argument (maybe this is really something SUN ought to fix?).
I could not figure out why path_absolute was returning a NULL
pointer. When I used the dbxtool debugger I'd end up getting
a "Trace/BPT trap(coredump)" before getting to where my normal core
dump was occurring. I don't know what a "Trace/BPT trap(coredump)"
(BPT == Break Point Trap ??) is but it seems to be a feature or
problem with the debugger (I'm new at this dbx stuff, so forgive me).
I was able to at least fix the problem by not passing a NULL pointer
to strcmp().
Here are the diffs to my fix (to sh/name.c):
1085a1086,1104
>
> /* Core dumping fix
>
> By: Marnix A. van Ammers
> Oct 12, 1989
> {att|pacbell}!pttesac!mavanamm
>
> Following fix added to avoid core dump by eq() when cp is NULL.
> (Happens when path_absolute() in echo_mode() returns NULL.)
> That situation happened when the first command to use echo was in my
> function gp() and OPTIONS had ECHOPRINT=0 and there is a
> /bin/echo as in the case of my Sun 3/50 running SUNOS 4.0.3 */
>
> if(cp == NULL)
> echo_arg = (char *) e_minus;
> else
>
> /* end of core dumping fix. */
>
For your information, here's my autoload function gp (I've since
changed this function, but this is the version that caused
ksh88b to dump core in my SUN):
#################################################################
function getpaths {
if [ "$1" = -x ];then
set -x;shift
fi
# getpaths($PATH) -- Return list of paths in $1
typeset PATH="$1"
typeset This_Path Front_Part Paths
while [ -n "${PATH}" ];do # While there's something in $PATH
Front_Part="${PATH%%:*}" # Remove 1st ':' and all to the right of it
if [ -z "$Front_Part" ];then # Front part was null -- special case
This_Path="."
Front_Part=":"
else
This_Path="$Front_Part"
fi
Paths="$Paths $This_Path"
PATH="${PATH#${Front_Part}}"
if [ "${PATH}" != ":" ];then # If this isn't the last (trailing) ':'
PATH="${PATH#:}" # then remove the leading ':'
fi
done
echo "$Paths"
}
# gp = getpath . Finds a *command* and does an ls -l on it
# For instance "gp sh" should find sh, rsh, ksh, rksh
function gp {
if [ "$1" = -x ];then
set -x;shift
fi
typeset F Files PATHS P
print "Searching for executables \"*$1*\" in \$PATH" >&2
PATHS=`getpaths "$PATH"`
for P in $PATHS;do
for F in $P/*$1*;do
if [ -f "$F" -a -x "$F" ];then
Files="$Files $F"
fi
done
done
if [ -n "$Files" ];then
ls -ld $Files
fi
}
#################################################################
I don't seem to have the real problem in hand, but I did just want
to report this to the net in case anyone has an idea what's really
going on.
--
Marnix
-----------------------------
From: Marnix van Ammers <mavanamm at pttesac.uucp>
Subject: ksh88 problem with substring expansion using "+( )" pattern
Date: 17 Oct 89 23:39:08 GMT
Followup-To: comp.unix.wizards
Keywords: KSH88 SUBSTRING PATTERN
To: unix-wizards at sem.brl.mil
I can't believe that the following ksh substring expansion should take
*22* seconds on my sun 3/50 (34 seconds on our 3B20A). All the work
is done internal to ksh. I'm using ksh88b (the "+( )" pattern
requires ksh88).
x=$(set -o) # Set x to current option settings
xx="${x##*nolog+( )on}" # same as `echo "$x"|sed "s/.*nolog *on//"`
As long as the above takes, I could do about 40+ forks and execs
of sed. I've found better ways of doing what I wanted to do without
any system calls, but I still can't believe 22 seconds.
Anybody know what's going on?
--
Marnix
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: Bug/problem in ksh88b and/or SUN OS
Date: 22 Oct 89 04:22:30 GMT
Keywords: KSH 88B SUN BUG
To: unix-wizards at sem.brl.mil
In article <1425 at pttesac.UUCP> mavanamm at pttesac.UUCP (Marnix van Ammers) writes:
>The strcmp() function in SUN OS 4.0.3 apparently cannot take a NULL
>argument (maybe this is really something SUN ought to fix?).
Fix it how? The problem lies in the application, not the C library.
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list