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 <turnbull AT ecolan DOT sbs DOT ohio-state DOT edu>
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

- Raw text -