Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdahl!JUTS!ked01 From: ked01@ccc.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga.tech Subject: Re: ls 4.0k Case Sensitive (was Re: CygnusEd Pro) Message-ID: <82=R02Cb02ds01@JUTS.ccc.amdahl.com> Date: 21 Sep 90 00:14:34 GMT References: <1928@lpami.wimsey.bc.ca> <1990Sep6.034821.9389@ecn.purdue.edu> Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 77 [ If you see this twice, chalk it up to a PG&E power glitch earlier. ] In article dick@woodwrk.LoneStar.ORG (Richard H. Wood) writes: > >In article mrr@mrsoft.Newport.RI.US (Mark Rinfret) writes: > > > >Your problem may be at least partially due to the fact that ls 4.0 is > >case-sensitive. I went back to 3.2 (I think) because of this. > > From a(n) SKsh 1.4 window ls 4.0k is *NOT* case sensitive. I just > experimented a bit and found that Mark is correct, however. From a Wshell > window ls 4.0k *IS* case sensitive. What's the deal? (Steve?) I think there is a little bit of confusion here. All versions in this series of ls's (Justin's v3.x, my v4.xk, etc) are designed to perform normal wildcard expansion ("*" and "?") internally. This is necessary in order to bypass the command-line length limitation of 255 chars in AmigaDOS 1.3 and earlier (read: BCPL string limitation). In order for that to work though, the wildcard char(s) have to be "seen" by "ls", meaning that if the *shell* also expands these same characters, they need to be "quoted" in some manner to prevent the shell from doing its own thing. I forget what WShell uses offhand and how it controls "quoting", but from the observation above, it must be passing the wildcard(s) along to ls in argv[], thus allowing ls to control the expansion process. SKsh on the other hand, normally expands "*" and "?" itself, so unless you were explicitly quoting the wildcards yourself (foo\*, "foo*", etc), or had added "ls" to SKsh's "dwclist" (that Steve so kindly provided in v1.5), it was the shell doing the expansion, and ls never saw the wildcards. Further, SKsh has option flags that control whether wildcard expansion is enabled or not (+f), whether wildcard expansion will be sorted or not (+s), and whether wildcard expansion will be case sensitive or not (+c). Plus a few others. Lots of possibilities ... :-) I've no idea if WShell provides a similar degree of control. Bear in mind also, that ls has TWO case-sensitivity controlling flags. One (-m) controls whether alpha case is respected or ignored in the output sort order. The other (-M) is the one that controls whether or not case is significant in wildcard pattern matching. Now, the (RSN) v4.1k version of ls will continue to provide internal wildcard expansion, and both -m and -M flag support. Baring any new significant bugs found, this should be the final 1.3 compatible release, and should work with 2.0 just fine (but will not take advantage of, nor support 2.0 "goodies" like ExAll(), links, etc). The subsequent version (v5.0k ?) will be 2.0 only, and will support links (if they're actually "in there"), and will use the new file scanning calls, etc. It will NOT perform wildcard expansion internally, but will leave that chore up to the shell where it really belongs (IMO). That is, it will NOT do so, if the command-line length limitation has truly been overcome, and has a limit that is some "reasonable" value (say 32K ... yes, I do have dirs with a couple thousand files in them ... USENET articles do pile up, ya know). And with that change, the -M flag will be history, of course. At least that's the plan. Now if I could just get the documentation on all the new stuff (couldn't make it to Atlanta, sigh) ... Comments? /kim -- UUCP: kim@uts.amdahl.com -OR- ked01@juts.ccc.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25