gnulib-tool-py
[Top][All Lists]
Advanced

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

Re: [gnulib-tool-py] The root of the problem


From: Bruno Haible
Subject: Re: [gnulib-tool-py] The root of the problem
Date: Tue, 26 Jun 2012 23:37:43 +0200
User-agent: KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; )

Hi Dmitriy,

> > '^Description:\n(.*?)\n\n' expects to find a blank line.
> So you mean that from
> '''Description:\nSearch for an exact or abbreviated match of a string in an
> array of strings.\n\n'''
> we shall get
> '''Search for an exact or abbreviated match of a string in an array of
> strings.\n'''?

No, we shall get
'''Search for an exact or abbreviated match of a string in an array of 
strings.\n\n'''

because that is what func_get_description will produce.

=============================================================================
$ ./gnulib-tool --extract-description argmatch
Search for an exact or abbreviated match of a string in an array of strings.

=============================================================================

The output reproduces the same newlines as were found in modules/argmatch.

func_get_description uses the sed command
  sed -n -e "/^Description$sed_extract_prog"
and see the comments in front of sed_extract_prog:

  # A field starts with a line that contains a keyword, such as 'Description',
  # followed by a colon and optional whitespace. All following lines, up to
  # the next field (or end of file if there is none) form the contents of the
  # field.
  # An absent field is equivalent to a field with empty contents.

I don't want to have differences between the old and the new gnulib-tool
on this point. Module description files should be interpreted in the
exact same way by the new gnulib-tool.

Bruno




reply via email to

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