DAN@IBM.COM.UUCP (04/01/87)
What do people do about the long names of many pieces of X on systems (like System V) that do not support long names? Presumably they shorten them. Does everybody use the same short name? How about a shell script to do the fixes in some standard way. Just getting them off the tar tape is a super pain as many of them fall on top of each other.
geoff@desint.UUCP (04/03/87)
In article <040187.111854.dan@ibm.com> DAN@IBM.COM ("Walter E. Daniels Jr.") writes: > What do people do about the long names of many pieces of X on > systems (like System V) that do not support long names? > Presumably they shorten them. Does everybody use the same short name? > How about a shell script to do the fixes in some standard way. > Just getting them off the tar tape is a super pain as many of them > fall on top of each other. Hear, hear! Even better, how about if MIT admits that some of us are stuck with Neanderthal systems, and renames every file to be TWELVE characters or shorter? (That leaves two so we can do SCCS or RCS). If X is going to be a standard, it needs to bend a bit to accomodate POSIX- and SVID-conforming systems. While we're at it, can we *please* get rid of the uppercase characters in file names? This is a major pain with no gain. For that matter, I'd also love to get the Pascal-itis out of the C bindings, but I suppose I'm too late on that. -- Geoff Kuenning geoff@ITcorp.com {hplabs,ihnp4}!trwrb!desint!geoff Founder, National Committee to Stamp Out C That Wants to Be Another Language :-)
jg@jumbo.UUCP (04/04/87)
In article <311@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >In article <040187.111854.dan@ibm.com> DAN@IBM.COM ("Walter E. Daniels Jr.") writes: >Hear, hear! Even better, how about if MIT admits that some of us are >stuck with Neanderthal systems, and renames every file to be TWELVE >characters or shorter? This has been done in V11; all file names will be 12 characters or less for systems in the beta and final release to cooperate with RCS and SCCS. Large amounts of effort have been going into making the code as portable as possible, and not only to various variants of Unix. >While we're at it, can we *please* get rid of the uppercase characters >in file names? This is a major pain with no gain. You are the first person to compain about this in recent memory. I find it easier to parse names of files if there is some way to tell where one word begins and ends. This is particularly important once you have abbreviated file names to live within 12 characters. For example, XChkMskEv.c I find easier to deal with than xchkmskev.c would be. Jim Gettys
martillo@bacchus.UUCP (04/05/87)
While I agree that mixed case names are easy to parse, some operating systems are mostly case insensitve on the command line. I think VMS, DOS, and PRIMOS force file name case either to upper or lower case. I guess people coming from one of these systems to Unix might have some problems with meaningful case in file names.
bzs@bu-cs.UUCP (04/05/87)
Yakim Martillo writes >While I agree that mixed case names are easy to parse, some operating >systems are mostly case insensitve on the command line. I think VMS, >DOS, and PRIMOS force file name case either to upper or lower case. I >guess people coming from one of these systems to Unix might have some >problems with meaningful case in file names. Yes, in fact almost all O/S's other than UNIX use single case or resist mixed case (TOPS-20.) This of course doesn't make it a good thing, it's more a throwback to 029 keypunches and SIXBIT/RAD50 bit-smashing schemes. The only "danger" is if you make them only unambiguous due to the case sensitivity (Makefile/makefile comes to mind) as they'll probably smash each other coming off a tape (or cause the tape utility to scream.) Other than that, as Jim Gettys pointed out, the mixed case contains useful information (which, as far as the software is concerned, should be harmlessly lost when moved to a case insensitive machine, unless of course strings within programs [eg] refer to these files and this isn't handled "properly", I suppose that's worth a thought.) Has the original plaintiff tried 'stty lcase' :-) -Barry Shein, Boston University
rlk@ATHENA.MIT.EDU.UUCP (04/05/87)
The other disadvantage of mixed-case names is that they are very hard to type. Robert^Z
mkhaw@teknowledge-vaxc.UUCP (04/05/87)
Mixed case filesnames could be a real headache on a Apollo system running
Domain/IX (Apollo's flavor of Unix). On the one hand, Unix is case sensitive;
on the other hand, Aegis (the underlying "native" OS) is case-insensitive.
How does Apollo deal with this? A Unix name like "FooBar" becomes an
Aegis name like ":foo:bar".
Ideally, this doesn't make a bit of a difference, but in practice, Domain/IX
sometimes :) does break and you have to drop into Aegis to fix things, and
Aegis commands have an odd habit of sometimes not being able to deal with
filenames containing ':'s.
By the way, similar considerations apply to Eunice running under VAX/VMS.
Uppercase characters in Eunice filenames get '$' prefixed (or is it suffixed?)
when seen from VMS, and VMS has a 14 char filename, 14 char filetype limit.
So, you're really talking about limiting filenames to 7 chars plus a '.'
plus N chars for the "filetype". Why would anyone try to port X to Eunice if
X ports to VMS? Who knows, but it's still a potential problem.
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303shannon@sun.UUCP (04/06/87)
In article <776@jumbo.dec.com>, jg@jumbo.dec.com (Jim Gettys) writes: > I find it easier to parse names of files if there is some way to tell where > one word begins and ends. This is particularly important once you have > abbreviated file names to live within 12 characters. For example, > XChkMskEv.c I find easier to deal with than xchkmskev.c would be. How about chk_msk_ev.c for the filename and x_chk_msk_ev() for the function name? I find it quite painful to visually parse a bunch of letters into words using only case change to separate the words. And I find it a real pain to type such names! The mixed case hack is a leftover from languages with restricted character sets. C has a reasonable word separator (underscore), why not use it? Bill Shannon
oster@lapis.berkeley.edu.UUCP (04/06/87)
In article <16197@sun.uucp> shannon@sun.uucp (Bill Shannon) writes: >How about chk_msk_ev.c for the filename and x_chk_msk_ev() for the >function name? I find it quite painful to visually parse a bunch >of letters into words using only case change to separate the words. On the contrary: The underscore as a word separator has its origin in systems with a limited character set: no upper and lower case, just upper case and underscore. I find it quite painful to read and write names using the underscore as separator. For me, ChkMskEv.c is much easier to read then chk_msk_ev.c. The extra length of the latter form also gets on my nerves. After all, these things are _names_ not _sentences_ (limited character set: here I mean switch to italic font style.) What we really need are systems powerful enough to put names into our personal canonical forms when we type them, and when the system shows them to us. Not only in our editors but also on our command lines and in our debuggers. A canonical form reader/printer would also solve the problem that the Lisp people have with the C style names of X.
geoff@desint.UUCP (04/07/87)
My word! I certainly didn't realize I was going to unleash such a storm of controversy. Jim Gettys writes: >You are the first person to compain about this in recent memory. This only proves that you are in a "sheltered*" environment. *I don't mean this in a negative sense. >I find it easier to parse names of files if there is some way to tell where >one word begins and ends. While it is true that visual parsing aids are nice, I have found that after a short learning curve, I have no trouble parsing things. On the other hand, I *type* the filenames a lot, and as somebody pointed out, shifting slows typing. For a really fast typist, it slows it a lot, because there is a synchronization required, which is much more difficult than simple sequencing. As quick evidence, here are six attempts at fast typing: nos is the time to all good men to come to the aid of the paryt now is the time for all good men to come to the aid of the party My best time was 7.5 seconds. Note that the second one is perfect. Now Is The Time For All Good Men To Come TO The Aid Of THe Party Now Is The Time For All Good Men TO Come To THe Aid Of The Partyy Now Is The Time For ALl Good Men To COme TO THe Aid Of THe Party Now Is The Time For All Good Men To Come To The Aid Of The APrety My best time was 11.0 seconds. Note that EVERY example contains at least one case where I didn't release the shift key quickly enough. Yakim Martillo writes: >I guess people coming from one of these systems to Unix might have some >problems with meaningful case in file names. This person (who is the original complainer) has been using UNIX exclusively and continuously for six years, and has noticed that UNIX uses monocase almost exclusively. It is radical only in that the single case is lower, not upper. True, there are exceptions; it is also true that many people are unhappy with things like mixed-case switches. The people who have problems with meaningful case in file names are the people who have been paying attention to the human-engineering literature for the past few years. :-) Barry Shein writes: >Has the original plaintiff tried 'stty lcase' :-) The original plaintiff is frequently used as a walking index to the UNIX documentation. :-) -- Geoff Kuenning geoff@ITcorp.com {hplabs,ihnp4}!trwrb!desint!geoff
bob@osu-eddie.UUCP (04/07/87)
In article <8704050609.AA00698@4-035-9> rlk@ATHENA.MIT.EDU (Robert L. Krawitz) writes: >The other disadvantage of mixed-case names is that they are very hard >to type. So use a shell with a command/filename completer, like TWENEX's escape key. Just about any `XInCredibly-Ugly$GobbleDy_Gook.c' becomes easy to handle, and you preserve the usefulness of the MixedCase name when scanning a sorted listing of your directory. SysV simply requires you to keep your XUgliNess briefer, but it can still be at least as ugly and nearly as informative. -- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@ohio-state.{arpa,csnet} or ...!cb{osgd,att}!osu-eddie!bob (614)292-7348 (office) or -0915 (operators) or -7325 (answering machine)
shannon@sun.UUCP (04/08/87)
In article <3059@jade.BERKELEY.EDU>, oster@lapis.berkeley.edu (David Phillip Oster) writes: > The underscore as a word separator has its origin in systems with a > limited character set: no upper and lower case, just upper case and > underscore. Got any examples? All the systems I know of that were stuck with upper case only are from the days when the ASCII character set didn't have an underscore, it had a backarrow instead. People usually used $ in those days to separate words. > I find it quite painful to read and write names using the underscore as > separator. For me, ChkMskEv.c is much easier to read then chk_msk_ev.c. Truly warped! :-) I'd love to take a poll, but I doubt it would do any good. I suspect a lot of it is just what you are used to, and I'm used to my words being separated by white space, and _ is a close approximation to white space. > The extra length of the latter form also gets on my nerves. After all, > these things are _names_ not _sentences_ I agree about the length of names. I really hate variable or subroutine names that have a little story in them, like convert_widget_to_extra_large_gadget (or ConvertWidgetToExtraLargeGadget to you). All of this has very little to do with X, so let's get off this subject or find some other newsgroup to move it to (comp.lang.style???). Bill
geoff@desint.UUCP (04/08/87)
In article <3059@jade.BERKELEY.EDU> oster@lapis.berkeley.edu (David Phillip Oster) writes: > On the contrary: > The underscore as a word separator has its origin in systems with a > limited character set: no upper and lower case, just upper case and > underscore. "On the contrary" yourself; you should research your history a bit more carefully. The history of computing shows a long effort, starting in the late fifties and ending in the mid-seventies, to develop good techniques for naming variables. "Special" characters were introduced fairly early in this sequence; the first I am aware of is Cobol's hyphen. The underscore was eventually chosen because most people find it to be visually very close to the blank. And, as you have probably noticed, the blank is what natural languages use, and what people are best at parsing. PerhapsYouHaven'tNoticedExactlyHowHardItReallyIsToParseASentenceWhenThe WordsAreOnlySeparatedByCapitals? Notice_how_much_easier_it_is_to_read_this_sentence_with_the_underscores which_are_very_similar_to_blanks. [QED :-] -- Geoff Kuenning geoff@ITcorp.com {hplabs,ihnp4}!trwrb!desint!geoff
rusty@weyl.Berkeley.EDU.UUCP (04/08/87)
In article <16197@sun.uucp> shannon@sun.uucp (Bill Shannon) writes: > >How about chk_msk_ev.c for the filename and x_chk_msk_ev() for the >function name? I find it quite painful to visually parse a bunch >of letters into words using only case change to separate the words. >And I find it a real pain to type such names! Here here! A space is much easier for my brain/eyes to parse as a separater than mixed case. This also solves the problem of systems that map mixed case into all lower/upper-case; on the other hand it uses up valuable space for those systems that allow a limited number of chars for identifiers or file names. -------------------------------------- rusty c. wright rusty@weyl.berkeley.edu ucbvax!weyl!rusty
geoff@desint.UUCP (04/10/87)
In article <3416@osu-eddie.UUCP> bob@osu-eddie.UUCP (Bob Sutterfield) writes: > So use a shell with a command/filename completer, like TWENEX's escape > key. Sounds great. Please send a public-domain shell with filename completion via the most expedient method possible. Failing that, let's stick to ways to deal with the world as it is *today*. -- Geoff Kuenning geoff@ITcorp.com {hplabs,ihnp4}!trwrb!desint!geoff
paul@osu-eddie.UUCP (04/11/87)
In article <319@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >PerhapsYouHaven'tNoticedExactlyHowHardItReallyIsToParseASentenceWhenThe >WordsAreOnlySeparatedByCapitals? > >Notice_how_much_easier_it_is_to_read_this_sentence_with_the_underscores >which_are_very_similar_to_blanks. > >[QED :-] > Geoff Kuenning geoff@ITcorp.com {hplabs,ihnp4}!trwrb!desint!geoff ActuallyIFoundItJustAsEasyToReadTheSeperatedByCapitalsVersionAsTheUnderscores Version Really. The format of this comment is 8-), but the semantics are not. What it REALLY gets down to is what you are use to reading. I think that you may be supprised to find out just how good humans are at parsing aritrary things. Just how do you think you can tell where the word seperators are in the spoken language of a fluent (or for that matter, not fluent), rapid speaker??? -- Paul Placeway -=- -- Paul Placeway Department of Computer and Information Science SNail: The Ohio State University 2036 Neil Ave. Columbus OH USA 43210-1277 ARPA: paul@ohio-state.{arpa,csnet} UUCP: ...!cb{osgd,att}!osu-eddie!paul