Re: Kitten

[Soeren D. Schulze]

>    [...] you run into a couple of problems that I am going to explain
>    here...
> 
> Soeren, you haven't explained the problems (unless it is hidden in
> your message) that you ran into.  Could you list the questions that
> you are having problems with?

>From implementation perspective, it is just one problem: what to do when
delimiters are removed unexpectedly.  But from user's perspective, there
may be different scenarios where this may occur:

1. intuitive removal or just user fault
2. file truncation
(There might be more.)

>    The term "delimiter" is a bit confusing, however, because it does
>    not indicate the end of a file but its beginning.
> 
> There is nothing confusing with the word delimiter in this context, it
> indicates not only the start of the next section, but it also
> indicates the end of the previous section.

I would consider newline a typical delimiter and it does not come before
the first line but after the last.  Here, the delimiter comes before the
first inserted file but not after the last one.  But if you are not
confused, it is probably OK.

>    What will happen if someone just removes a delimiter from the file
>    content?
> 
> Then we write the content to the previous file, if no such file exists
> (i.e. we remove a delimiter on line 0), then we write to the following
> file.  If neither exists, we write it to the translated file.

Well, what should happen when user writes data before the first
delimiter is a different discussion.  My idea is that this data is saved
in RAM unless the user specifies a "head file", on command line, which
the data is written in.  The drawback at your idea is that when you open
the file for reading again, you will see the delimiter again, which is
different from how you edited it.

But I was imagining yet a different scenario: it is no problem when the
user just removes a delimiter somewhere in order append data to a file,
as long as he/she finally does write it back afterwards and the file is
syntactically correct again.  An intelligent implementation will not get
confused.

On the other hand, it *is* a problem when the user has really removed
the delimiter and does not put it back some bytes after but maybe writes
the delimiter of the file that comes after the one whose delimiter has
been removed.

1. If we assume that the delimiter contains the name of the file that
   it precedes (as I did in my initial posting) but remains on the
   initial file order (no syntactically sensitive delimiters), it will
   not recognize the delimiter as a delimiter and write everything to
   the previous file, which equals to complete confusion.
2. If the delimiter does not contain the file name, the file order will
   get confused; kitten will still notice that one delimiter is missing.
   This is roughly how it works in working branch of kitten (although
   some scenarios, including this, are not respected yet).
3. Only syntactically sensitive delimiters will see what the user tries
   to do.  I think this will also be the only way to provide a clean
   implementation that handles scenarios like inter-editing states,
   where the delimiter is removed temporarily, in all cases without
   dangerous assumptions or ugly caching.

>    Remaining on the strict definition above how it should work, you
>    cannot solve this.
> 
> What strict definition?

that every file is preceded by a delimiter and the files are kept in
order

>    Consider a tool written in ANSI C that manipulates a file in a way
>    that includes cutting some bytes at the end.  Unless these bytes
>    contain a delimiter, everything seems all right.  But the usual way
>    how to do this in ANSI C is to read the content of the file and
>    then truncate it completely.  Obviously, we removed all the
>    delimiters that way and kitten will get *really* confused.
> 
> You mean that your current version gets confused, right?

No, it is more than an implementation issue and related to the drawback
of your proposal above how it should work when delimiters are removed.

You can easily tell the kitten implementation that it should consider
all the files empty when the translated file is empty, but when you open
it for reading, the delimiters will appear.  In my opinion, the file
should just look like you edited it when you open it again and the
conkittenated files have not been touched but anybody else.

>    1. One might define that all the tailing empty files in the
>       conkittenation are not listed.
> 
> Ugly.

It is.  But this way, the file would look like you edited it when having
a look at it.

>    2. A much more enhanced approach is to make the delimiters
>       "sensitive": by changing the delimiter content, you can choose a
>       file to join the conkittenation.
> 
> I guess that this is what my rules above are, but with a very
> confusing name and you didn't describe how this really works.

You might start kitten with no files.  Then you fill up the (empty)
translated file with this:

address@hidden
Hey, I'm magically put in foo.
address@hidden
me in bar

The files foo and bar are opened and truncated.  Then, kitten writes the
desired content to them.  You can savely remove a delimiter: if you
remove "address@hidden", its content goes to foo.

As you can see, delimiters have an advanced syntactic meaning: speaking
in regexp, "address@hidden(.*\)$" is attempted to be applied to each line to be
inserted to check whether it contains a delimiter.  If yes, the
following content is put to the file whose name the regexp's \1 has.

>       Obviously, this is a security issue: by making one file writable
>       to somebody, you make *every* file that you can control
>       writable.
> 
> Just check the permission on each file before writting any data back,
> and if one or more files can't be written to, spit out ENOPERM.

Yes, it is an implementation issue, but I am not sure if I am familiar
enough with the Hurd to do this.  But I will try when I have come so
far.

> I note that you haven't noted the scenarios that Wolfgang wrote about
> in his mail (May 12th, 2004, subject: Write support for composed
> configuration files).  You should read that, if you haven't already
> done so.  If you want I can forward it again to the list...

Mailman search had not mentioned this posting when I had searched for
this issue days ago, but Google managed to find it by name on the first
hit.

It looks like he really had similar ideas independently and the
discussion stopped where my initial posting started, although he more
specifically pondered about how to realize it in the package management
translater.

Referring to one further point of that discussion: a "patching"
translator for editing global read-only configuration files would of
course be one way to solve it, but well-designed formats should allow
you to override settings from ealier lines if you want to change them.
Moreover, you always have the freedom to copy global configuration files
to your home directory and edit them.  If the global copy changes, there
is the merge command that you can merge changes with after figuring out
what the global changes do.  Nevertheless, it is an interesting idea,
even if not used here.

Of course, next generation's kitten would have the option to figure out
where the changes should belong automatically, but let me first
implement the "generic" way.  I think that even if such an intelligent
kitten was only as hard to implement as the delimiter/mark-based kitten,
the latter would be more useful if there was only one available.


Sören