[355] in SIPB bug reports

home help back first fref pref prev next nref lref last post

No Deal

daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Wed Mar 8 09:10:19 1989

From: amgreene@ATHENA.MIT.EDU
Date: Wed, 8 Mar 89 09:08:47 EST
To: wesommer@ATHENA.MIT.EDU
Cc: bjaspan@ATHENA.MIT.EDU, bug-sipb@ATHENA.MIT.EDU
In-Reply-To: Bill Sommerfeld's message of Wed, 8 Mar 89 00:27:13 EST <8903080527.AA00612@ra.mit.edu>

> I disagree; when running under UNIX, it should NEVER append '.tex' to
> a filename typed on a command line under ANY circumstances.

I guess this is just a difference in our perspectives on user interfaces.
I want to use the .tex suffix (or extension, or family name, or whatever)
to differentiate my TeX files; I'd just as rather not type it in more
than I have to (which means that TeX can assume anything it wants).
Should BASIC not assume .BAS, Pascal not assume .PAS, Lotus 123 not
assume .WKS, [fine, I'm showing my TurboDOS heritage and MS-DOS
contamination], etc.?

If foo exists, end of story.  If foo does not exist but foo.tex does,
isn't it a reasonable assumption that that's what the user meant?  If
neither foo nor foo.tex exist, does it make one bloody difference?

> This is not standardization; this is dragging the system down to the
> level of the lowest common denominator, and I assert (in my jaundiced
> view of the world) that dragging a system down to the level of MS-DOS
> makes it harder to use on Berkeley UNIX.

The only restriction this places on you is that you can't have multiple
suffices.  The only time that's ever burned me was when I did course-
related stuff, and I switched to hyphens, then dropped the punctuation 
altogether (805ps1.tex can only be one thing).  I don't see how this
is "dragging the system down to the level of MS-DOS."  You don't lose
anything -- including filenames that seem longer than your paper --
except the ability to call your files I.want.to.have.periods.in.my.filename
and I.want.to.screw.over.TeX and have distinct .dvi files.

You shouldn't be keeping .dvi files lying around anyway; they eat up
disk space and can be easily regenerated from the .tex sources.  If they
can't be, they shouldn't be writable.

> Moreover, the fact that the code has '.' hard-coded as the separator
> character is itself an indication of a lack of portability; both ITS
> and VM/CMS use ' ', not '.', as a separator character in filenames.

I know that there is TeX on CMS, and I assume that the situation has
been dealt with there.  But I'd call it CMS lossage that it uses the
eight-character space-separated fields, not TeX's lossage that it was
designed for a more universal interface.

> So, if I name two files "foo.bar.tex" and "foo.quux.tex", they'll both
> use a \jobname of "foo"?  THIS IS ALSO BROKEN.  At the very least, it
> should look up to the point of the _LAST_ period, not the _FIRST_
> period.

I personally find it a feature, as I've mentioned before.  

> Barry: the change probably goes someplace in
> /mit/sipbsrc/uus/{vs2,rtpc}/tex/Common-TeX/file.c; portions would have
> to live in both "more_name()" and also in its callers.  The code seems
> to be in a fairly stilted, twisted, and, pascal-esque style which
> makes it hard to read.

Maybe that's because it was written in web.

And, please, if you do make any changes, don't change TeX and LaTeX,
but call your version something else, so that those of us who agree
with the current official TeX standard and expect standard behaviour
don't get screwed by a local deviation.

> This is not "safe"; if I run TeX on two different files with related
> basenames simultaneously, they will be overwritten; this is an example
> of where hauling things down to the level of MS-DOS makes things
> _harder_ for me on UNIX.  [Actually, I would advise against using an
> alias; instead, set up a Makefile].

Point conceded.  Again, I don't see why one would need to use the
period as anything except a basename/suffix delimiter --- then again,
I've always been unimaginative.


- Rhu

home help back first fref pref prev next nref lref last post