Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!nsc!voder!dtg.nsc.com!waggoner From: waggoner@dtg.nsc.com (Mark Waggoner) Newsgroups: comp.sys.amiga.tech Subject: Re: SKsh completion bug. Message-ID: <392@icebox.nsc.com> Date: 9 Mar 90 00:53:34 GMT References: <8289@wpi.wpi.edu> <13920055@hpfelg.HP.COM> Reply-To: waggoner@icebox.UUCP (Mark Waggoner) Organization: National Semiconductor, Santa Clara Lines: 38 In article <13920055@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes: >Un*x usually makes the assumption that it would be redundant for all >applications to have their own wildcard matching code - the shell can >do it once. The only reasons that many AmigaDos utilities have their own >pattern matching code built in are that: > > 1) the original AmigaDos shell didn't expand wildcards itself, > 2) the length of the passed command line is limited to 255 (or so) > characters. Thus, if the wildcard matches many files, the line > will be truncated. > 3) the startup code supplied with Lattice C limits the number of > command line arguments to 32. > >Shell-expanded wildcards are still quite useful. If the last two >limitations can be removed or expanded (and they can), they will >become even more useful. Even unix has limitation number 2 (and possibly #3, I don't know) though it is larger. Try doing an ls */*/*/* from the root directory. As long as there is any limit to the command line length it can be useful for programs to do their own pattern matching. If the pattern matching code is put in a shared library (it is available in arp.library) you avoid unnecessary code duplication as well. The only reason I can see for doing shell expansions is to provide a unix-like environment, which means you also need a bunch of unix-like commands that expect the wildcards to be expanded. -- Mark Waggoner Santa Clara, CA (408) 721-6306 waggoner@dtg.nsc.com Unofficially representing National Semiconductor Local Area Networks Group Officially misrepresenting myself.