Path: utzoo!attcan!uunet!cs.utexas.edu!convex!rosenkra From: rosenkra@convex.com (William Rosencranz) Newsgroups: comp.sys.atari.st Subject: Re: case insensitivity in TOS Message-ID: <1991Jan23.115630.5846@convex.com> Date: 23 Jan 91 11:56:30 GMT References: <1991Jan12.023029.20022@convex.com> <1991Jan18.005041.22961@convex.com> <1991Jan22.170111.12465@cs.mcgill.ca> Sender: news@convex.com (news access account) Organization: Convex Computer Corporation; Richardson, TX Lines: 189 Nntp-Posting-Host: convex1.convex.com In article <1991Jan22.170111.12465@cs.mcgill.ca> depeche@cs.mcgill.ca (Acme Instant Dehydrated Boulder Kit) writes: >In article <1991Jan18.005041.22961@convex.com> rosenkra@convex.com (William Rosencranz) writes: >>it would probably not break any existing code. if so, how? > >For one thing, most file selector boxes, and command shells, translate >lower case characters into uppercase before processing input lines i don't know about "most" but gulam does not xlate to upper case. it passes things off to exec'd processes with no case conversion. some compiler startup codes and libraries do that, but i don't thing GNU c is one of the, and i even patched good ol' alcyon to stop that foolish practice. in fact no unix shell clone on the st does this now (gulam, bash, msh, etc). PCOMMAND and NEODESK are not unix-like shells. the desktop does, however, force upper case, which is why it is a pain in the *ss to run unix utilites from the desktop, especially ones which have different meanings of "-c" and "-C". all this talk has nothing to do with TOS itself supporting (even toggling this feature on/off) mixed case file names. look, i'd like to have the option of switching case sensitivity on and off at will. i myself see no reason why this cannot be added. i myself like having important files in caps (like README and Makefile) since with a directory list, they appear set aside, and easy to spot (i.e. more productive). pls don't argue that YOU may find it revolting. I do not. and besides, if it is SWITCHABLE, then it does not impact you our any program in the slightest. i have discussed how this can be done in a previous note. all i want to do is find out CAN IT BE DONE and IS ATARI PLANNING ON DOING THIS? which apratt@atari answered. >fp=fopen("datafile.in","r"); i can't see how/why a program has to force case anyway, since TOS does it for you. it IS case insensitive, so DaTaFiLe.In is the same file as datafile.in is the same as DATAFILE.IN is the same as DataFile.In, etc. The only reason programs force upper case is for cosmetic reasons, i.e. for consistency. try it youself: #include main() { FILE *fp; char buf[256]; fp=fopen("datafile.in","w"); fprintf(fp,"Hello\n"); fclose(fp); fp=fopen("DATAFILE.IN","r"); fscanf(fp,"%s",buf); printf("%s\n",buf); fclose(fp); exit(0); } i bet this will print "Hello". meaning it does not matter AT ALL what case the file name is. both fopens open the same file. i already mentioned that the program can make a call like this to force old, compatible behavior: Fcase(CASE_OFF); BEFORE doing anything, if it must. and i already mentioned that the desktop of TOS x.x which would have this new feature can have an additional menu item for configuration (which would cause Fcase be called if the menu state changes, just like the blitter). FOr those of you who still don't understand this, i offer this hypothetical desktop menu (for those who hate cmd shells): ________________________________________ | Configure | |---------------------| . . . . |---------------------| | X Case sensitivity | |---------------------| . ^ . . | . "X" means it is ENabled... ________________________________________ | Configure | |---------------------| . . . . |---------------------| | Case sensitivity | |---------------------| . ^ . . | . no "X" means it is DISabled... >It is a FACT that if such a convention were added, TONS of programs >would need little changes to work again. I happen to use a few programs see above. it does NOT effect the programs, if implemented this way. and new programs can inquire the state of case sensitivity: state = Fcase (CASE_INQUIRE); or somesuch. here is the example program with this "new" TOS: #include main() { FILE *fp; char buf[256]; if(Fcase(CASE_INQURE) == CASE_ON) Fcase(CASE_OFF); /* added...*/ fp=fopen("datafile.in","w"); fprintf(fp,"Hello\n"); fclose(fp); fp=fopen("DATAFILE.IN","r"); fscanf(fp,"%s",buf); printf("%s\n",buf); fclose(fp); exit(0); } for existing programs, the if(Fcase(CASE_INQURE) == CASE_ON) Fcase(CASE_OFF); /* added...*/ is done with the desktop menu selection, making it 10000000% compatible with older TOS. how can i make this any clearer? if the effort to do this is 2 manweeks (design, implement, debug, test, document), and it takes 50 bytes of ROM, WHY NOT DO IT????? sheesh! >which are no longer being maintained by the author, and I don't have the >sourcecode. What do I do now that I can't run them anymore? > >> and it is a BIG win, IMHO. don't knock it 'til you've tried it. i prefer seeing files in my directory like this: % ls Makefile bbb.c eee.c nnn.c README ccc.c hhh.c ppp.c aaa.c ddd.c iii.c sss.c over: % ls aaa.c ddd.c iii.c ppp.c bbb.c eee.c makefile readme ccc.c hhh.c nnn.c sss.c since my eye is trained to go to the upper left on a page first, so "important" files should be there (and i keep them there, consciously). Yes, this is unix. but it is equally valid for directories which use icons, or file selector boxes, or whatever. also, it is a pain in the *ss which moving mixed case file names between systems which do have case sensitivity (e.g. unix) and the ST. you always have to convert names. >can have IN THE SAME VERY DIRECTORY files like > >jove.RC >jovE.rC >JoVe.Rc >JOVE.RC >jove.rc not a very good example >And this is just a half-assed step towards a unix-like filesystem - if you >want a real unix filesystem, you gotta throw out all this TOS and MSDOS no one is talking about a unix file system, just something that can't be more trivial to implement, will NOT break any existing code, and certainly can't hurt at all (and can help, at least me...). a unix FS does not make sense (really) on the ST since it is not multitasking. note that ST/MINIX does implement FS, but then again it is not running TOS. all i want is a choice. right now we do not have one... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com