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

Re: [augeas-devel] aug_lens_get



On Wed, 2009-03-25 at 17:25 +0100, Jakub Hrozek wrote:
> Attached is a new iteration of the patch. It fixes the issue of reusing
> the lens, puts the text into /text/$name, errors
> into /augeas/text/$name/errors and fixes the coding style errors.

Cool .. thanks, this looks very good now. I would like to hold off on
committing this until you have the aug_lens_put piece, too.

> I left the code that adds the trailing newline if it's not there for now
> - from the transform_load() code I got the impression that requiring a
> trailing newline is kinda bad practice in the lens file, so it's not
> something the user should take care of (i.e. the caller should not be
> working around the lens file)..but if it's more like a requirement of
> augeas (or rather the lens language) that the input string must conform
> to, it probably is something the caller of aug_lens_get() should take
> care of and I will respin the patch with this code out.

This newline business is pretty specific to processing whole files.
Almost all the lenses that process a whole file have the form l*, where
l handles one part of the file (e.g. one line for /etc/hosts or one
section in an INI-file) and they all expect that the part they deal with
end with a newline, even though the program reading the file is
perfectly capable of handling files that do not end with a newline.

The reason that such a lens l is not written in a way that makes the
last newline in a file optional is simply that writing such a lens is
much harder than one that always expects the trailing newline.

Since transform_load knows that it handles a complete file, and since
any config file I know of is valid if it _does_ have a trailing newline,
there's no harm in appending a trailing newline.

The situation for aug_lens_get is a little different, in that we have no
idea whether the lens is meant to process a whole file, or simply a
small fragment of a file; as an example, the user might try to parse a
fragment from /etc/sudoers, say 'env_keep = "COLORS DISPLAY HOSTNAME"' -
that's not a complete line, and the lens to parse just that bit
(Sudoers.parameter) will not be able to process the above string if you
append a '\n'.

So the long and short of this: aug_lens_get should not automatically
append a '\n' - in the future, we might add code that looks at the lens
to determine if it requires a trailing '\n' and add the newline
automatically only in that case; but in general, assuming that strings
must end with a newline is not correct.

David




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