Path: utzoo!attcan!uunet!cs.utexas.edu!mailrus!ames!haven!adm!xadmx!POSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu From: POSTMASTER%DICKINSN.BITNET@cornellc.cit.cornell.edu (Postmaster) Newsgroups: comp.unix.wizards Subject: Returned network mail Message-ID: <21244@adm.BRL.MIL> Date: 22 Oct 89 16:20:22 GMT Sender: news@adm.BRL.MIL Lines: 766 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@DICKINSN e.g., POSTMASTER@DICKINSN or ALLAN_J@DICKINSN or WOLTER@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@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@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@BRL.MIL Sender: Unix-Wizards Mailing List From: Mike Muuss The Moderator Subject: UNIX-WIZARDS Digest V8#099 X-To: UNIX-WIZARDS@BRL.MIL To: Chris Leyon 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 Subject: Re: How do you tell a wizard? Date: 21 Oct 89 05:33:42 GMT Sender: news@cs.mu.oz.au To: unix-wizards@sem.brl.mil In article <89Oct20.205428edt.19392@me.utoronto.ca>, ip@me.utoronto.ca (Bevis Ip) writes: > In article <917@uakari.primate.wisc.edu> bin@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 Subject: Re: UNIX history made easy Date: 20 Oct 89 17:03:04 GMT To: unix-wizards@sem.brl.mil In article <10027@alice.UUCP>, andrew@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 Subject: The Great Vi Controversy Date: 21 Oct 89 15:13:17 GMT To: unix-wizards@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@primate.wisc.edu ----------------------------- From: Amos Shapir Subject: Re: ksh dumping core Date: 21 Oct 89 13:32:18 GMT Hdate: 22 Tishrey 5750 To: unix-wizards@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@taux01.nsc.com or amos@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 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@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@faatcrl.UUCP . ** | File Server!" - Me | | // . **** | | | \\ // GEnie: Airwarior: . .** | | | \X/ JIMBURWELL Techrat . | | +------------------------------------------------+--------------------------+ ----------------------------- From: Malaclypse the Elder Subject: Re: Help! Altos 5.3.1 fork is failing! Date: 21 Oct 89 06:57:22 GMT To: unix-wizards@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" Subject: Xenix driver for Univision 1024 video board Date: 21 Oct 89 00:01:47 GMT Keywords: driver univision xenix 386 To: unix-wizards@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@genisco -- David L. Markowitz Genisco Technology Corporation dav@genisco ----------------------------- From: Robert Krawitz Subject: Re: BSD file system Date: 21 Oct 89 18:29:19 GMT Sender: news@think.com To: unix-wizards@sem.brl.mil In article <31003@news.Think.COM>, dm@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 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111 ----------------------------- From: RAMontante Subject: Re: Real Time UNIX (was: Re: How do you tell a wizard?) Date: 21 Oct 89 19:35:23 GMT To: unix-wizards@sem.brl.mil der@cbnewsl.ATT.COM (david.e.rorke) <2396@cbnewsl.ATT.COM> : - -Real time scheduling is available (or will be in a couple weeks) I LOVE it! ----------------------------- From: George Hartzell Subject: "evils of alloca" discussion Date: 21 Oct 89 19:48:04 GMT Sender: news@boulder.colorado.edu Keywords: alloca To: unix-wizards@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@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell ----------------------------- From: "John F. Haugh II" Subject: Re: How to write a new Unix-like kernel Date: 21 Oct 89 18:27:31 GMT To: unix-wizards@sem.brl.mil In article <2046@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes: >In <17166@rpp386.cactus.org> jfh@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@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@rpp386.cactus.org | ... EMACS makes a computer slow. UUCPNet: {texbell|bigtex}!rpp386!jfh +--<><--<><--<><--<><--<><--<><--<><--- ----------------------------- From: "Mark J. DeFilippis" Subject: Re: How do you tell a wizard? Date: 21 Oct 89 01:11:12 GMT To: unix-wizards@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@adelphi.UUCP or mark@promark.UUCP UUCP: uunet!mimsy!rutgers!columbia!adelphi!markd ----------------------------- From: Alan Watson 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@sem.brl.mil From article <917@uakari.primate.wisc.edu>, by bin@primate.wisc.edu (Brain in Neutral): > From article <955@umb.umb.edu>, by campbell@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@rti!tijc02 ----------------------------- From: Guy Harris Subject: Re: BSD file system Date: 21 Oct 89 20:49:29 GMT To: unix-wizards@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 Subject: Re: What SHOULD go in the kernel Date: 21 Oct 89 20:51:59 GMT Keywords: device drivers To: unix-wizards@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 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@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 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@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 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@sem.brl.mil In article <1425@pttesac.UUCP> mavanamm@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 **************************