dick@woodwrk.LoneStar.ORG (Richard H. Wood) (09/18/90)
>In article <mrr.3864@mrsoft.Newport.RI.US> mrr@mrsoft.Newport.RI.US (Mark Rinfret) writes: >>In article <1990Sep6.034821.9389@ecn.purdue.edu> yorkw@stable.ecn.purdue.edu (Willis F York) writes: >>NOW MY PROBLEM. >> >>I got files i can't find on my floppy, they run and act like they is thers., >>but they don't show up, Yes i tried the -h file option of >>ls 4.0k (i'm usinf this ls) but these files don't >>show up on browser/dir/list/anything else i use. >> >>BUT THE FILES ARE THERE!, They WORK they run they are invisible!. >> >>any ideas. > >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?) >Mark > >-- >################################################################# ># Mark R. Rinfret, MRSoft Home: 401-846-7639 # ># mrr@mrsoft, galaxia!mrsoft!mrr Work: 401-849-9930 x301 # >################################################################# Dick -- Richard H. Wood // dick@woodwrk.LoneStar.ORG 246 Bancroft Drive East \X/ uunet!digi!woodwrk!dick Garland, Texas, 75040 "Become an ORGAN DONOR" +1 214 530 2595 \/\/ \/\/ \/\/ \/\/ \/\/ \/\/ \/\/ \/\/ \/\/ \/\/ \/\/ \/\/ \/\/ \/\/ \/\/
yarnall@usceast.UUCP (Ken Yarnall) (09/20/90)
In article <dick.4313@woodwrk.LoneStar.ORG> dick@woodwrk.LoneStar.ORG (Richard H. Wood) 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?)
As I recall, ls 4.0k has a switch to enable/disable case sensitivity, and is
by default case sensitive (to more closely mimic the U*IX version). I can't
recall the letter used for the switch, and I'm not on my Amiga right now, but
the manual page for ls 4.0k is quite complete.
As for the SKsh/Wshell question, is it possible that you are using SKsh's
builtin ls when you are running that shell? That is the only explanation
that comes to mind.
+
+Dick
+
kenny
--
Ken Yarnall /// yarnall@cs.scarolina.EDU
Math Department, USC \\\/// yarnall@ucseast.UUCP
Columbia, S.C. 29208 \\\/ (803)777-6686
I want a T-shirt with a cow on it saying "Don't have a Bart, man."ked01@ccc.amdahl.com (Kim DeVaughn) (09/21/90)
[ 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
koren@hpfelg.HP.COM (Steve Koren) (09/21/90)
> >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?) Both SKsh and ls 4.0k have different options to handle case sensitivity, and these options can interact in interesting ways. However, there is enough flexibility to make them act almost any way you want. First of all, in SKsh 1.5 (not 1.4!) you have a choice about whether to let SKsh expand the wildcards on the command line, or have ls do it. (See the dwclist command for details on that - again, only in >= 1.5). If you let SKsh expand wildcards, then case sensitivity will be controlled by SKsh: ie, you can turn it off or on with an SKsh option (see the options command). If you let ls expand the wildcards by putting ls in your dwclist, (generally a good idea), then case sensitivity will be controlled by ls (and I believe you can turn case sensitivity on or off there as well). I don't know how WShell handles case sensitivity, and whether it is configurable in this regard, so I can't help you there. (I should really buy this and play with it someday...) In short, you can make it work however you want, but you have to set it up that way. The default may not be what you like. Hope this helps! - steve
koren@hpfelg.HP.COM (Steve Koren) (09/21/90)
> As I recall, ls 4.0k has a switch to enable/disable case sensitivity, and is > As for the SKsh/Wshell question, is it possible that you are using SKsh's > builtin ls when you are running that shell? That is the only explanation > that comes to mind. This poster has a good point as well; you may be using the builtin SKsh "ls" command, which will happen by default unless you configure it another way. You can make SKsh *completely* forget about its own ls command by saying: unset -b ls From then on, any references to "ls" will use an alias, if you have one, or a function if you have one, or the external one failing either of those. Another way to play with the external "ls" without unsetting the SKsh internal "ls" is to say: alias ls=$(which ls) Then, any references to "ls" will use the SKsh alias, which will point to the external command. The ls 4.0k command provides many more options and configurations than the internal SKsh ls does. You can make ls 4.0k into a resident command using: resident -a $(which ls) from within SKsh. That, coupled with the "unset -b ls" and "dwclist -a ls" above, will let you use Kim's "ls" with little invocation overhead while letting ls 4.0k expand wildcards. Hope this helps, - steve
billsey@agora.uucp (Bill Seymour) (09/21/90)
In article <82=R02Cb02ds01@JUTS.ccc.amdahl.com> ked01@ccc.amdahl.com (Kim DeVaughn) writes:
:
: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).
And this one will fix that annoying problem with both 3.1 and 4.1 that
puts my 3000 into 'real, real slow speed' mode? It doesn't happen each time,
and Doug Walker said that he did a workaround by playing with max size for
windows... It seems like it doesn't bite until I've done something that I
need to be keep runing over the serial port or something else that requires
me to not miss characters. Once it's in the mode, I can't get out without
rebooting.
: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) ...
I thought CATS made the DevCon notes available to developers (for a
fee, of course) after Devcon? Check to see if you can buy them now, there's
a *lot* of good stuff in there.
: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
What? No PLink? Dump the CI$ and move up... :-)
--
-Bill Seymour ...tektronix!reed!percival!agora!billsey
=============================================================================
Bejed, Inc. NES, Inc. Northwest Amiga Group At Home Sometimes
(503) 281-8153 (503) 246-9311 (503) 656-7393 BBS (503) 640-0842ecarroll@vax1.tcd.ie (Eddy Carroll) (09/24/90)
> 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. > > Comments? > > /kim Since (1) the current AmigaShell 2.0 doesn't support wildcard expansion on the command line (which I agree is a nice place to have it), and (2) AmigaDos 2.0 has calls to do wildcard expansion for you, I'd argue quite strongly for leaving in wildcard support. Particularly since there are no 2.0-specific enhanced shells available as yet, to do the wild card expansion instead. My suggestion for 4.1 (4.0 is great, by the way) is a flag to say that the shell has done the wildcard expansion, so that I don't get a long listing when I do ls * in my shell (which is not yet sksh). Just my $.02. -- Eddy Carroll ----* Genuine MUD Wizard | "You haven't lived until ecarroll@vax1.tcd.ie | you've died in MUD!" ecarroll%vax1.tcd.ie@cunyvm.cuny.edu | -- Richard Bartle
kim@uts.amdahl.com (Kim DeVaughn) (09/28/90)
In article <1990Sep21.161025.14703@agora.uucp> billsey@agora.uucp (Bill Seymour) writes: > In article <82=R02Cb02ds01@JUTS.ccc.amdahl.com> ked01@ccc.amdahl.com (Kim DeVaughn) writes: > : > :Now, the (RSN) v4.1k version of ls will continue to provide internal wildcard > > And this one will fix that annoying problem with both 3.1 and 4.1 that > puts my 3000 into 'real, real slow speed' mode? It doesn't happen each time, [ Just to avoid confusion, the problem exists in v3.1 and v4.0k ... v4.1k has yet to be released. ] Yes, the problem has been found! There are several other, quite different ways it can manifest itself also, BTW. Henrik Clausen found that *his* manifestation of the problem disappeared if the standard Lattice "cres.o" startup code was used in place of the custom "mycres.o" code (thanks again, Henrik!). This also explains why v3.1 has the problem, as that code is identical in both 3.1 an 4.0k. Not having a 3000/2.0 myself, I haven't bothered to try and isolate exactly *what* in "mycres.o" was causing the problem though. The price paid for this solution is an increase of a few hundred bytes, which I think is "reasonable". Another plus, is that is by using the standard startup code, it allows me to use the Lattice getenv() function, rather than having to "roll my own" (though *that* fn() adds nearly a full 1K to the executable). Also, it means one less piece of code that needs to be supported. There was one further complication with this. Someone was getting "instant Guru's" using a test version of ls that was built using the Lattice v5.05 "cres.o", but when it was recompiled using the SAS v5.10 version, the problem went away. Since this was done under a beta version of a commercial product, I'm not sure where the problem really was, but that's why I've been waiting for my copy of SAS v5.10 to show up before releasing v4.1k of "ls". Which showed up yesterday ...!!! So, in summary, "ls" v4.1k will be along in not too long ... after some final beta testing, and it will be a bit larger than I'd like (feature enhancements aside). I will try and reduce the "bloat" in a subsequent revision, but I want to get something that works well with both 1.3 and 2.0 out ASAP. /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
kim@uts.amdahl.com (Kim DeVaughn) (09/28/90)
In article <6878.26fe0ccf@vax1.tcd.ie> ecarroll@vax1.tcd.ie (Eddy Carroll) writes: > > 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, > > Since (1) the current AmigaShell 2.0 doesn't support wildcard expansion on the > command line (which I agree is a nice place to have it), and (2) AmigaDos 2.0 > has calls to do wildcard expansion for you, I'd argue quite strongly for > leaving in wildcard support. Particularly since there are no 2.0-specific > enhanced shells available as yet, to do the wild card expansion instead. So I have been told. One of the things that *didn't* make it "in there". Sigh. > My suggestion for 4.1 (4.0 is great, by the way) is a flag to say that the > shell has done the wildcard expansion, so that I don't get a long listing > when I do ls * in my shell (which is not yet sksh). Thanks ... glad you like it! Another possibility is seperate versions (read: heavily #ifdef'd code), as I really *would* like to reduce the amount of "vestigial" code in the binary. I haven't decided on an implementation strategy yet, and probably won't until 2.0 gets "frozen" (read: is generally available), as much of the 2.0 specific stuff could well change (are links in or not?, wildcard expansion, etc). In any case, rest assured that I won't leave AmigaShell users "out in the cold" ... /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