Subject: Re: one-letter paths To: sincon AT minsky DOT csata DOT it (Divisione SINCON) Date: Mon, 26 Apr 93 13:33:11 EDT From: Stephen Turnbull Cc: djgpp AT sun DOT soe DOT clarkson DOT edu (DJ's GPP mailing list) Mauro Condarelli (sincon AT minsky DOT csata DOT it) writes: > IMHO the problem with ports is to remain as close as possible to the > original code. > I tried to minimize the diffs from the standard FSF, so to be able to > upgrade easyly. > If it would be possible to merge the diffs in the original code that would > be, of course, different. I agree 100%. > Should i send to FSF (where ?) the diffs and apply for inclusion in the > standard distribution (how ?) ? > I could use a word of advice. I think the place to go is gnu AT prep DOT ai DOT mit DOT edu. The address should be in all CopyLefts or readmes or somewhere in the standard distribution of each piece of FSF software. I'm sure DJ has told you by now :-) > >never have either of those problems, but the wuarchive.wustl.edu > >graphics archive uses single letter directories to keep the size of > >the .gif directories down a little bit, and I could imagine a > >situation where you wanted emacs to look for its config files relative > >to the current directory. > as i said the only real clash i see (it may be i'm a little short sighted) > is ":.:" which is single char AND a useful path. No, the examples I gave *are* *real* clashes. I agree, you could get around it in various ways, but it's better to have one simple, easily recognized problem ("can't handle colons") than complicated ones ("can't handle single character relative paths in leap year in countries with even-numbered MS-DOS code pages"). Especially with something that "isn't a real clash" you're likely to forget why it *is* in fact a clash when someday you or (worse) someone else decides to do something that makes that convenient. > IMHO an environmnt variable could be more useful, if it proves impossible > to support both styles. No reason why the same code that supports the +compatiblity switch couldn't support the environment variable. The environment variable would affect all programs expecting that switch, however, whereas the +compatibility switch can be used case-by-case. > Anyway the real problem are the tons of programs which just do what > they please, without us having any way to interfere (and acting differently > from each other). Bang on---and exactly what the switch/environment variable approach is intended to address. In any case, many thanks for the groff port. -- Stephen Turnbull The Ohio State University, Department of Economics 410 Arps Hall, 1945 N. High St., Columbus, OH 43210-1172 USA Phone: (614) 292-0654 Fax: ...-3906 Email: turnbull DOT 1 AT osu DOT edu