Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!sdd.hp.com!mips!twg.com!david From: david@twg.com (David S. Herron) Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: Case-sensitive Name Service Routines Message-ID: <8013@gollum.twg.com> Date: 29 Sep 90 23:57:29 GMT References: <40500002@hpindwa.HP.COM> <1990Sep29.091829.7625@lth.se> Reply-To: david@twg.com (David S. Herron) Distribution: comp Organization: The Wollongong Group, Palo Alto, CA Lines: 75 In article <1990Sep29.091829.7625@lth.se> Dan@dna.lth.se (Dan Oscarsson) writes: >In article <40500002@hpindwa.HP.COM> jbeck@hpindwa.HP.COM (John Beck) writes: [John Beck notices that gethostbyname() does caseless matching but that other things such as getservbyname() does not...] >>How do others feel about this issue? Is it worth pursuing to get a change >>effected? Or is it too trivial to bother with? Responses encouraged. >> >This is one area where Unix is a mess. For most normal people (non unix) >a letter A is an A independent of case. I think most of you do noy think >an A and an a read in a book have different meanings. Therefore I feel >it would be much better if as much as possible should be case-insensitive. >At least all routines concerning host names, protocol, services, user names and >group names (and some more I cannot think of just now). >Even file names should be looked up case-insensitive (but named case-sensitive), >but this may be to much for some unix hackers. yah.. that's "too much" for this Unix hacker. XtAddCallback() is a very different looking creature from xtaddcallback(). Ergo .. one case where case changes are useful. In any case .. gethostbyname() ultimately uses strcasecmp() to do caseless string comparisons. I'm sure it would be trivial to make getservbyname() and the others to do caseless string comparisons. Since the semantics of network, host and service names say that case is insignificant then this is a reasonable change. But this does not mean that the semantics of different cases are always unimportant! Just because *you* can't think of any use for enforcing casefull-ness in file names doesn't mean that there isn't a use. A for-instance I have in mind is a database being stored using the file system as the hashing/indexing scheme. There's a number of ways of doing this, and one of the early Unix authors did a comparison paper showing that if the Unix file system were a database then the indexing overhead is a h*ll of a lot lower than in more traditional databases. Er, back to the subject -- casefullness would help by increasing the set of characters that can be used in hash strings. This would tend to decrease the number of levels of indexing required to get to a particular data item. Even in written-communication case differences are important. For instance it grates on the nerves to see "UNIX" or "unix", the spelling is properly "Unix". Notice our two sentences above ... At the most -- to help humans who are using these systems -- there could be some kind of environmental option one could set to influence the kind of matching used in the file system. It would be a pretty simple hack to have iname() use a caseless compare given some global flag, in either the "proc" or "user" structures. The hard part is getting that global option into whichever of those structures is the appropriate place. There isn't, currently, either a system call or a user command for manipulating that kind of environment option. I do think it would be a good idea .. I don't think that traditional "environment variables" are the right place since this particular thing should be implemented inside the kernel and the kernel doesn't really have access to environment variables. Rather .. my memory is that environment variables are purely an invention of shell authors and the closest the OS gets to being involved with them is to pass them along during exec()'s. -- <- David Herron, an MMDF & WIN/MHS guy, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- Sign me up for one "I survived Jaka's Story" T-shirt!