Re: What is xreadline?

[Reuben Thomas]

On Tue, 2 Jul 2024 at 00:46, Gary V. Vaughan  wrote:

>
>
> On Jul 1, 2024, at 12:46 PM, Reuben Thomas  wrote:
>
> readtokens.c has a comment saying "This almost supersedes xreadline
> stuff", but I can't find out what xreadline is.
>
> --
> https://rrt.sc3d.org
>
>
> IIUC it’s the xreadline.c from gnupg.
>

Aha! Thanks. I see that is basically 'readline'. So perhaps this comment
should be removed, as probably it's simpler to use 'readline', which is in
any case now a standard GNU libc function, rather than "abuse" readtokens
for this purpose.

-- 
https://rrt.sc3d.org

lib/uniname/gen-uninames.lisp: adjust clisp shebang?

[Simon Josefsson via Gnulib discussion list]

Hi!  The Debian gnulib package carry this patch:

https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/patches/02-shebang.patch?ref_type=heads

Should we apply a patch like the one below to gnulib?

/Simon
From e0c2029772b3789ab77884705cea7cb181708df7 Mon Sep 17 00:00:00 2001
From: Daniel Baumann 
Date: Tue, 2 Jul 2024 10:51:50 +0200
Subject: [PATCH] lib/uniname/gen-uninames.lisp: Use #!/usr/bin/clisp.

Signed-off-by: Simon Josefsson 
---
 ChangeLog | 4 
 lib/uniname/gen-uninames.lisp | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index abdba4716b..c63827fa64 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2019-10-08  Daniel Baumann  
+
+	* lib/uniname/gen-uninames.lisp: Use #!/usr/bin/clisp.
+
 2024-07-01  Bruno Haible  
 
 	Avoid some possibly wrong configure test results.
diff --git a/lib/uniname/gen-uninames.lisp b/lib/uniname/gen-uninames.lisp
index 1b0c60cf04..15d76019c6 100755
--- a/lib/uniname/gen-uninames.lisp
+++ b/lib/uniname/gen-uninames.lisp
@@ -1,4 +1,4 @@
-#!/usr/local/bin/clisp -C
+#!/usr/bin/clisp -C
 
 ;;; Creation of gnulib's uninames.h from the UnicodeData.txt table.
 
-- 
2.45.2



signature.asc
Description: PGP signature

Re: lib/uniname/gen-uninames.lisp: adjust clisp shebang?

[Bruno Haible]

Hi Simon,

> Should we apply a patch like the one below to gnulib?

The existing code follows the recommendation from the CLISP documentation
https://clisp.sourceforge.io/impnotes.html#quickstart-unix
  "The recommended path is /usr/local/bin/clisp, and if CLISP is actually
   installed elsewhere, making /usr/local/bin/clisp be a symbolic link to
   the real CLISP."

However, that documentation is outdated, focusing on platforms that are
less relevant today.

Debian's patch, to hardcode /usr/bin/clisp, is not good either, since
it doesn't work on Guix, nor Solaris, nor distros which don't package CLISP.
(Who is surprised that patches from Debian are Debian-specific?)

The solution is to use /usr/bin/env for a PATH lookup. So that it works
on Guix as well. Unfortunately, that requires using a non-POSIX option,
in order to avoid an error

  $ lib/uniname/gen-uninames.lisp UnicodeData.txt NameAliases.txt uninames.h
  /usr/bin/env: ‘clisp -C’: No such file or directory
  /usr/bin/env: use -[v]S to pass options in shebang lines


2024-07-02  Bruno Haible  

uniname/uniname: Modernize gen-uninames.lisp.
Reported by Simon Josefsson in
.
* lib/uniname/gen-uninames.lisp: Swap second and third parameter. Look
up clisp in $PATH.
* lib/gen-uni-tables.c: Update invocation.

diff --git a/lib/uniname/gen-uninames.lisp b/lib/uniname/gen-uninames.lisp
index 1b0c60cf04..30191f2e8e 100755
--- a/lib/uniname/gen-uninames.lisp
+++ b/lib/uniname/gen-uninames.lisp
@@ -1,6 +1,7 @@
-#!/usr/local/bin/clisp -C
+#!/usr/bin/env -S clisp -C
 
-;;; Creation of gnulib's uninames.h from the UnicodeData.txt table.
+;;; Creation of gnulib's uninames.h from the UnicodeData.txt and 
NameAliases.txt
+;;; tables.
 
 ;;; Copyright (C) 2000-2024 Free Software Foundation, Inc.
 ;;; Written by Bruno Haible , 2000-12-28.
@@ -48,8 +49,8 @@
   length; number of words
 )
 
-(defun main (inputfile outputfile aliasfile)
-  (declare (type string inputfile outputfile aliasfile))
+(defun main (inputfile aliasfile outputfile)
+  (declare (type string inputfile aliasfile outputfile))
   #+UNICODE (setq *default-file-encoding* charset:utf-8)
   (let ((all-chars '())
 (all-chars-hashed (make-hash-table :test #'equal))
diff --git a/lib/gen-uni-tables.c b/lib/gen-uni-tables.c
index 3ebcd833ff..b4f16da560 100644
--- a/lib/gen-uni-tables.c
+++ b/lib/gen-uni-tables.c
@@ -12075,8 +12075,8 @@ main (int argc, char * argv[])
  *   && diff uniwbrk/wbrkprop_org.txt uniwbrk/wbrkprop.txt  \\
  *   && clisp -C uniname/gen-uninames.lisp  \\
  *
/media/nas/bruno/www-archive/software/i18n/unicode/ftp.unicode.org/ArchiveVersions/15.1.0/ucd/UnicodeData.txt
 \\
- *uniname/uninames.h\\
  *
/media/nas/bruno/www-archive/software/i18n/unicode/ftp.unicode.org/ArchiveVersions/15.1.0/ucd/NameAliases.txt
 \\
+ *uniname/uninames.h\\
  *   && { sed -e 's/^/# /' -e 's/ $//' < 
/media/nas/bruno/www-archive/software/i18n/unicode/ftp.unicode.org/ArchiveVersions/license.txt;
 \\
  *echo; \\
  *cat 
/media/nas/bruno/www-archive/software/i18n/unicode/ftp.unicode.org/ArchiveVersions/15.1.0/ucd/NameAliases.txt;
 } \\

Re: lib/uniname/gen-uninames.lisp: adjust clisp shebang?

[Simon Josefsson via Gnulib discussion list]

Bruno Haible  writes:

> Hi Simon,
>
>> Should we apply a patch like the one below to gnulib?
>
> The existing code follows the recommendation from the CLISP documentation
> https://clisp.sourceforge.io/impnotes.html#quickstart-unix
>   "The recommended path is /usr/local/bin/clisp, and if CLISP is actually
>installed elsewhere, making /usr/local/bin/clisp be a symbolic link to
>the real CLISP."
>
> However, that documentation is outdated, focusing on platforms that are
> less relevant today.
>
> Debian's patch, to hardcode /usr/bin/clisp, is not good either, since
> it doesn't work on Guix, nor Solaris, nor distros which don't package CLISP.
> (Who is surprised that patches from Debian are Debian-specific?)
>
> The solution is to use /usr/bin/env for a PATH lookup. So that it works
> on Guix as well. Unfortunately, that requires using a non-POSIX option,
> in order to avoid an error
>
>   $ lib/uniname/gen-uninames.lisp UnicodeData.txt NameAliases.txt uninames.h
>   /usr/bin/env: ‘clisp -C’: No such file or directory
>   /usr/bin/env: use -[v]S to pass options in shebang lines

Thanks, this seems even better, and will allow Debian to (eventually)
drop the custom patch.

/Simon

> 2024-07-02  Bruno Haible  
>
>   uniname/uniname: Modernize gen-uninames.lisp.
>   Reported by Simon Josefsson in
>   .
>   * lib/uniname/gen-uninames.lisp: Swap second and third parameter. Look
>   up clisp in $PATH.
>   * lib/gen-uni-tables.c: Update invocation.
>
> diff --git a/lib/uniname/gen-uninames.lisp b/lib/uniname/gen-uninames.lisp
> index 1b0c60cf04..30191f2e8e 100755
> --- a/lib/uniname/gen-uninames.lisp
> +++ b/lib/uniname/gen-uninames.lisp
> @@ -1,6 +1,7 @@
> -#!/usr/local/bin/clisp -C
> +#!/usr/bin/env -S clisp -C
>  
> -;;; Creation of gnulib's uninames.h from the UnicodeData.txt table.
> +;;; Creation of gnulib's uninames.h from the UnicodeData.txt and 
> NameAliases.txt
> +;;; tables.
>  
>  ;;; Copyright (C) 2000-2024 Free Software Foundation, Inc.
>  ;;; Written by Bruno Haible , 2000-12-28.
> @@ -48,8 +49,8 @@
>length; number of words
>  )
>  
> -(defun main (inputfile outputfile aliasfile)
> -  (declare (type string inputfile outputfile aliasfile))
> +(defun main (inputfile aliasfile outputfile)
> +  (declare (type string inputfile aliasfile outputfile))
>#+UNICODE (setq *default-file-encoding* charset:utf-8)
>(let ((all-chars '())
>  (all-chars-hashed (make-hash-table :test #'equal))
> diff --git a/lib/gen-uni-tables.c b/lib/gen-uni-tables.c
> index 3ebcd833ff..b4f16da560 100644
> --- a/lib/gen-uni-tables.c
> +++ b/lib/gen-uni-tables.c
> @@ -12075,8 +12075,8 @@ main (int argc, char * argv[])
>   *   && diff uniwbrk/wbrkprop_org.txt uniwbrk/wbrkprop.txt  \\
>   *   && clisp -C uniname/gen-uninames.lisp  \\
>   *
> /media/nas/bruno/www-archive/software/i18n/unicode/ftp.unicode.org/ArchiveVersions/15.1.0/ucd/UnicodeData.txt
>  \\
> - *uniname/uninames.h\\
>   *
> /media/nas/bruno/www-archive/software/i18n/unicode/ftp.unicode.org/ArchiveVersions/15.1.0/ucd/NameAliases.txt
>  \\
> + *uniname/uninames.h\\
>   *   && { sed -e 's/^/# /' -e 's/ $//' < 
> /media/nas/bruno/www-archive/software/i18n/unicode/ftp.unicode.org/ArchiveVersions/license.txt;
>  \\
>   *echo; \\
>   *cat 
> /media/nas/bruno/www-archive/software/i18n/unicode/ftp.unicode.org/ArchiveVersions/15.1.0/ucd/NameAliases.txt;
>  } \\
>
>
>
>
>


signature.asc
Description: PGP signature

Re: Bug#752135: git-merge-changelog: Overstates the need for .gitattributes

[Simon Josefsson via Gnulib discussion list]

Samuel Bronson  writes:

> Package: git-merge-changelog
> Version: 20140202+stable-2
> Severity: normal
>
> Dear Maintainer,
>
> Your git-merge-changelog(1) manpage and the source file
> git-merge-changelog.c both say that you need a '.gitattributes' file in
> *every* directory.  In fact, if you want all files named ChangeLog in a
> given git repository to be merged using git-merge-changelog, you just
> need one .gitattributes file at the top of the tree, with the same
> contents already documented in both manpage and source.
>
> This is because the pattern is treated the same as in .gitignore, which
> means that for a pattern to be restricted to matching a file relative
> to that particular directory, it must start with a /, so "ChangeLog"
> will match any file named ChangeLog in the directory containing the
> .gitattribute file or any of its subdirectories.

Hi Samuel.  Thanks for the bug report.  I believe you are right, and I
suggest the patch below.  Bruno, what do you think?  Maybe today it is
more fashionable to use top-level .gitattributes and not bother with
per-directory files that feels like a CVS idiom.

/Simon

diff --git a/lib/git-merge-changelog.c b/lib/git-merge-changelog.c
index 3cffe1fd2f..b8c6b63c32 100644
--- a/lib/git-merge-changelog.c
+++ b/lib/git-merge-changelog.c
@@ -55,8 +55,9 @@
   name = GNU-style ChangeLog merge driver
   driver = /usr/local/bin/git-merge-changelog %O %A %B
 
- - In every directory that contains a ChangeLog file, add a file
-   '.gitattributes' with this line:
+ - In every directory that contains a ChangeLog file, or
+   at the top-level directory, add a file '.gitattributes' with
+   this line:
 
   ChangeLogmerge=merge-changelog
 


signature.asc
Description: PGP signature

Re: Bug#752135: git-merge-changelog: Overstates the need for .gitattributes

[Bruno Haible]

Hi Samuel and Simon,

> I believe you are right, and I
> suggest the patch below.  Bruno, what do you think?

Yes, you are right. I have a package with a .gitattributes at the
top-level and a src/ChangeLog, and the .gitattributes file has the
desired effect. (Things may well have been different 16 years ago.
But what matters are the 'git' versions in use today.)

> Maybe today it is
> more fashionable to use top-level .gitattributes and not bother with
> per-directory files that feels like a CVS idiom.

Absolutely. I'm committing this:


2024-07-02  Bruno Haible  

git-merge-changelog: Simplify installation instructions.
Reported by Samuel Bronson  via Simon Josefsson in
.
* lib/git-merge-changelog.c: Suggest creating a .gitattributes file only
at the top-level.

diff --git a/lib/git-merge-changelog.c b/lib/git-merge-changelog.c
index 3cffe1fd2f..60754c8367 100644
--- a/lib/git-merge-changelog.c
+++ b/lib/git-merge-changelog.c
@@ -1,5 +1,5 @@
 /* git-merge-changelog - git "merge" driver for GNU style ChangeLog files.
-   Copyright (C) 2008-2021 Bruno Haible 
+   Copyright (C) 2008-2024 Bruno Haible 
 
This file is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published
@@ -55,8 +55,8 @@
   name = GNU-style ChangeLog merge driver
   driver = /usr/local/bin/git-merge-changelog %O %A %B
 
- - In every directory that contains a ChangeLog file, add a file
-   '.gitattributes' with this line:
+ - Add to the top-level directory of the checkout a file '.gitattributes'
+   with this line:
 
   ChangeLogmerge=merge-changelog
 
@@ -77,12 +77,12 @@
Additionally, for hg users:
  - Add to your $HOME/.hgrc the lines
 
-[merge-patterns]
-ChangeLog = git-merge-changelog
+  [merge-patterns]
+  ChangeLog = git-merge-changelog
 
-[merge-tools]
-git-merge-changelog.executable = /usr/local/bin/git-merge-changelog
-git-merge-changelog.args = $base $local $other
+  [merge-tools]
+  git-merge-changelog.executable = /usr/local/bin/git-merge-changelog
+  git-merge-changelog.args = $base $local $other
 
See  section merge-tools
for reference.

Re: Bug#752135: git-merge-changelog: Overstates the need for .gitattributes

[Simon Josefsson via Gnulib discussion list]

Bruno Haible  writes:

> Hi Samuel and Simon,
>
>> I believe you are right, and I
>> suggest the patch below.  Bruno, what do you think?
>
> Yes, you are right. I have a package with a .gitattributes at the
> top-level and a src/ChangeLog, and the .gitattributes file has the
> desired effect. (Things may well have been different 16 years ago.
> But what matters are the 'git' versions in use today.)
>
>> Maybe today it is
>> more fashionable to use top-level .gitattributes and not bother with
>> per-directory files that feels like a CVS idiom.
>
> Absolutely. I'm committing this:

Thank you!  Looks great.  This fix didn't make it into the 20240701-1
upload of gnulib into Debian, but hopefully I'll be able to take care of
it before the next upload.

It would be nice if the documentation is moved to the gnulib texinfo
manual, but as I haven't tried git-merge-changelog yet I'm not the best
person to work on that.

/Simon


signature.asc
Description: PGP signature

Re: Bug#752135: git-merge-changelog: Overstates the need for .gitattributes

[Bruno Haible]

Simon Josefsson wrote:
> It would be nice if the documentation is moved to the gnulib texinfo
> manual, but as I haven't tried git-merge-changelog yet I'm not the best
> person to work on that.

git-merge-changelog is actually out-of-place in gnulib, since it's a program
(to be compiled first, not even a shell script) whereas gnulib is a library.

It should better be moved to https://savannah.gnu.org/projects/vc-changelog/
and released as a tarball on ftp.gnu.org. But I don't have time for doing
that at the moment.

Therefore I don't think it would be a good idea to move its documentation
into gnulib's documentation.

Bruno