lout-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wishes for next Lout


From: basile . starynkevitch
Subject: Re: wishes for next Lout
Date: Wed, 17 Jan 1996 17:23:11 +0100

>>>>> "Ian" == Ian Jackson <address@hidden> writes:

    Ian> T. Kurt Bond writes ("Re: wishes for next Lout"):
    >> I wish that people would pause for a bit before deciding that
    >> documents should *not* be able to contain arbitrary programs !
    >> 
    >> Have you ever tried to keep in synch the hundreds of ``here's
    >> some program input, what is the program output?'' examples one
    >> might have in a piece of documentation, a tech report, etc.?
    >> After all, I'm writing the document, I know I can be trusted,
    >> so why not integrate my document formatter with my other tools
    >> and automatically generate them?

    Ian> This then is not a document but a collection of test programs
    Ian> which must be run and have their output collected.


No. It is a user manual! This is precisely the kind of stuff where I
want to use Lout for!

    Ian> Most documents do not contain collections of test programs;
    Ian> users should not be led to believe that turning documents
    Ian> into programs is a good idea.

There aren't with Lout; the Lout @Filter capability is in practice
only usable by knowledgable Lout style writers (ie Lout
experts). These are definitely not Lout casual users! A Lout filter is
always part of a Lout package (ie style).

    Ian> It's the very idea that documents ought to be Turing-powerful
    Ian> that has got us into this mess in the first place.

I don't think that Lout is turing powerful. It is just capable of
invoking a definite filter program. This filter is not arbitrary! And
I disagree with Ian, thinking on the opposite that full (and easy)
programmability is necessary in document formatting. I would even want
even more programmability in Lout style files. Perhaps it could be
disabled in Lout document files. By the way, TeX and DSSSL are both
programmable -and perhaps writing Fibionnaci is easier in them than in
Lout. I'm missing elementary data processing (ie sorting, integer
arithmetic, small list processing) in Lout. Perhaps having a different
language for styles (actually formatting programs) and documents is
the way to go (in DSSSL the document are in SGML, while the formatting
styles are in a dialect of Scheme). And postscript itself is a
programming language!

    >> Of course, other people may write documents that do injury,
    >> either maliciously or stupidly, but shouldn't you be more
    >> careful with other people's documents in the first place?

    Ian> *NO*.  In order to read a document properly I need to be able
    Ian> to format it, and this should *not* require me to trust the
    Ian> originator.

You still will need any specific Lout styles. These may contains
@Filter-s -that I consider part of them. The fact that styles invoke a
knowledgable -not arbitrary- program is in my opinion an
implementation detail. I agree that lout style implementers (these are
Lout experts, not casuals users) should be aware of security issues.

    >> In most modern (and not-so-modern) operating systems you can
    >> easily isolate one program from all other running programs and
    >> from inappropriate areas of the file systems, so do that before
    >> formatting someone else's documents and be safe.  (Sure, it
    >> helps if the language or document processor has features that
    >> assist in this, but it's not necessary: our other tools and
    >> help.)

    Ian> Right, how do I do this on a multi-user Unix system of which
    Ian> I'm not the sysadmin ?  On a single-user DOS or Windows box ?

Changing the path should be enough. Perhaps the @Filter primitive
should either have a full pathname (ie /usr/local/bin/c2lout instead
of c2lout). 

    >> Note that *anything* with active documents will have these
    >> problems, and I expect them to increase, but they have been
    >> around since the first time someone figured out that if they
    >> put the correct escape codes in a file they sent someone, they
    >> could cause that person's terminal, editor, command line, etc.,
    >> to misbehave.

I (Basile) fully agree with this comment by T. Kurt Bond.

    Ian> Only because the receiving program had a bug that made it
    Ian> interpret those control codes.  Noone was claiming then that
    Ian> it was a feature.

    >> As for the Word virus, Microsoft could have easily prevented
    >> that by having Word ask the user before executing macros in
    >> documents on startup, with an idot-box warning about security
    >> if they deemed necssary.

    Ian> Even if this were true, the logical equivalent for Lout is a
    Ian> command-line option to disable this kind of thing.  The
    Ian> option should default to off, just like the dialogue box.

I suggest that the default option would be set in the Lout building
Makefile. Lout installer could change it at will. And portability (ie
in Makefiles invoking lout for document formatting) would be preserved
by always expliciting the enable/disable at lout invocation.



-- 

----------------------------------------------------------------------
Basile STARYNKEVITCH   ----  Commissariat a l Energie Atomique (civil)
DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France
fax: (33) 1- 69.08.85.68; phone: (33) 1- 69.08.40.66; homephone: (33) 1- 
46.65.45.53
email: address@hidden (redirected to address@hidden);  
I speak french (natively), english, russian. Je parle francais, anglais, russe.
----------------------------------------------------------------------

N.B. Any opinions expressed here are solely mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

Please cite a **small pertinent part** of my mail in all answers
Veuillez citer une **petite partie pertinente** de mon courrier dans vos 
reponses


reply via email to

[Prev in Thread] Current Thread [Next in Thread]