> [...] 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: [EMAIL PROTECTED] Hey, I'm magically put in foo. [EMAIL PROTECTED] 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 "[EMAIL PROTECTED]", its content goes to foo. As you can see, delimiters have an advanced syntactic meaning: speaking in regexp, "[EMAIL PROTECTED](.*\)$" 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 _______________________________________________ gnu-system-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-system-discuss
