🚀 go-pugleaf

[ If you see this twice, chalk it up to a PG&E power glitch earlier. ]


In article <dick.4313@woodwrk.LoneStar.ORG> dick@woodwrk.LoneStar.ORG (Richard H. Wood) writes:
> >In article <mrr.3864@mrsoft.Newport.RI.US> 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