Re: SSHD user-switching under Cygwin/XP (was Re: Case insensitivity ad nauseum)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan Kidd wrote: It took me some time to figure out the syntax, but I've now tried various permutations of net use. I mostly am causing it to generate a lot of system errors: [EMAIL PROTECTED] ~ $ net use z: '\\empress\oberon' /user:oberon 'password' System error 5 has occurred. Access is denied. I didn't carefully read over this whole list of permutations, but at first glance, perhaps it's just the domain for oberon that's missing? e.g. net use z: \\empress\oberon /user:empress\oberon password Yep. That's it, I just also have to login using a password rather than my private/public key pair. Thanks, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- All those who believe in psychokinesis raise my hand. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/11CrLD1OTBfyMaQRAqUSAJ96W6t84zG34/eZJtW6PZrdICHhhgCdEO4m 0QWgWmRd5r5YvcjD09wlhAc= =PaM1 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SSHD user-switching under Cygwin/XP (was Re: Case insensitivity ad nauseum)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan Kidd wrote: Derek Robert Price wrote: I didn't carefully read over this whole list of permutations, but at first glance, perhaps it's just the domain for oberon that's missing? e.g. net use z: \\empress\oberon /user:empress\oberon password Yep. That's it, I just also have to login using a password rather than my private/public key pair. As I revisit this, I note however, that this is not sufficient. I'm trying to set up automated testing, so I couldn't enter the password if I wanted to - even saving to a file and attempting to echo it to ssh doesn't work because ssh grabs the TTY to get the password. I really need to use public key authentication, but this prevents SSHD from grabbing the Windows authentication tokens. I think maybe this is a Windows (combined with SSHD?) limitation that I cannot get any access to network resources without authenticating with a password? I don't know if this helps in your situation, but if you are always testing from the same machine you could have a persistent connection to some share on empress using oberon's password. Any subsequent access to any share on empress will automatically use this user/password without prompting for it. That is, it is sufficient to simply run: net use * \\empress\oberon But then if you do this you might as well make the original connection you want as persistent and never even bother with net use in your script. (On W2K, at least, it doesn't even seem possible to use a password from STDIN.) That doesn't work. As near as I can tell now based on my experiments and reading, my problem is that I am attempting to launch the tests via an automated ssh connection from another computer. SSHD on Cygwin does user-switching, but only gets Windows auth tokens if you use your Windows password to login. Since I can't use a password with ssh from an automated script, I cannot get Windows auth tokens, and without Windows auth tokens, Windows won't let me see or mount, _any_ network share, not even a share that allows anonymous connections. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- I will not carve gods. I will not carve gods. I will not carve gods... - Bart Simpson on chalkboard, _The Simpsons_ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/129cLD1OTBfyMaQRAufGAKDGEogiW2K/vheO9F7KeKnA3N/V8wCg3GMq 16ABCrtdg9dYiLjNChQb2lw= =LBvf -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SSHD user-switching under Cygwin/XP (was Re: Case insensitivity ad nauseum)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Wood wrote: Now I'm really out on a limb, but, what user is sshd running as before it switches? Does logging into sshd without a password, using a key instead, merely mean that no switch from this default sshd user occurs? If that's the case, can we adjust the default user that sshd runs as? Yes, according to the email archives I have found, I could run as my cvs test user rather than LOCAL_SYSTEM or whatever the sshd account is by default, but it would limit me to logging into the machine via ssh as only the cvs test user, something else I am trying to avoid. I could also, possibly, set up the generic SSHD on one port and the cvs test SSHD on another. So far I am avoiding this because according to the mailing lists and the one time I tried it, there are some permissions issues in the DLLs that I am both reluctant to dive into with my level of Windows expertise. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- My father often told me, We have servants and machines in order that our will may be carried out beyond the reach of our own arms. Machines are more powerful than servants and more obedient and less rebellious, but machines have no judgement and will not remonstrate with us when our will is foolish, and will not disobey us when our will is evil. In times and places where people despise the gods, those most in need of servants have machines, or choose servants who will behave like machines. I believe this will continue until the gods stop laughing. -Orson Scott Card, Children of the Mind -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/13ZCLD1OTBfyMaQRAuo0AJ42oYoC9l4W/nF3NOj3Oz5S81XQdgCfaeiE oPqpe2bowZd7LFaHNJqclYo= =8/gy -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SSHD user-switching under Cygwin/XP (was Re: Case insensitivity ad nauseum)
Derek Robert Price wrote: My research so far leads me to believe that the problem is that the Local System Account does not have permission to access the drive. ... it set up for nightly testing (if anyone knows how to get Cygwin sshd to allow access to a mounted Samba share via its login shell, I could use some assistance). I haven't been following the case-insensitivity thread, but is this the problem: You are logging in to Cygwin sshd using publickey auth (i.e. no password), and you cannot access a Samba/Windows share that your user should be able to? If so, the explanation is this: sshd runs as the Windows SYSTEM user (or other user with sufficient rights) to create Windows authentication tokens. These are fully valid on the local machine, *but* if you do not log in with a password, the token does not contain a password (because there is no way to know what it is - it is hashed in the Windows password database). Therefore, no password = unable to authenticate to remote machines, therefore unable to access network shares. There is no elegant solution. Inelegant solutions include: * Only log into sshd with a password. * Put your password into a file only readable by you, and use it with the Windows net use command during your .profile, to connect to the network share. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SSHD user-switching under Cygwin/XP (was Re: Case insensitivity ad nauseum)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max Bowsher wrote: Derek Robert Price wrote: My research so far leads me to believe that the problem is that the Local System Account does not have permission to access the drive. ... it set up for nightly testing (if anyone knows how to get Cygwin sshd to allow access to a mounted Samba share via its login shell, I could use some assistance). I haven't been following the case-insensitivity thread, but is this the problem: You are logging in to Cygwin sshd using publickey auth (i.e. no password), and you cannot access a Samba/Windows share that your user should be able to? Yes. If so, the explanation is this: sshd runs as the Windows SYSTEM user (or other user with sufficient rights) to create Windows authentication tokens. These are fully valid on the local machine, *but* if you do not log in with a password, the token does not contain a password (because there is no way to know what it is - it is hashed in the Windows password database). Therefore, no password = unable to authenticate to remote machines, therefore unable to access network shares. There is no elegant solution. Inelegant solutions include: * Only log into sshd with a password. I can't. I want to make this part of hte automated nightly testing and currently, for security reasons, the testing account doesn't even have a password. * Put your password into a file only readable by you, and use it with the Windows net use command during your .profile, to connect to the network share. It took me some time to figure out the syntax, but I've now tried various permutations of net use. I mostly am causing it to generate a lot of system errors: [EMAIL PROTECTED] ~ $ net use z: '\\empress\oberon' /user:oberon 'password' System error 5 has occurred. Access is denied. [EMAIL PROTECTED] ~ $ and [EMAIL PROTECTED] ~ $ net use '\\empress\oberon' /user:[EMAIL PROTECTED] 'password' System error 86 has occurred. The specified network password is not correct. [EMAIL PROTECTED] ~ $ net use '\\empress\oberon' /user:oberon 'password' System error 1312 has occurred. A specified logon session does not exist. It may already have been terminated. [EMAIL PROTECTED] ~ $ net use z: '\\empress\oberon' /user:oberon Enter the password for 'oberon' to connect to 'empress': Enter the password for 'oberon' to connect to 'empress': System error 5 has occurred. Access is denied. The password is invalid for \\empress\oberon. [EMAIL PROTECTED] ~ $ net use z: '\\empress\oberon' /user:oberon Enter the password for 'oberon' to connect to 'empress': Enter the password for 'oberon' to connect to 'empress': System error 5 has occurred. Access is denied. The password is invalid for \\empress\oberon. [EMAIL PROTECTED] ~ $ net use z: '\\empress\oberon' /user:oberon 'password' System error 5 has occurred. Access is denied. [EMAIL PROTECTED] ~ $ Note that in the cases where I do not supply a password, the prompt that is presented times out with the error message in milliseconds. There is not nearly enough time for me to even hit a key. SSHD does appear to be performing the user switch correctly. I think that is the reason I show up in the Administrators group, and I can access my local files: [EMAIL PROTECTED] ~ $ id uid=1009(oberon) gid=513(None) groups=513(None),544(Administrators),545(Users) [EMAIL PROTECTED] ~ $ When the drive is already mounted from the XP desktop, the following command claims to work: [EMAIL PROTECTED] ~ $ net use z: Local namez: Remote name \\Empress\oberon Resource type Disk The command completed successfully. [EMAIL PROTECTED] ~ $ But the drive still doesn't appear, even after issuing mount commands: [EMAIL PROTECTED] ~ $ ls /cygdrive/ c [EMAIL PROTECTED] ~ $ ls /cygdrive/z/ ls: /cygdrive/z/: No such file or directory [EMAIL PROTECTED] ~ $ I will note that `net use' still reports the Z: drive is inaccessible after the previous command returns success: [EMAIL PROTECTED] ~ $ net use New connections will be remembered. Status Local RemoteNetwork - --- Unavailable Z:\\Empress\oberon Microsoft Windows Network The command completed successfully. [EMAIL PROTECTED] ~ $ Any more hints? Regards, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- Were it left for me to decide whether we should have a government without newspapers, or newspapers without a government, I should not hesitate a moment to prefer the latter. - Thomas Jefferson (appeared http://hotwired.lycos.com/special/lawsuit/ ) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
Re: SSHD user-switching under Cygwin/XP (was Re: Case insensitivity ad nauseum)
Derek Robert Price wrote: * Put your password into a file only readable by you, and use it with the Windows net use command during your .profile, to connect to the network share. It took me some time to figure out the syntax, but I've now tried various permutations of net use. I mostly am causing it to generate a lot of system errors: [EMAIL PROTECTED] ~ $ net use z: '\\empress\oberon' /user:oberon 'password' System error 5 has occurred. Access is denied. I didn't carefully read over this whole list of permutations, but at first glance, perhaps it's just the domain for oberon that's missing? e.g. net use z: \\empress\oberon /user:empress\oberon password -Nathan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I settled on a compromise for the nonce. I fixed the latest case insensitivity bug I knew of in 1.11.x and removed case insensitivity support from feature entirely. I've also added some tests of behavior involving heterogeneous combinations of case sensitive and case insensitive clients and servers to both branches though I've yet to get it set up for nightly testing (if anyone knows how to get Cygwin sshd to allow access to a mounted Samba share via its login shell, I could use some assistance). Since things look stable without case insensitivity support, I will probably remove support from stable too if any new bugs crop up. I'll probably roll a new release early next week. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/xP4ZLD1OTBfyMaQRAjN4AJ0dlk5zjIsae5xN6elNbLw9TKpl9ACg2KGD DIdO/rpFI8YlFAqUrOukha4= =q+r2 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
Is the problem that you're not sure how to get the network drive into the sshd filesystem root? Or that when you try to that it fails? If it were the latter, it would be reminiscent of a similar problem I had trying to get apache to serve files from a network drive on Windows XP. We found that the Local System Account that the apache service ran under by default did not have permissions to access the drive. If you were having trouble with it, you might look into what user the sshd process is running as, and whether that user has permission to access the drive. [EMAIL PROTECTED] wrote on 11/26/2003 02:25:14 PM: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I settled on a compromise for the nonce. I fixed the latest case insensitivity bug I knew of in 1.11.x and removed case insensitivity support from feature entirely. I've also added some tests of behavior involving heterogeneous combinations of case sensitive and case insensitive clients and servers to both branches though I've yet to get it set up for nightly testing (if anyone knows how to get Cygwin sshd to allow access to a mounted Samba share via its login shell, I could use some assistance). Since things look stable without case insensitivity support, I will probably remove support from stable too if any new bugs crop up. I'll probably roll a new release early next week. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/xP4ZLD1OTBfyMaQRAjN4AJ0dlk5zjIsae5xN6elNbLw9TKpl9ACg2KGD DIdO/rpFI8YlFAqUrOukha4= =q+r2 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
Jim writes: Oh great so now tags like 'CheckPoint' 'CHECKpoint' 'checkpoint' are all different? how useless is that? it's the IDEA of the word not the technical content of the word that should matter And don't the words Therapist and TheRapist convey totally different ideas? -Larry Jones If I was being raised in a better environment, I wouldn't do things like that. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
Chris Garrigues writes: Yes, Therapist and TheRapist do convey different ideas. However, in an actual English sentence, it's pretty damned clear what I'M GOING TO SEE MY THERAPIST THIS AFTERNOON. means even without mixed case to clue you in. Yes, case is less important when you have additional context like an entire sentence. The problem is that in most computer applications, we don't have any contxt to allow us to distinguish one thing from another, so case becomes more important. You may have noticed that I misspelled context in the previous sentence, or maybe not. In either event, I'm sure you had no trouble understanding what I meant. Are you now going to claim that English isn't spelling sensitive, either? -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Garrigues wrote: |From: [EMAIL PROTECTED] (Larry Jones) |Date: Thu, 6 Nov 2003 11:49:29 -0500 (EST) | |Chris Garrigues writes: | |Yes, Therapist and TheRapist do convey different ideas. However, in | |an | |actual English sentence, it's pretty damned clear what I'M GOING TO SEE | |MY | |THERAPIST THIS AFTERNOON. means even without mixed case to clue you in. | |Yes, case is less important when you have additional context like an |entire sentence. The problem is that in most computer applications, we |don't have any contxt to allow us to distinguish one thing from |another, so case becomes more important. You may have noticed that I |misspelled context in the previous sentence, or maybe not. In either |event, I'm sure you had no trouble understanding what I meant. Are you |now going to claim that English isn't spelling sensitive, either? | | |Careful now or you might end up making my point for me. | |The fact is that I didn't even notice that context was misspelled and I did |understand the sentence completely. Given that human beings care and do |understand things which are misspelled and which have differing case, it |should be obvious that from a human interaction perspective, it would be ideal |if the computer could also understand things which are misspelled and have |differing case. Understanding misspelled words is a difficult task and is |well beyond the scope of this email, but whether or not a computer language |or operating system or software package is case sensitive or not is a |design decision and IMHO, from the perspective of usability, Unix (and C) made |the wrong call. | |However, after over 30 years, this is not a decision which is going to be |changed, so I just grumble about it in email every few years and go on with |my life. | |Chris The salient point to me is that _sometimes_ case does make a difference and a case insensitive filesystem can take that choice away from the user in some circumstances. Now, a filesystem, or perhaps something akin to bash's tab-completion that would make sense of misspelled and miscased words, when it seemed best, and would still allow words with conflicting case when requested, might make sense, but I don't think CVS has any business fiddling around at this level. If a SysAdmin thinks it important that the CVS server look case insensitive, that admin can install the repository in question on a case insensitive file system. Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- I am not a dentist. I am not a dentist. I am not a dentist... ~ - Bart Simpson on chalkboard, _The Simpsons_ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/qoOWLD1OTBfyMaQRAgSsAJ4wlQ9G13dYXcYAEkFrZPfFXre1yQCgywrJ zpSIk/o0+cVPTuArzXZpCfo= =iEe8 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ingolf Steinbach wrote: |On Thursday 06 November 2003 06:24, Jim wrote: | |That's not really the point... how many times do you maintain ChangeLog, |CHangeLog, changeLog, changelog in the same directory? | | |On Solaris with SUNWspro installed: | |% ls /opt/SUNWspro/bin/?? |/opt/SUNWspro/bin/CC /opt/SUNWspro/bin/cb /opt/SUNWspro/bin/cc | |CC is the C++ compiler while cc is the C compiler. Looks like cc's big brother to me. :) Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- We shall have our follies without doubt. Some one or more of them will always be afloat. But ours will be the follies of enthusiasm, not of bigotry, not of Jesuitism. Bigotry is the disease of ignorance, of morbid minds; enthusiasm of the free and buoyant. Education and free discussion are the antidotes of both. We are destined to be a barrier against the return of ignorance and barbarism. - Thomas Jefferson to John Adams, 1816 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/qoR6LD1OTBfyMaQRAgYcAJ9OUPXk0WB0MmT+VEmd6bONw72rPQCeN1Tz JqiVbcRcW0pFaXlakzJNxtY= =1RRl -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
On Wed, Nov 05, 2003 at 09:24:06PM -0800, Jim wrote: I suppose someone could have abused the case sensitivity and used capital cases of file extensions as backups... 'main.c' backed by 'main.C' though this seems like a bad habit. Interesting choice of example :-) Doesn't the latter mean C++ on some systems? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Case insensitivity ad nauseum
While I'm finding this whole discussion fascinating, it's beginning to aggravate me that it is occurring on both info-cvs and bug-cvs. Could the discussion be limited to one list only, please? Thank you. -- Rick Genter Sr. Software Engineer Silverlink Communications mailto:[EMAIL PROTECTED] (781) 272-3080 x242 This e-mail, including attachments, may include confidential and/or proprietary information, and may only be used by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -Original Message- From: Eric Siegerman [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2003 12:40 PM To: [EMAIL PROTECTED] Subject: Re: Case insensitivity ad nauseum On Wed, Nov 05, 2003 at 09:24:06PM -0800, Jim wrote: I suppose someone could have abused the case sensitivity and used capital cases of file extensions as backups... 'main.c' backed by 'main.C' though this seems like a bad habit. Interesting choice of example :-) Doesn't the latter mean C++ on some systems? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
--- Forwarded mail from [EMAIL PROTECTED] Jim.Hyslop [EMAIL PROTECTED] WeLl mAdE ArguMent... No, not at all. For example, of the 111 items in my home directory right now, 17 of them use upper-case letters in a meaningful way. Common practice is to name some things on Unix in a mixture of cases, e.g. Makefile, Imakefile, ChangeLog. That's not really the point... how many times do you maintain ChangeLog, CHangeLog, changeLog, changelog in the same directory? or Makefile and makefile? or .BASHrc, .bashRC, .BashRc, .bashrc ? Is there even one example of where it's logical to have the same name with a different case in a directory? I have worked in a shop where most directories contained a makefile and a Makefile, and relied on the search order of the tools to choose the right one. The reason was because the product was a third-party source with its own makefiles, and we used the second makefile to interface our build system with theirs. It was a gunky arrangement, but it saved us from having to merge local changes into their makefiles after every code drop, and any changes we made to their makefiles were generic in nature and could be fed back to them. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rick Genter wrote: |While I'm finding this whole discussion fascinating, it's beginning to aggravate me that it is occurring on both info-cvs and bug-cvs. Could the discussion be limited to one list only, please? Thank you. I do that occasionally when I'm hoping for user and developer input on a problem. I think some people only read one list or the other. Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- Teacher is not a leper. Teacher is not a leper. Teacher is not a leper... ~ - Bart Simpson on chalkboard, _The Simpsons_ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/qpFYLD1OTBfyMaQRAg4pAJ4l1GCpgijajm7Gfh4TMF2mUMSnNACeP1tT ny2Hvd3FbUa13TPj97PMGgk= =ZxS6 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Case insensitivity ad nauseum
Rick Genter [mailto:[EMAIL PROTECTED] wrote: While I'm finding this whole discussion fascinating, it's beginning to aggravate me that it is occurring on both info-cvs and bug-cvs. Could the discussion be limited to one list only, please? Thank you. I've a better idea - why don't we call a truce and agree to disagree on the philosophy, and let Derek handle the situation as he sees best? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) Let's build software that works the way people expect. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Case insensitivity ad nauseum
Ingolf Steinbach [mailto:[EMAIL PROTECTED] wrote: On Solaris with SUNWspro installed: CC is the C++ compiler while cc is the C compiler. Thank you for supplying an example that supports my point. Using that convention, it is impossible for you to know which compiler is which, unless someone tells you or you refer to external documentation. Wouldn't it just be easier to distinguish the two programs by giving them names that are different and that *tell* you which one is which, such as gcc and g++? Just as in my earlier message I pointed out that jim and Jim are the same name, cc and CC are the same name, from a human point of view. Read them out loud. Both jim and Jim come out the same, don't they? We *speak* labels as much as we read them, and spoken language does not make case distinctions. I don't know about you, but when I read, I do not just see the shapes of the letter combinations, I *hear* the words associated with those combinations. Arcane labels such as cc and CC are spoken as see see, unless you would habitually say little see little see and uppercase see uppercase see. BTW, in response to the earlier comment (not made by you, IIRC) that my grade school teacher should have pointed out that only Jim is correct - that's not really important (I refer you to e.e. cummings, a.a. milne and a variety of other people who do not use capital letters in their names, by the way). Jim may be the correct way of spelling it, but if I leave a note for my wife and sign it jim she won't say Who the hell is jim? My husband's name is Jim. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) Let's build software that works the way people expect. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Case insensitivity ad nauseum
[ On Wednesday, November 5, 2003 at 10:11:45 (-0500), Jim.Hyslop wrote: ] Subject: RE: Case insensitivity ad nauseum Hi Jim! How are you! How are things at Leitch? :-) From the time we first learned to read, we have never considered the case of a word to be significant in determining the identity of an object being referred to. I think you're headed _WAY_ off track there. This really has nothing much to do with reading and human languages or anything like that. Case sensitivity is an important and useful feature in computer languages, including filesystem naming. Many of us consider those filesystems which cannot preserve case, but which accept input in random case, to be so utterly broken as to be undeserving of any attention whatsoever. They create a situation where the computer effectively considers the users to be too stupid or blind or whatever to be able to say what we mean accurately. Besides, there are lots of situations in plain old English where a capitalised word has at least different connotations, if not also a different meaning from its all lowercase companion. As you have probably gathered, my background is almost entirely Windows-based. In case-sensitive (i.e. Unix) systems, what is the generally accepted practise with respect to naming files: is it generally considered bad practise to have two files with the same name, that differ only by case, in the same directory? Nope -- indeed it is far more common than you might think to have files with names which differ only in the case of their letters. About the only thing in Unix history where the case of filename characters has been ignored in some way has been with make where it will try the file makefile and if it cannot find a file by that name then it will try the file Makefile, though in this case it is quite often used to advantage and files of both names will exist in a directory. My understanding is that the common practise on Unix is to use all lower-case names, to avoid potential confusion. Confusion has nothing to do with it -- it's all about SHOUTING! ;-) It also had to do with having a distinguishing feature that made Unix (and Multics) look better and smarter than all those ancient old mainframe systems which only used uppercase characters. Use of lowercase letters distinguised Unix from many stuffy/stodgy old systems, and ability to not only preserve case in file content and file names, but also to distinguish between names differing only in case, gave Unix (and Multics) a powerful new ability those older systems did not have. (and the reason for not capitalizing many filenames was that it is rather hard to touch type upper-case letters on a real Teletype ASR-33 -- those damn little round keys are hard enough to press on their own, one at a time, without also trying to press a shift key with your other hand at the same time too!) Let's build software that works the way people expect. I expect my software to honour and recognize case differences in filenames (and all other identifiers too!) -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
I was investigating case sensitivity, thinking that it was somehow necessary for the support of Windows clients, when it occurred to me that the _only_ value-added feature this provides is that Windows users don't need to specify the case of files and paths correctly in remote commands. We once had the minor problem that somehow files showed up twice (e.g. doing an update). It turned out that the case of the file itself didn't match the entry in the entries file. So cvs once reported the file from the entries file and then again while looking for unknown files. It behaved correctly, it just did the file twice. But that's something the local client needs to handle (I guess) and not the server. So I don't know if this has something to do with your actual work, I just thought I'd mention it. (Actually that was some months ago, I don't know if this is still the case. Can't test now). bye Fabi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
We once had the minor problem that somehow files showed up twice (e.g. doing an update). It turned out that the case of the file itself didn't match the entry in the entries file. So cvs once reported the file from the entries file and then again while looking for unknown files. It behaved correctly, it just did the file twice. But that's something the local client needs to handle (I guess) and not the server. So I don't know if this has something to do with your actual work, I just thought I'd mention it. Yes - if you use a poor editor it will not preserve the case of the filenames. FAT32, NTFS both preserve the case, even if it doesn't actually USE the case... It is entirely feasible to leave CVS case sensitive and make a note somewhere that the responsibility of preserving the case is on the user. Jim OOP is a frame of mind, not a language. The difference between a bug and a feature? A feature's documented. What? if I press the enter key the program crashes and makes the computer reboot? ... Yeah... it says right here - feature - quick reboot Everything changes, what you hear today is gone tomorrow, and yesterday might as well never have been. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
We once had the minor problem that somehow files showed up twice (e.g. doing an update). It turned out that the case of the file itself didn't match the entry in the entries file. So cvs once reported the file from the entries file and then again while looking for unknown files. It behaved correctly, it just did the file twice. But that's something the local client needs to handle (I guess) and not the server. So I don't know if this has something to do with your actual work, I just thought I'd mention it. Yes - if you use a poor editor it will not preserve the case of the filenames. FAT32, NTFS both preserve the case, even if it doesn't actually USE the case... It is entirely feasible to leave CVS case sensitive and make a note somewhere that the responsibility of preserving the case is on the user. The strange thing here is that cvs is inconsequent. It should report the file from the entries as missing and recreate it (though not possible on Windows) and further should report an unknown file in the directory. But what it did is really updating the file, so it could make the connection between the different cases partly. Either it's case sensitive or it's not. And that was with a local repository, so no client/server issues. bye Fabi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Case insensitivity ad nauseum
Greg A. Woods [mailto:[EMAIL PROTECTED] wrote: [ On Tuesday, November 4, 2003 at 13:57:25 (-0500), Derek Robert Price wrote: ] Subject: Case insensitivity ad nauseum So anyway, why _don't_ we remove the case-insensitivity support? I can only say it should never ever have been put in in the first place. First, Derek, let me thank you for all the work you have put in on this. It sounds like I'm going to be the sole dissenting voice here, at least so far. Let me explain my reasoning; it will be rather round-about, but please bear with me. It will (I hope) make sense in the end. Historically, computers have not had the processing power to be able to work the way humans expect the world to work, so humans have always had to bend to the limitations of the computer. While that may have been acceptable forty years ago, in this day and age when using desktop or laptop systems, it is not. Computers today are tools that should make the jobs easier for human beings. Computers should bend to the expectations of humans, not the other way around. From the time we first learned to read, we have never considered the case of a word to be significant in determining the identity of an object being referred to. My name is Jim. My name is also JIM. If you're talking about me, then it doesn't matter whether you spell my name Jim, JIM, or any of the other six variations involving case: the label that you apply to me is not case-sensitive. That's the way the world works... except in computer sciences. Well, I believe the time has come to rectify that. A file name is a label that a human applies to a particular entity called a file. As I said earlier, case distinction in labelling entities is irrelevant. Case-preserving, case-insensitive file systems are, in my opinion, the correct way to model the world. In this respect Bill Gates actually did something *right* with Windows (let's not go into the myriad ways he went wrong - that's a whole other troll^H^H^H^H^H rant). As you have probably gathered, my background is almost entirely Windows-based. In case-sensitive (i.e. Unix) systems, what is the generally accepted practise with respect to naming files: is it generally considered bad practise to have two files with the same name, that differ only by case, in the same directory? My understanding is that the common practise on Unix is to use all lower-case names, to avoid potential confusion. Sounds to me like this is a manually-operated (and therefore error-prone) convention imposed in order to have, effectively, a case-insensitive, case-preserving file naming system ;-) Let's build software that works the way people expect. On a case-insensitive, case-preserving file system such as Windows or (I believe) Mac OS, that means making the program smart enough to realize that cvs rlog myproject also means cvs rlog MyProject. If you put it in, you unfortunately won't get a lot of Windows users saying thank you for making it match the case, but if you leave it out you might get a lot of Windows users saying WTF? Why am I getting an error with 'cvs rlog myproject'? Whaddya mean it's case-sensitive?!? What a stupid program!! It won't be easy, and I'm sure the problem is rather complex, but I truly believe the end results *will* be worth the extra effort involved. -- Jim ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim.Hyslop wrote: |It sounds like I'm going to be the sole dissenting voice here, at least so |far. Let me explain my reasoning; it will be rather round-about, but please |bear with me. It will (I hope) make sense in the end. [. . . snip . . .] |It won't be easy, and I'm sure the problem is rather complex, but I truly |believe the end results *will* be worth the extra effort involved. Are you volunteering to maintain this code? I'm getting sick of it. :) Seriously, case-philosophies aside, we could remove the handling from CVS and anyone sharing your beliefs could still install a case-insensitive file system on a UNIX server and put their CVS repository there to get the behaviour you want. As it stands, Windows users will only get the behavior you prefer _sometimes_, since as long as the repository exists on a case sensitive file system, files with conflicting case can still exist in the repository. I don't think the overhead for such a small gain, the worth of which is completely dependant on personal case-philosophy, and which system administrators can configure according to their own personal case-philosophy, is worth it. Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- If virtuous, [the government] need not fear the fair operation of attack and defense. Nature has given to man no other means of sifting the truth, either in religion, law, or politics. - Thomas Jefferson to George Washington, 1792 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/qRiOLD1OTBfyMaQRAviXAJ9AQu6x5adpkNoSEy1HV2KMyVEDCgCfdQRu BLHCsIWwqyDf8j1yJNCxoz0= =+XnW -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
On Wed, Nov 05, 2003 at 10:11:45AM -0500, Jim.Hyslop wrote: It sounds like I'm going to be the sole dissenting voice here, at least so far. Let me explain my reasoning; it will be rather round-about, but please bear with me. It will (I hope) make sense in the end. snip A file name is a label that a human applies to a particular entity called a file. As I said earlier, case distinction in labelling entities is irrelevant. Case-preserving, case-insensitive file systems are, in my opinion, the correct way to model the world. In this respect Bill Gates actually did something *right* with Windows (let's not go into the myriad ways he went wrong - that's a whole other troll^H^H^H^H^H rant). The problem with mixing case-sensitivity in this way is that it's just about impossible to get right. The amount of work involved to do it completely (and correctly) is horrendous. If you want an example, look at the work the Samba team have to do to try and present a case-insensitive view of a case-sensitive file system. And then consider the whole gamut of different character sets and encodings out there. Some systems do not have a one-to-one mapping from upper to lower case and vice versa. If you want to do case-insensitivity properly, it needs to be done all the way down. Anything else is a grievous hack... As you have probably gathered, my background is almost entirely Windows-based. In case-sensitive (i.e. Unix) systems, what is the generally accepted practise with respect to naming files: is it generally considered bad practise to have two files with the same name, that differ only by case, in the same directory? My understanding is that the common practise on Unix is to use all lower-case names, to avoid potential confusion. Sounds to me like this is a manually-operated (and therefore error-prone) convention imposed in order to have, effectively, a case-insensitive, case-preserving file naming system ;-) No, not at all. For example, of the 111 items in my home directory right now, 17 of them use upper-case letters in a meaningful way. Common practice is to name some things on Unix in a mixture of cases, e.g. Makefile, Imakefile, ChangeLog. Let's build software that works the way people expect. On a case-insensitive, case-preserving file system such as Windows or (I believe) Mac OS, that means making the program smart enough to realize that cvs rlog myproject also means cvs rlog MyProject. If you put it in, you unfortunately won't get a lot of Windows users saying thank you for making it match the case, but if you leave it out you might get a lot of Windows users saying WTF? Why am I getting an error with 'cvs rlog myproject'? Whaddya mean it's case-sensitive?!? What a stupid program!! Another point I'd like to make: labels are case-sensitive already. Live with it. Most of the Mac/Windows people who will ever have to cope with cvs on their platform not being case-insensitive are going to be programmers _anyway_. And you sure as hell cannot go randomly mixing case in C/C++/Java source code! The only non-programmers I've ever seen using CVS on Windows were using a pretty GUI front-end which would hide all the details from them anyway and would get the case correct by default. It won't be easy, and I'm sure the problem is rather complex, but I truly believe the end results *will* be worth the extra effort involved. And I'd strongly recommend losing the current set of kludges that we have that only cause confusion. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? pgp0.pgp Description: PGP signature ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim wrote: | Yes - if you use a poor editor it will not preserve the case of the | |filenames. FAT32, NTFS both preserve the case, even if it doesn't actually |USE the case... It is entirely feasible to leave CVS case sensitive and |make a note somewhere that the responsibility of preserving the case is on |the user. The note that the client needs to preserve case is already in the client-server specification document (doc/cvs-client.texinfo). If the client is not preserving case in some instances, then it is a bug in the client. An editor should not be able to affect this since the CVS client uses the file name case in the CVS/Entries file and not the case passed in by the user or in the filesystem unless the file does not exist in CVS/Entries. Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- 115. (A)bort, (R)etry, (I)nfluence with large hammer -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/qRuJLD1OTBfyMaQRAvffAKDcSzjZZl6NPUlHi3Ee6KE0gewttQCfYmXm 31LlgW1AdtuMqN005bQvM+w= =Y6XV -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fabian Cenedese wrote: |The strange thing here is that cvs is inconsequent. It should report the |file from the entries as missing and recreate it (though not possible on |Windows) and further should report an unknown file in the directory. |But what it did is really updating the file, so it could make the connection |between the different cases partly. Either it's case sensitive or it's not. |And that was with a local repository, so no client/server issues. If I made this change, CVS clients would still treat the local workspace files in a case insensitive manner. Only the server wouldn't and the CVS client/server specification already requires the client to preserve the case of files it retrieved from the server and as far as I know the CVS client does this properly. Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- Thank GOD Microsoft doesn't build airplanes. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/qRwFLD1OTBfyMaQRAqh9AJwPpEt/WaH3zl5iXGQJ7LTNyklnFgCeKKyy Q3GdZMOWXg5LBKsXbNLQT5s= =hD51 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
Jim.Hyslop [EMAIL PROTECTED] wrote:
...
is it generally considered
bad practise to have two files with the same name, that differ only by case,
in the same directory?
Yes.
My understanding is that the common practise on Unix
is to use all lower-case names, to avoid potential confusion.
I've been using UNIX since the BSD 4.x days ('82). I've never heard
this before.
Sounds to me
like this is a manually-operated (and therefore error-prone) convention
imposed in order to have, effectively, a case-insensitive, case-preserving
file naming system ;-)
Bad conclusion.
Let's build software that works the way people expect. On a
case-insensitive, case-preserving file system such as Windows or (I believe)
Mac OS,
But not Mac OS X.
that means making the program smart enough to realize that cvs rlog
myproject also means cvs rlog MyProject. If you put it in, you
unfortunately won't get a lot of Windows users saying thank you for making
it match the case, but if you leave it out you might get a lot of Windows
users saying WTF? Why am I getting an error with 'cvs rlog myproject'?
Whaddya mean it's case-sensitive?!? What a stupid program!!
If Windows is case preserving and people use dual case in names, why
allow them to be sloppy and specify the single case name? The only
thing you are doing is supporting fuzzing thinking, IMO.
Kevin
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Case insensitivity ad nauseum
Donald Sharp [mailto:[EMAIL PROTECTED] wrote: It's not terribly uncommon to have both Makefile and makefile in some build trees I've seen( and they have a different meaning to make! ) on unix. I wouldn't want cvs to stop surporting the ability to track this at all! It's not unreasonable to have the same name with different cases, rare yes, but not unreasonable. Oh, don't get me wrong - I'm not suggesting that CVS drop case-sensitive support altogether. I realize that the case-sensitive nature of Unix will probably never change, partly due to legacy issues and partly due to the attitudes and philosophies of Unix users. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) Let's build software that works the way people expect. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Case insensitivity ad nauseum
Steve McIntyre [mailto:[EMAIL PROTECTED] wrote: Another point I'd like to make: labels are case-sensitive already. Live with it. I think you missed my main point: *why* should the user have to deal with it? Just because that's the way it works? Well then, let's *change* the way it works, so people don't have to deal with it. Make the computer deal with it. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) Let's build software that works the way people expect. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
On Wed, Nov 05, 2003 at 11:35:12AM -0500, Jim.Hyslop wrote: Steve McIntyre [mailto:[EMAIL PROTECTED] wrote: Another point I'd like to make: labels are case-sensitive already. Live with it. I think you missed my main point: *why* should the user have to deal with it? Just because that's the way it works? Well then, let's *change* the way it works, so people don't have to deal with it. Make the computer deal with it. No, I didn't. Labels in *lots* of systems other than CVS are case-sensitive and this will _not_ change any time soon, if ever. That was _my_ point here. People work with them all the time. I disagree with your fundamental premise that case-sensitivity is harder / less intuitive, FWIW. I'm very much with Derek on this point - if we can lose one of the harder to maintain parts of the CVS code base and make the system more consistent as a result, then *hell* yes. Do it! -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Can't keep my eyes from the circling sky, Tongue-tied twisted, Just an earth-bound misfit, I... pgp0.pgp Description: PGP signature ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Robert Price wrote: | Jim.Hyslop wrote: | | |It sounds like I'm going to be the sole dissenting voice here, at least so | |far. Let me explain my reasoning; it will be rather round-about, but please | |bear with me. It will (I hope) make sense in the end. | | | [. . . snip . . .] | | |It won't be easy, and I'm sure the problem is rather complex, but I truly | |believe the end results *will* be worth the extra effort involved. | | | Are you volunteering to maintain this code? I'm getting sick of it. :) | | Seriously, case-philosophies aside, we could remove the handling from | CVS and anyone sharing your beliefs could still install a | case-insensitive file system on a UNIX server and put their CVS | repository there to get the behaviour you want. | | As it stands, Windows users will only get the behavior you prefer | _sometimes_, since as long as the repository exists on a case sensitive | file system, files with conflicting case can still exist in the | repository. | | I don't think the overhead for such a small gain, the worth of which is | completely dependant on personal case-philosophy, and which system | administrators can configure according to their own personal | case-philosophy, is worth it. To phrase this in yet another way, I do not think it should be CVS's responsiblity to hide this feature of the server's file system, in the same way that UNIX and Mac OS X fail to attempt to make a mounted case-insensitive filesystem appear to be case-sensitive. This should not be CVS's responsibility. As far as file names and file systems are concerned, CVS should behave as an access mechanism and _ask the filesystem if the file exists_. If an administrator wants a CVS server that behaves as if its filesystem is case insensitive, then the administrator should install the server on a case insensitive filesystem. Jim, you had to learn to use correct case and punctuation for your English teacher, to extend your own metaphor. You may think jim, Jim, and JIM refer to the same thing, but some people will interpret them differently, especially if we bring context into the picture. I do not think asking CVS users on Windows to get the case correct (and mind you this is only for checkout and the r* commands) is much more complicated than this. They do already manage it for their passwords, after all. Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- It does me no injury for my neighbor to say there are twenty gods or no god. It neither picks my pocket nor breaks my leg. ~- Thomas Jefferson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/qTFPLD1OTBfyMaQRAsx+AJ99x1wKp1NKzWZykmXWdnLzynRnPwCgg9BD 5H2ZA62DGPMijzRUbq44JAA= =Waat -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Case insensitivity ad nauseum
Derek Robert Price [mailto:[EMAIL PROTECTED] wrote: Are you volunteering to maintain this code? I'm getting sick of it. :) Ah, well... gee, look at the time! ;-) I don't think the overhead for such a small gain, the worth of which is completely dependant on personal case-philosophy, and which system administrators can configure according to their own personal case-philosophy, is worth it. OK. You're more familiar with the complexities and issues. I've had my say on this. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) Let's build software that works the way people expect. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Case insensitivity ad nauseum
--- Forwarded mail from [EMAIL PROTECTED] Steve McIntyre [mailto:[EMAIL PROTECTED] wrote: Another point I'd like to make: labels are case-sensitive already. Live with it. I think you missed my main point: *why* should the user have to deal with it? Just because that's the way it works? Well then, let's *change* the way it works, so people don't have to deal with it. Make the computer deal with it. Having experienced the way it works both ways, I personally prefer the Unix way. (Unix was not my first OS, by the way.) The problem here is as much a matter of taste as anything else. Half the users want case-senstivity, the rest want case-insensitivity with case- preserving behavior. Because computing resources are shared, then half of the users are bound to be unhappy in a shop that requires interoperability between systems. There's no workable solution to the problem at the filesystem or OS level, so it falls onto the shop to set its own policy. I think that the proper solution is not to change the OS, but to simplify CVS. CVS should support case-sensitivity, but provide more hooks so that the shop can enforce its own naming policy. That way, pure Unix shops get what they want by default. Canned triggers can enforce policies such as no upper-case letters in a name or no two files in the same directory can have names that differ only by case. The triggers must apply at the points where they make the most sense. At present, such triggers can be invoked only at commit time. In my opinion, that is too late to be any good for enforcing naming conventions, because by that time there may have been significant work done that depends on the new file's name. (Consider, for example, the case where a C header file is refactored, and a fundamental data structure is moved to the new file. If local policy is to disallow nested #includes then many source files require modifications to pick up the new file. If two users add header files that differ only in case concurrently, then a significant amount of rework is needed to resolve the conflict. Although we could argue that this specific example is a project management problem, most of us have seen variations of the problem.) In my opinion, the cvs add command should be modified to invoke a trigger and then reserve the name in the repository. The cvs remove command should be modified to invoke a trigger that enforces removal policy (and cancels reservations if no versions have been committed to the file). --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
Jim.Hyslop writes: From the time we first learned to read, we have never considered the case of a word to be significant in determining the identity of an object being referred to. That simply is not true, there are times when case is significant. The words Polish and polish, for example. Likewise, Catholic and catholic. My name is Jim. My name is also JIM. If you're talking about me, then it doesn't matter whether you spell my name Jim, JIM, or any of the other six variations involving case: the label that you apply to me is not case-sensitive. You must not have had a very good grade-school English teacher; mine would have insisted that only Jim is correct. -Larry Jones Whatever it is, it's driving me crazy! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
Jim.Hyslop [EMAIL PROTECTED] WeLl mAdE ArguMent... No, not at all. For example, of the 111 items in my home directory right now, 17 of them use upper-case letters in a meaningful way. Common practice is to name some things on Unix in a mixture of cases, e.g. Makefile, Imakefile, ChangeLog. That's not really the point... how many times do you maintain ChangeLog, CHangeLog, changeLog, changelog in the same directory? or Makefile and makefile? or .BASHrc, .bashRC, .BashRc, .bashrc ? Is there even one example of where it's logical to have the same name with a different case in a directory? I suppose someone could have abused the case sensitivity and used capital cases of file extensions as backups... 'main.c' backed by 'main.C' though this seems like a bad habit. The arguments presented about the case insensitivity are rather valid... Another point I'd like to make: labels are case-sensitive already. Oh great so now tags like 'CheckPoint' 'CHECKpoint' 'checkpoint' are all different? how useless is that? it's the IDEA of the word not the technical content of the word that should matter Sorry for the bitter sarcasm.. I wish I had made such a valid argument for the windows client maintaining \r's and not adding additional ones whens storing \n's received from the server ... I mean the unix client has no problem maintaining when there are \r's in the files stored in the repository, both to and from with no arbitrary descisions to attach \r's to \n's received from the server - leading to \r\r\n sequences in files. I even tried to touch the repositories I had to strip out the \r's since it appears that they 'shouldn't' have been there in the first place, but gave up and grudgingly accepted to use the cygwin port (and therefore the cygwin dll's which change weekly) which don't have a problem maintaining the correct characters for a line ending. Anyhow sorry I'm digressing... Unfortunatly looks like both issues lead to dead ends. OOP is a frame of mind, not a language. The difference between a bug and a feature? A feature's documented. What? if I press the enter key the program crashes and makes the computer reboot? ... Yeah... it says right here - feature - quick reboot Everything changes, what you hear today is gone tomorrow, and yesterday might as well never have been. - Original Message - From: Steve McIntyre [EMAIL PROTECTED] To: Jim.Hyslop [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 7:33 AM Subject: Re: Case insensitivity ad nauseum ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
On Tue, 2003-11-04 at 13:57, Derek Robert Price wrote: So anyway, why _don't_ we remove the case-insensitivity support? It seems to me that it has been causing an awful lot of headaches without a very good reason for supporting it. So what if Windows users have to specify project case correctly during the initial checkout? They had to anyhow when conflicting cases existed in the repository. For what it's worth this sounds like an excellent idea to me. Yours, Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
[ On Tuesday, November 4, 2003 at 13:57:25 (-0500), Derek Robert Price wrote: ] Subject: Case insensitivity ad nauseum So anyway, why _don't_ we remove the case-insensitivity support? I can only say it should never ever have been put in in the first place. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
