pawn@wpi.wpi.edu (Kevin Goroway) (02/15/90)
I think I may have uncovered a bug in Sksh v1.3...
It seems that while doing command completion, and you type:
cd dh1:somedir/somefile/someletters[TAB]
^-intentional error
The system will tell you that volume dh1: has a read/write error.
Scary at first...
Also, although this may not be a bug...
if you type
cd ../something[TAB]
It will translate the ../ to /, which means your root directory now...
Oh well...
Otherwise, this shell is fantastic!
--
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
| Worcester Polytechnic Institute | "It happens sometimes, people just |
| Pawn@wpi.wpi.edu Pawn@wpi.bitnet | explode, natural causes."-Repo Man |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=koren@hpfelg.HP.COM (Steve Koren) (02/22/90)
> I think I may have uncovered a bug in Sksh v1.3... > It seems that while doing command completion, and you type: > cd dh1:somedir/somefile/someletters[TAB] > ^-intentional error > The system will tell you that volume dh1: has a read/write error. Is fixed and will work right in 1.4. Bug in the directory scan code; falls under the classification of "programmer stupidity error" :-) - steve
deven@rpi.edu (Deven T. Corzine) (02/23/90)
On 15 Feb 90 00:54:00 GMT, pawn@wpi.wpi.edu (Kevin Goroway) said: Kevin> Also, although this may not be a bug... Kevin> if you type Kevin> cd ../something[TAB] Kevin> It will translate the ../ to /, which means your root directory now... Kevin> Oh well... Hey, someone else besides me noticed! Yes, it's a bug. (Listening, Steve?) If you're in sys:devs/keymaps and type "ls ../print<TAB>", you will end up with "ls /printers" which will (when executed) look for :printers. This is definitely a bug. There are others. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
ose12@kunivv1.sci.kun.nl (ose cursus ) (03/05/90)
koren@hpfelg.HP.COM (Steve Koren) writes: >> cd dh1:somedir/somefile/someletters[TAB] >> ^-intentional error >Is fixed and will work right in 1.4. Bug in the directory scan code; >falls under the classification of "programmer stupidity error" :-) Does this also hold for the 'ls */*'? It makes my amiga guru or, more brutally, crash without a warning! Also, I have noticed, that SKsh 1.3 will not cooperate correctly with other programs using (unix-like) wildcards. eg. the simple command 'Zoo l df1:*' should normally give a list of all files that are zoo-ed in any file ending with '.zoo' (I seem to make it sound more complicating than it actually is). But SKsh will make it try to list any file, which makes zoo terminate on the very first file (eg .info) Is this fixed in 1.4?
koren@hpfelg.HP.COM (Steve Koren) (03/06/90)
> >Is fixed and will work right in 1.4. Bug in the directory scan code; > >falls under the classification of "programmer stupidity error" :-) > Does this also hold for the 'ls */*'? It makes my amiga guru or, more > brutally, crash without a warning! Yes. It is one and the same bug - just a different symptom. Fixed. Sorry!! The trouble was that if the first wildcard matched a file, SKsh would then look for "file/*", and look for files inside a file. That didn't go over too well with AmigaDos :-). > Also, I have noticed, that SKsh 1.3 will not cooperate correctly with > other programs using (unix-like) wildcards. eg. the simple command > 'Zoo l df1:*' should normally give a list of all files that are zoo-ed > in any file ending with '.zoo' (I seem to make it sound more complicating > than it actually is). But SKsh will make it try to list any file, which > makes zoo terminate on the very first file (eg .info) > Is this fixed in 1.4? Well, it is not really broken. In SKsh (and for that matter, ksh or sh under Un*x), to pass a wildcard to an external program you must quote it. For example: zoo l df1:* (wildcard gets expanded by SKsh, sh, ksh, etc) zoo l 'df1:*' (wildcard gets expanded by zoo) zoo l "df1:*" (wildcard gets expanded by zoo here too) You probably want the 2nd or 3rd example. In the first, SKsh is doing the correct thing from its point of view - it is expanding the wildcard and passing everything matched (ie, every file name) to the program. 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. Hope this helps. Would it be a good idea for me to make this a bit more clear in the docs? I probably didn't describe it very well in there. - steve
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (03/09/90)
In <682@xdos.UUCP>, doug@xdos.UUCP (Doug Merritt) writes: >The problems with that are: > 1) Pervasiveness/universality: if it's not in the shell, that > generally means that feature is not universally available. > So I have to remember which commands allow it, which do not, > which support one flavor of wildcarding, which allow another, > which use both, which have Super Wildcard Expansions, etc. > So this is also a "consistency/documentation" argument. > And this is precisely the problem I currently have. As you point out, it is a 'consistency/documentation' problem, not, as you mention earlier, a 'not in the shell' problem. As you well know, there are commands for which shell expansion of wildcards is innappropriate, and because of this, it is sometimes desirable to allow the program to determine the way to handle expansion of the wildcards. > 2) No, you don't need "unix-like commands". Essentially all > reasonable utilities support a command line list of files. > Even if they support wildcards, they will not object to > what appears to be a wildcard-free list of filenames typed > by hand. They may or may not object. This is the whole point of having shell expansion; that programs will be written with shell expansion in mind if that's the way the system works, and will not object to extra arguments. With expansion left strictly to the program, anarchy abounds, and a program may choke, do the wrong thing, or ignore everything past the first filename without telling you. > 3) Duplication of effort/code size. When every command has its > own wildcard code, it not only wastes code space, it also > (probably more significantly) wastes the time of the developer > who had to reinvent the wheel one more time. As I mentioned earlier, sometimes it is desirable for the program to expand the wildcards. A case in point is where the wildcards specify filenames that are not currently in existence. One day I typed 'mv *.foo *.bar' on a Unix machine, and was appalled to find out that it could not be done. Why should I have to remember the way a shell treats wildcards for non-existent files (and to subsequently have to write it as a 'foreach' loop, when there is a perfectly good way to avoid both this problem and the problems inherent in program expansion of wildcards? >So, no, it's not just to provide a Unix-like environment. It's because >it's smart. The only (arguably) better way is to provide the facility >in a *standard* system library (ARP may reach this status but it ain't >there yet). Now there's the ticket. A simple call to a system library that will expand the wildcards, callable by the program _when appropriate_. Make it easy to use and cheap in code size, and it will be taken into consideration and used by programmers. In the example above, the 'mv' command would expand the first argument with a call to the system routine, and would either handle the second argument itself, or pass the second argument to the wildcard expansion, along with the first argument as the target of the expansion, rather than whatever currently exists in the file system. > This makes it a little less universal, in that some boneheads >will still write programs that don't *use* the system facility (as >previously established on all the O.S.'s that do this). But it gets >around the limited expansion space problem. Boneheads abound. We cannot ever guarantee that all programs will be written correctly. About all we can do is to provide the facilities for doing the right thing, document them in a way that they are understandable (lets make it more than strictly C oriented documentation), and hope that the errant programs are in the minority. >It also potentially allows wildcards to be used even in e.g. requesters, >which the shell approach does not. Yes, and a requester could call the same library, selectively. If the requester required some list criteria other than existing files, it could be passed the list of names to use. We have a machine in which the wildcard expansion philosphy is not set in stone. Let's not make the mistake of accepting either of the 'extremes' of philosophy. Let's look at how we can have the best features of both philosophies. -larry -- Entymology bugs me. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
waggoner@dtg.nsc.com (Mark Waggoner) (03/09/90)
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.
doug@xdos.UUCP (Doug Merritt) (03/10/90)
In article <392@icebox.nsc.com> waggoner@icebox.UUCP (Mark Waggoner) writes: > >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. A little history here: this argument has been going on endlessly over every non-Unix system in existence; i.e. the above is a popular argument. The problems with that are: 1) Pervasiveness/universality: if it's not in the shell, that generally means that feature is not universally available. So I have to remember which commands allow it, which do not, which support one flavor of wildcarding, which allow another, which use both, which have Super Wildcard Expansions, etc. So this is also a "consistency/documentation" argument. And this is precisely the problem I currently have. 2) No, you don't need "unix-like commands". Essentially all reasonable utilities support a command line list of files. Even if they support wildcards, they will not object to what appears to be a wildcard-free list of filenames typed by hand. 3) Duplication of effort/code size. When every command has its own wildcard code, it not only wastes code space, it also (probably more significantly) wastes the time of the developer who had to reinvent the wheel one more time. So, no, it's not just to provide a Unix-like environment. It's because it's smart. The only (arguably) better way is to provide the facility in a *standard* system library (ARP may reach this status but it ain't there yet). This makes it a little less universal, in that some boneheads will still write programs that don't *use* the system facility (as previously established on all the O.S.'s that do this). But it gets around the limited expansion space problem. It also potentially allows wildcards to be used even in e.g. requesters, which the shell approach does not. If I misunderstood you, and we're in violent agreement on this :-), my apologies. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
peter@sugar.hackercorp.com (Peter da Silva) (03/10/90)
> 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. It also ensures that (a) you can be guaranteed that all programs will accept wildcards, (b) that all programs will use wildcards uniformly, and (c) that you can defeat the wildcarding easily and in a uniform manner. Quick, how do you tell a random Amiga program to use the file named "#?* *?#"? Does your version of grep use UNIX-style, DOS-style, Amiga-style, or ARP-style wildcards? -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
mwm@raven.pa.dec.com (Mike (Real Amiga have keyboard garages) Meyer) (03/10/90)
<Warning - religious comments follow> In article <5367@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > 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. It also ensures that (a) you can be guaranteed that all programs will accept wildcards, (b) that all programs will use wildcards uniformly, and (c) that you can defeat the wildcarding easily and in a uniform manner. Or: a) you can be guaranteed that programs that don't take file names as arguments will do oddball things if when given characters that aren't magic in that context; b) that programs that want to do pattern matching against anything other than files will regularly require magic cookies; c) that scripts running programs that pattern match will require levels of quoting that may depend on other apparently unrelated arguments. Quick: how do you get a ".*" to a sed being run from a shell script run via 'system' from the program you're actually invoking? Peter is arguing for consistency to the point that it starts becoming painfull. By providing a system library with calls to do pattern matching on a single argument or an argument list, you can have the same kind of consistency. Better yet, you can have commands that treat string arguments as strings, and not as file names that have to be treated magically in some cases. Even better, you can provide for matching in spaces other than the file space (running processes, machines on the network, and probably others). Similar comments can be made regarding providing file name completion. BTW, the "unix-like commands" don't need to expect anything to be wild-carded. They'll run quite happily in any environment. All they need to be usefull in such an environment is to expect multiple filenames as arguments. I've got a hacked C startup module that does AmigaDOS style pattern matching before calling the main routine. It gets linked in with programs that expect multiple file names, but not with programs that expect a fixed number (like zero) of arguments filename arguments. <mike -- The sun is shining slowly. Mike Meyer The birds are flying so low. mwm@relay.pa.dec.com Honey, you're my one and only. decwrl!mwm So pay me what you owe me.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (03/12/90)
In <13664@nigel.udel.EDU>, new@udel.edu (Darren New) writes: > >On a side note: >Why do file requestors all have rediculously (sp?) small name lists? >I have my screen open to 640x400 lines and most of my file requestors >show me 5-10 names at a time. I can get 30-40 names at a shot with >a workbench display, and THAT is showing icons as well! Golly! -- Darren Not all do. The one in CEDPro 2.0 shows me 30 dir/file names and 30 device/assigned names at a time, and the req.library that provides it is either shareware or freely distributable. Khalid Aldoseri (Scripit, DSD, and a host of other freeware), is currently working on a file requester implemented as a library. It is resizable, which is a great way to provide for long lists and to allow you to get it out of the way of text on the screen you might need to see. I don't know if any versions of it have been released publically yet, but if not, it should be soon. With 1.4 coming, we have every hope that there will be a CBM supplied FR, that programmers will use it because of its low overhead to call, and that it will be fairly easy to replace with one of your choosing, including Khalid's. -larry -- Entomology bugs me. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
new@udel.edu (Darren New) (03/13/90)
In article <1213@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >As I mentioned earlier, sometimes it is desirable for the program >to expand the wildcards. I was also bothered by the fact that the UNIX man command could not "do" its own wildcard expansion. Thus, I could not "man *seek*" and find out all the seek-like functions. Let's hear it for program-driven expansion with a standard library!!! On a side note: Why do file requestors all have rediculously (sp?) small name lists? I have my screen open to 640x400 lines and most of my file requestors show me 5-10 names at a time. I can get 30-40 names at a shot with a workbench display, and THAT is showing icons as well! Golly! -- Darren
mann@watserv1.waterloo.edu (Shannon Mann) (03/13/90)
In article <13664@nigel.udel.EDU> new@udel.edu (Darren New) writes: >I was also bothered by the fact that the UNIX man command could not >"do" its own wildcard expansion. Thus, I could not "man *seek*" and find >out all the seek-like functions. >-- Darren : Try man -k seek (-k is the keyword option) And when you are done, try man man :-) -=- -=- Shannon Mann -=- mann@watserv1.UWaterloo.Ca -=-
new@udel.edu (Darren New) (03/13/90)
In article <1414@watserv1.waterloo.edu> mann@watserv1.waterloo.edu (Shannon Mann) writes: >In article <13664@nigel.udel.EDU> new@udel.edu (Darren New) writes: >>I was also bothered by the fact that the UNIX man command could not >>"do" its own wildcard expansion. Thus, I could not "man *seek*" and find >>out all the seek-like functions. >Try man -k seek (-k is the keyword option) And when you are done, try >man man :-) Smiley appriciated. Two problems tho: management does not run "makewhatis" very often, and I really wanted to do command completion, not wildcard expansion. I just thought I would simplify some. (BTW, man -k only gives you the names of the pages, not the pages themselves. You still have to type them in or do some shell magic.) Besides, this illustrates my point! The shell wildcarding was inappropriate, so I had to use a separate command (-k option of man) and a separate wildcard syntax (assumed caseless search of *mypattern*) because man did not do its own wildcard expansion. so there! :-P -- Darren :-)
waggoner@dtg.nsc.com (Mark Waggoner) (03/13/90)
In article <682@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >In article <392@icebox.nsc.com> waggoner@dtg.nsc.com (I) write: >> >>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. > >The problems with that are: ... valid problem # 1 > 2) No, you don't need "unix-like commands". Essentially all > reasonable utilities support a command line list of files. > Even if they support wildcards, they will not object to > what appears to be a wildcard-free list of filenames typed > by hand. ... more valid problems. Most AmigaDOS standard commands do not support a list of filenames very well. They should, but they don't. >So, no, it's not just to provide a Unix-like environment. It's because >it's smart. The only (arguably) better way is to provide the facility >in a *standard* system library (ARP may reach this status but it ain't >there yet). This makes it a little less universal, in that some boneheads >will still write programs that don't *use* the system facility (as >previously established on all the O.S.'s that do this). But it gets >around the limited expansion space problem. > >It also potentially allows wildcards to be used even in e.g. requesters, >which the shell approach does not. > >If I misunderstood you, and we're in violent agreement on this :-), >my apologies. Well, we're in violent near agreement. I agree that shell wildcard expansions are smart and I also think that a STANDARD system library that included expansions would be better. Perhaps I overstated my original claim at the beginning of this message. The problem I do see is that most STANDARD AmigaDOS commands do NOT support a list of filenames as arguments and expanding the wildcards in the shell breaks them. Yes, I know you can inhibit the substitution with the right combination of quotes and magic, but then I have to remember which commands support multiple file arguments and which do not. Blech. Ideally, I would like to see a wildcard expansion library call AND have the commands support multiple file arguments. I'd rather be able to type: (Substitute * for #? if you like). Copy #?.c #?.o otherdir than: Copy (#?.c|#?.o) otherdir and have copy expand #?.c and #?.o. (I think this is a real example, though I can't try it right now to see). -- Mark Waggoner Santa Clara, CA (408) 721-6306 waggoner@dtg.nsc.com Unofficially representing National Semiconductor Local Area Networks Group Officially misrepresenting myself.
bdb@becker.UUCP (Bruce Becker) (03/13/90)
In article <13664@nigel.udel.EDU> new@udel.edu (Darren New) writes: |[...] |I was also bothered by the fact that the UNIX man command could not |"do" its own wildcard expansion. Thus, I could not "man *seek*" and find |out all the seek-like functions. Let's hear it for program-driven |expansion with a standard library!!! The Berkeley Unix "man" system has an "apropos" command which does essentially what you suggest here. No doubt it will appear in Amix if they're doing things the way they ought to... In general, program-driven expansion is a bad idea, but having a common library helps a bit (but it's still ugly). There are situations where one needs to have program- driven expansion even in Unix, such as the "find" command for example... -- (__) Bruce Becker Toronto, Ontario w \@@/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/v/-e UUCP: ...!uunet!mnetor!becker!bdb _/ \_ "So far from God, so close to the United States" - Old Mexican proverb