[PATCH] terminfo, termcap: Fix more spellos in a comment.
* lib/tparm.c: Fix misspellings and wording in the main comment. --- ChangeLog | 5 + lib/tparm.c | 8 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog index 25610ee51b..17bb762072 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2023-02-27 Benno Schulenberg(tiny change) + + terminfo, termcap: Fix more spellos in a comment. + * lib/tparm.c: Fix misspellings and wording in the main comment. + 2023-02-27 ChuanGang Jiang fts: fail gracefully when out of memory diff --git a/lib/tparm.c b/lib/tparm.c index 17923787d7..e9214e292c 100644 --- a/lib/tparm.c +++ b/lib/tparm.c @@ -176,14 +176,14 @@ cvtchar (const char *sp, char *c) /* sigh... this has got to be the ugliest code I've ever written. Trying to handle everything has its cost, I guess. - It actually isn't to hard to figure out if a given % code is supposed + It actually isn't too hard to figure out if a given % code is supposed to be interpreted with its termcap or terminfo meaning since almost all terminfo codes are invalid unless something has been pushed on the stack and termcap strings will never push things on the stack (%p isn't used by termcap). So where we have a choice we make the - decision by whether or not somthing has been pushed on the stack. + decision by whether or not something has been pushed on the stack. The static variable termcap keeps track of this; it starts out set - to 1 and is incremented as each argument processed by a termcap % code, + to 1 and is incremented for each argument processed for a termcap % code, however if something is pushed on the stack it's set to 0 and the rest of the % codes are interpreted as terminfo % codes. Another way of putting it is that if termcap equals one we haven't decided either @@ -216,7 +216,7 @@ cvtchar (const char *sp, char *c) %O logical or pop and pop and push the result %! push the logical not of pop %? condition %t if_true [%e if_false] %; -if condition evaulates as true then evaluate if_true, +if condition evaluates as true then evaluate if_true, else evaluate if_false. elseif's can be done: %? cond %t true [%e cond2 %t true2] ... [%e condN %t trueN] [%e false] %; %i add one to parameters 1 and 2. (ANSI) -- 2.39.2
glob.m4 leaves the file 'conf-file' behind
Since commit c386ed6eb0 from a month ago, the m4/glob.m4 script creates a file './conf-file' and does not delete it afterward, causing 'make distcheck' to fail for GNU nano. ERROR: files left in build directory after distclean: ./conf-file Makefile:2038: recipe for target 'distcleancheck' failed make[1]: *** [distcleancheck] Error 1 Benno OpenPGP_signature Description: OpenPGP digital signature
Re: build failure of glob module on NetBSD: request for member ‘dd_fd’...
Op 27-04-2022 om 00:02 schreef Paul Eggert: > I took the easy way out, though, and simply documented the bugs and modified > glob to not run afoul of the bugs, by installing the attached patch into > Gnulib. This fixes the issue for me. Thanks. Benno OpenPGP_signature Description: OpenPGP digital signature
build failure of glob module on NetBSD: request for member ‘dd_fd’...
Trying to build nano from git on a NetBSD 9.2 virtual machine, I get this: [...] gcc -DHAVE_CONFIG_H -I. -I.. -D_NETBSD_SOURCE -D_XOPEN_SOURCE=600 -I/usr/pkg/include/ncursesw -I/usr/pkg/include -I/usr/pkg/include -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function -Wno-unused-parameter -Wno-float-conversion -Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits -Wno-unsuffixed-float-constants -g -O2 -Wall -MT libgnu_a-glob.o -MD -MP -MF .deps/libgnu_a-glob.Tpo -c -o libgnu_a-glob.o `test -f 'glob.c' || echo './'`glob.c In file included from ./dirent.h:27:0, from glob.c:49: glob.c: In function ‘glob_in_dir’: glob.c:1361:21: error: request for member ‘dd_fd’ in something not a structure or union int dfd = dirfd (stream); ^ *** Error code 1 The offending commit is 98f034a0c2 (glob: fix symlink and // issues...). Nano builds fine on FreeBSD and OpenBSD. Benno OpenPGP_signature Description: OpenPGP digital signature
[PATCH] doc: add two missing closing parentheses
* doc/regex.texi (Syntax Bits): Add missing closing parenthesis.
* doc/regex.texi (BSD Regular Expression Compiling): Likewise.
---
ChangeLog | 6 ++
doc/regex.texi | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 7f0970e310..4cffa1044b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2022-02-22 Benno Schulenberg(tiny change)
+
+ doc: add two missing closing parentheses
+ * doc/regex.texi (Syntax Bits): Add missing closing parenthesis.
+ * doc/regex.texi (BSD Regular Expression Compiling): Likewise.
+
2022-02-21 Paul Eggert
close-stream: don't depend on fclose
diff --git a/doc/regex.texi b/doc/regex.texi
index c8a691ebc8..d21052282d 100644
--- a/doc/regex.texi
+++ b/doc/regex.texi
@@ -118,7 +118,7 @@ order:
@cnindex RE_BACKSLASH_ESCAPE_IN_LIST
@item RE_BACKSLASH_ESCAPE_IN_LISTS
-If this bit is set, then @samp{\} inside a list (@pxref{List Operators}
+If this bit is set, then @samp{\} inside a list (@pxref{List Operators})
quotes (makes ordinary, if it's special) the following character; if
this bit isn't set, then @samp{\} is an ordinary character inside lists.
(@xref{The Backslash Character}, for what @samp{\} does outside of lists.)
@@ -2122,7 +2122,7 @@ With Berkeley Unix, you can only search for a given
regular
expression; you can't match one. To search for it, you must first
compile it. Before you compile it, you must indicate the regular
expression syntax you want it compiled according to by setting the
-variable @code{re_syntax_options} (declared in @file{regex.h} to some
+variable @code{re_syntax_options} (declared in @file{regex.h}) to some
syntax (@pxref{Regular Expression Syntax}).
To compile a regular expression use:
--
2.34.1
Re: compiling with tcc fails on regex.c since commit 56b32251
Op 27-11-2021 om 10:01 schreef Paul Eggert: > tcc is failing because it claims to support C99 (it > defines __STDC_VERSION__ to 199901L), but it doesn't support variable length > arrays as C99 requires. Perhaps you could file a bug report with the tcc > folks? Reported as https://savannah.nongnu.org/bugs/?61587. > Anyway, I installed the attached patches into Gnulib to attempt to work around > the tcc bug. Thanks. Compilation succeeds now. Benno OpenPGP_signature Description: OpenPGP digital signature
compiling with tcc fails on regex.c since commit 56b32251
Hi, Since commit 56b32251 from two months ago, I can no longer compile nano with tcc. It breaks on the regex module: [...] source='regex.c' object='regex.o' libtool=no \ DEPDIR=.deps depmode=tcc /bin/bash ../depcomp \ tcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw -g -O2 -Wall -c -o regex.o regex.c In file included from regex.c:70: ./regex.h:682: error: '__nmatch' undeclared Makefile:2143: recipe for target 'regex.o' failed make[4]: *** [regex.o] Error 1 make[4]: Leaving directory '/home/ben/Sources/NANO/lib' Makefile:2162: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 [...] $ tcc -v tcc version 0.9.27 (x86_64 Linux) Benno OpenPGP_signature Description: OpenPGP digital signature
Re: heap-buffer overflow when searching for regex @\*
Op 19-10-2021 om 00:10 schreef Paul Eggert: > Thanks for the bug report. I reproduced the problem with texinfo and installed > the attached Gnulib patch, which fixed things for me with texinfo. I didn't > quite > follow the 'nano' instructions but I hope this fixes the problem there too. Yes, using current gnulib, the issue is fixed for nano as well. Thanks! (Not that I would ever search for such a regex in nano. :) It was just to verify that the issue was in gnulib and not somehow caused by info itself.) Benno OpenPGP_signature Description: OpenPGP digital signature
heap-buffer overflow when searching for regex @\*
Hi, When compiling the 'info' program or GNU nano with -fsanitize=address, then searching in either of the programs for the regex "@\*" (without the quotes) causes an abortion in gnulib's re_search_internal() at lib/regexec.c:764. To reproduce, configure texinfo-6.8 with CFLAGS="-g -O0 -march=native -fsanitize=address", compile, and then run 'info/ginfo texinfo 2>TRAIL' and search for "@\*". In other words, type: /@\*. Then type five times Shift+}. Result: info aborts. See the attached output. To reproduce with nano, first run 'makeinfo --plain doc/texinfo.texi >thetext' in the texinfo-6.8 directory, then configure nano-5.9 with the same CFLAGS, compile, and then run 'src/nano +1 thetext 2>TRAIL' and type: Ctrl+W Alt+R @\*. Type type six times Alt+W. Result: nano aborts. See the attached output. Problem still occurs when using a current checkout of gnulib. Benno = ==15833==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602429f6 at pc 0x55571a3caf51 bp 0x7ffdbabfd5f0 sp 0x7ffdbabfd5e0 READ of size 1 at 0x602429f6 thread T0 #0 0x55571a3caf50 in re_search_internal /home/ben/Programoj/texinfo-6.8/gnulib/lib/regexec.c:764 #1 0x55571a3c88d8 in rpl_regexec /home/ben/Programoj/texinfo-6.8/gnulib/lib/regexec.c:219 #2 0x55571a37a8f3 in extend_matches /home/ben/Programoj/texinfo-6.8/info/search.c:142 #3 0x55571a37b1cf in regexp_search /home/ben/Programoj/texinfo-6.8/info/search.c:214 #4 0x55571a38dfcd in info_search_in_node_internal /home/ben/Programoj/texinfo-6.8/info/session.c:3956 #5 0x55571a38ed01 in info_search_internal /home/ben/Programoj/texinfo-6.8/info/session.c:4087 #6 0x55571a392477 in info_search_next /home/ben/Programoj/texinfo-6.8/info/session.c:4688 #7 0x55571a37e9b3 in info_read_and_dispatch /home/ben/Programoj/texinfo-6.8/info/session.c:252 #8 0x55571a37e797 in info_session /home/ben/Programoj/texinfo-6.8/info/session.c:220 #9 0x55571a365a26 in main /home/ben/Programoj/texinfo-6.8/info/info.c:1079 #10 0x7fca41f5bbf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6) #11 0x55571a3457e9 in _start (/usr/local/bin/info+0x237e9) 0x602429f6 is located 0 bytes to the right of 6-byte region [0x602429f0,0x602429f6) allocated by thread T0 here: #0 0x7fca42633f30 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdef30) #1 0x55571a3a8c0e in re_string_realloc_buffers /home/ben/Programoj/texinfo-6.8/gnulib/lib/regex_internal.c:168 #2 0x55571a3a82e9 in re_string_allocate /home/ben/Programoj/texinfo-6.8/gnulib/lib/regex_internal.c:61 #3 0x55571a3ca27b in re_search_internal /home/ben/Programoj/texinfo-6.8/gnulib/lib/regexec.c:636 #4 0x55571a3c88d8 in rpl_regexec /home/ben/Programoj/texinfo-6.8/gnulib/lib/regexec.c:219 #5 0x55571a37a8f3 in extend_matches /home/ben/Programoj/texinfo-6.8/info/search.c:142 #6 0x55571a37b1cf in regexp_search /home/ben/Programoj/texinfo-6.8/info/search.c:214 #7 0x55571a38dfcd in info_search_in_node_internal /home/ben/Programoj/texinfo-6.8/info/session.c:3956 #8 0x55571a38ed01 in info_search_internal /home/ben/Programoj/texinfo-6.8/info/session.c:4087 #9 0x55571a392477 in info_search_next /home/ben/Programoj/texinfo-6.8/info/session.c:4688 #10 0x55571a37e9b3 in info_read_and_dispatch /home/ben/Programoj/texinfo-6.8/info/session.c:252 #11 0x55571a37e797 in info_session /home/ben/Programoj/texinfo-6.8/info/session.c:220 #12 0x55571a365a26 in main /home/ben/Programoj/texinfo-6.8/info/info.c:1079 #13 0x7fca41f5bbf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ben/Programoj/texinfo-6.8/gnulib/lib/regexec.c:764 in re_search_internal Shadow bytes around the buggy address: 0x0c0484e0: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa 0x0c0484f0: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fa 0x0c048500: fa fa fd fa fa fa fd fd fa fa fd fa fa fa 04 fa 0x0c048510: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa 0x0c048520: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa fd fa =>0x0c048530: fa fa 00 fa fa fa 00 fa fa fa 00 00 fa fa[06]fa 0x0c048540: fa fa fd fa fa fa fd fd fa fa 00 fa fa fa 00 fa 0x0c048550: fa fa 00 00 fa fa fd fa fa fa fd fd fa fa 00 fa 0x0c048560: fa fa 00 fa fa fa 00 00 fa fa fa fa fa fa fa fa 0x0c048570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c048580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init o
mkstemps is not listed alphabetically in the manual
Hi, On https://www.gnu.org/software/gnulib/manual/html_node/Glibc-stdlib_002eh.html the entry for 'mkstemps' is out of alphabetical order. This is confusing. (I had downloaded the PDF of the manual, searched for mkstemps, paged up a bit, and then -- scrolling back down -- wondered where mkstemps went, expecting it to be after mkostemps.) Benno OpenPGP_signature Description: OpenPGP digital signature
Re: commit eb32c992 causes trouble on older Debian
Op 27-04-2021 om 20:28 schreef Paul Eggert: > Thanks for reporting that. I installed the attached into Gnulib to try to work > around the problem. Please give it a try (I haven't tested it on older > Debian). Confirmed. Commit afeeb210 fixes the problem. Thanks. Benno signature.asc Description: OpenPGP digital signature
commit eb32c992 causes trouble on older Debian
Hi, Commit eb32c992 from five days ago causes trouble when trying to compile GNU nano from git on an older Debian box: make[4]: Entering directory `/home/bens/NANO/lib' depbase=`echo malloc/dynarray_at_failure.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc -std=gnu11 -DHAVE_CONFIG_H -I. -I.. -I/usr/include/ncursesw -O1 -Wall -MT malloc/dynarray_at_failure.o -MD -MP -MF $depbase.Tpo -c -o malloc/dynarray_at_failure.o malloc/dynarray_at_failure.c &&\ mv -f $depbase.Tpo $depbase.Po In file included from ./libc-config.h:162:0, from malloc/dynarray_at_failure.c:20: ./cdefs.h:496:31: fatal error: bits/long-double.h: No such file or directory compilation terminated. When stepping back to the preceding commit (882243dc), things compile fine. The most recent commit (4b071c11 at the moment) still shows the problem. $lsb_release -d Description:Debian GNU/Linux 7.10 (wheezy) Benno signature.asc Description: OpenPGP digital signature
Re: [PATCH] mbrtowc: remove a redundant condition
Op 21-03-2021 om 19:22 schreef Bruno Haible: > Hi Benno, > >> * lib/mbrtowc-impl-utf8.h: There is no need to check for c == 0xf4 >> when !(c < 0xf4), as ten lines earlier c <= 0xf4 was established. > > Your patch is correct. But we generally don't need to do micro- > optimizations that a compiler easily can do for us. Yeah, I guess that the compiler could elide this superfluous condition. But does it actually do it? How many steps back does it take? > Just curious: > Did you get a compiler warning about this code? If so, from which > compiler? Or did you find this redundancy by staring at the code? By staring at the code and trying to understand whether I am missing something, why that c == 0xf4 is there. I was looking at the code to see how conversion from multibyte to wide character is done, whether it's worth it to give nano its own copy. There is quite some overhead at the beginning, and nano doesn't need to do the checks on m. Also, I want nano's version to return -1 for codes beyond U+10. The mbtowc from glibc returns 4 for codes from U+11 to U+1F, but those are not valid UTF-8 sequences, so nano would need to do another check afterward. Benno signature.asc Description: OpenPGP digital signature
[PATCH] mbrtowc: remove a redundant condition
* lib/mbrtowc-impl-utf8.h: There is no need to check for c == 0xf4
when !(c < 0xf4), as ten lines earlier c <= 0xf4 was established.
---
ChangeLog | 6 ++
lib/mbrtowc-impl-utf8.h | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index 76ea9c3eb..d2dfe5e0c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2021-03-21 Benno Schulenberg(tiny change)
+
+ mbrtowc: remove a redundant condition
+ * lib/mbrtowc-impl-utf8.h: There is no need to check for c == 0xf4
+ when !(c < 0xf4), as ten lines earlier c <= 0xf4 was established.
+
2021-03-21 Bruno Haible
doc: More updates.
diff --git a/lib/mbrtowc-impl-utf8.h b/lib/mbrtowc-impl-utf8.h
index 4f3bbb31b..38cecfcc5 100644
--- a/lib/mbrtowc-impl-utf8.h
+++ b/lib/mbrtowc-impl-utf8.h
@@ -96,7 +96,7 @@
if ((c2 ^ 0x80) < 0x40
&& (c >= 0xf1 || c2 >= 0x90)
-&& (c < 0xf4 || (c == 0xf4 && c2 < 0x90)))
+&& (c < 0xf4 || c2 < 0x90))
{
if (m == 2)
goto incomplete;
--
2.29.3
Re: commit 452fee36 causes trouble when compiling with clang
Hello Bruno, >> In file included from regex.c:74: >> ./regexec.c:1198:3: error: invalid application of 'typeof' to bit-field >> DEBUG_ASSERT (state->halt); >> ^ > > Thanks for the report. I didn't know that __typeof__ does not work for all > kinds of expressions. (intprops uses __typeof__ as well.) This patch fixes it. > > 2020-08-23 Bruno Haible > > verify: Make assume work on bit field expressions (regr. 2020-08-22). I can confirm that with commit f3808e88 things compile fine again. Benno signature.asc Description: OpenPGP digital signature
commit 452fee36 causes trouble when compiling with clang
Hi,
Running a compile test of nano with the current state of gnulib
(commit 452fee36, "verify: Do use __builtin_assume on clang")
on FreeBSD (which happens to use clang), the compile failed:
clang -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -D_DEFAULT_SOURCE
-I/usr/include/ncursesw -g -O1 -march=native -Wvla -Wshadow -Wall -MT regex.o
-MD -MP -MF $depbase.Tpo -c -o regex.o regex.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from regex.c:74:
./regexec.c:1198:3: error: invalid application of 'typeof' to bit-field
DEBUG_ASSERT (state->halt);
^
./regex_internal.h:42:26: note: expanded from macro 'DEBUG_ASSERT'
# define DEBUG_ASSERT(x) assume (x)
^
./verify.h:327:27: note: expanded from macro 'assume'
((void) ({ __typeof__ (R) _gl_verify_temp = (R); \
^
1 error generated.
Stepping one commit back, the compile succeeds fine.
$ clang --version
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM
8.0.1)
Same failure on Ubuntu 18.04 when using clang.
$ clang --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Benno
signature.asc
Description: OpenPGP digital signature
[PATCH] users.txt: add GNU nano
Nano has been making use of gnulib since March 2017, version 2.8.0. --- ChangeLog | 5 + users.txt | 1 + 2 files changed, 6 insertions(+) diff --git a/ChangeLog b/ChangeLog index 25f1f3e3b..983dcf4c8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2019-10-06 Benno Schulenberg(tiny change) + + users.txt: add GNU nano + Nano has been making use of gnulib since March 2017, version 2.8.0. + 2019-10-05 Paul Eggert bootstrap: simplify debugging of wget failures diff --git a/users.txt b/users.txt index 1bbab8dd2..84863c449 100644 --- a/users.txt +++ b/users.txt @@ -69,6 +69,7 @@ The following packages appear to be using gnulib and gnulib-tool: msmtp https://sourceforge.net/p/msmtp/code/ci/master/tree/ myserverhttps://git.sv.gnu.org/gitweb/?p=myserver.git;a=summary nagios-plugins https://github.com/nagios-plugins/nagios-plugins + nanohttps://git.savannah.gnu.org/cgit/nano.git Net::CDPhttp://cpansearch.perl.org/src/MCHAPMAN/Net-CDP-0.09/libcdp/ netcf https://fedorahosted.org/netcf/ OATH Toolkithttps://gitlab.com/oath-toolkit/oath-toolkit/ -- 2.23.0
Re: gnulib's translation
Op 02-12-18 om 13:10 schreef Bruno Haible: > - Thus the interface between the package maintainers and the TP is simpler > if > the package maintainers submit a tarball to the TP. Precisely. Furthermore, when following git, how is the translator to know that a release is approaching and the time has come to update his/her PO file? We don't want to prod the translators for every little string change. > Ah, you were assuming that the POT file is stored in the version control > system? > This is a practice that produces problems, What problems does this produce? (Probably this was discussed earlier and elsewhere? Maybe have a URL of an archived message?) Benno
Re: gnulib's translation
Op 01-12-18 om 17:00 schreef Bruno Haible: > Akim has just moved some code from Bison to Gnulib. He writes: > >> Also, I feel sorry for Bison's translators when submitting modules to >> gnulib: it's kind of throwing away their work; it would be great if there >> were a means to preserve these translations. Maybe the translation project >> is able to fill the translations of one project based on that of another, I >> don't know. > > What is the recommended procedure, to save translator work, when a number of > messages have been moved from one domain to another domain (both domains are > managed by the TP)? There is no procedure, as such moving of stuff across domains is a rare affair. But... it should not result in any Bison strings going untranslated because Bison will now include the relevant modules from gnulib, and the strings they contain will still be included in Bison's POT file -- they will just be marked with "#: lib/..." instead of "#: src/...", no? (When a new gnulib POT file gets submitted, I could do a one-time msgmerge to "import" translated strings from Bison to gnulib.) Benno
Re: gnulib's translation
> Akim Demaille wrote: >> maybe the translation project could work on top of git now? No, I'm not going to do that. The TP is geared toward packages that make releases. So I need a (prerelease) tarball that contains the corresponding POT file. Benno
[PATCH 2/2] bootstrap, gnulib-tool: use https instead of insecure rsync
The rsync command does not do any authentication and thus allows
man-in-the-middle attacks. Better use wget over https, although
this is slower.
* build-aux/bootstrap (download_po_files, po_download_command_format):
Don't try using rsync; always use wget over https to fetch PO files.
* gnulib-tool (func_import): Likewise.
* pygnulib/GLImport.py (GLImport.execute): Likewise.
---
build-aux/bootstrap | 12 +---
gnulib-tool | 10 +-
pygnulib/GLImport.py | 13 +++--
3 files changed, 5 insertions(+), 30 deletions(-)
diff --git a/build-aux/bootstrap b/build-aux/bootstrap
index 4a37ed0d0..cde39f4e7 100755
--- a/build-aux/bootstrap
+++ b/build-aux/bootstrap
@@ -164,15 +164,8 @@ bootstrap_epilogue() { :; }
# The command to download all .po files for a specified domain into
# a specified directory. Fill in the first %s is the domain name, and
-# the second with the destination directory. Use rsync's -L and -r
-# options because the latest/%s directory and the .po files within are
-# all symlinks.
+# the second with the destination directory.
po_download_command_format=\
-"rsync --include '*.po' --exclude '*' -Lrtvz \
- 'translationproject.org::tp/latest/%s/' '%s'"
-
-# Fallback for downloading .po files (if rsync fails).
-po_download_command_format2=\
"wget --mirror --level=1 -nd -q -A.po -P '%s' \
https://translationproject.org/latest/%s/";
@@ -742,9 +735,6 @@ download_po_files() {
domain=$2
echo "$me: getting translations into $subdir for $domain..."
cmd=$(printf "$po_download_command_format" "$domain" "$subdir")
- eval "$cmd" && return
- # Fallback to HTTPS.
- cmd=$(printf "$po_download_command_format2" "$subdir" "$domain")
eval "$cmd"
}
diff --git a/gnulib-tool b/gnulib-tool
index a0a52ce80..90e17aa19 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -5431,18 +5431,10 @@ s,//*$,/,'
fi
# Fetch PO files.
TP_URL="https://translationproject.org/latest/";
-TP_RSYNC_URI="translationproject.org::tp/latest/"
if $doit; then
echo "Fetching gnulib PO files from $TP_URL"
(cd "$destdir"/$pobase \
- && { # Prefer rsync over wget if it is available, since it consumes
-# less network bandwidth, due to compression.
-if type rsync 2>/dev/null | grep / > /dev/null; then
- rsync --delete --include "*.po" --exclude "*" -Lrtz
"${TP_RSYNC_URI}gnulib/" . && return
-fi
-
-wget --no-verbose --mirror -l1 -nd -A.po -P . "${TP_URL}gnulib/"
- }
+ && wget --no-verbose --mirror -l1 -nd -A.po -P . "${TP_URL}gnulib/"
)
else
echo "Fetch gnulib PO files from $TP_URL"
diff --git a/pygnulib/GLImport.py b/pygnulib/GLImport.py
index 3b4729ee7..19ade5e8d 100644
--- a/pygnulib/GLImport.py
+++ b/pygnulib/GLImport.py
@@ -1200,19 +1200,12 @@ AC_DEFUN([%s_FILE_LIST], [\n''' % macro_prefix
# Fetch PO files.
TP_URL = 'https://translationproject.org/latest/'
-TP_RSYNC_URI = 'translationproject.org::tp/latest/'
if not self.config['dryrun']:
print('Fetching gnulib PO files from %s' % TP_URL)
os.chdir(joinpath(destdir, pobase))
-cmd = 'type rsync 2>/dev/null | grep / > /dev/null'
-result = sp.call(cmd, shell=True)
-if result == 0: # use rsync
-args = ['rsync', '--include', '*.po', '--exclude', '*',
'-Lrtz', '%sgnulib/' % TP_RSYNC_URI, '.']
-result = sp.call(args, shell=True)
-if result != 0: # use wget
-args = ['wget', '--no-verbose', '--mirror', '--level=1',
'-nd', '-A.po', '-P', '.',
-'%sgnulib/' % TP_URL]
-sp.call(args, shell=True)
+args = ['wget', '--no-verbose', '--mirror', '--level=1',
'-nd', '-A.po', '-P', '.',
+'%sgnulib/' % TP_URL]
+sp.call(args, shell=True)
else: # if self.config['dryrun']
print('Fetch gnulib PO files from %s' % TP_URL)
--
2.17.1
[PATCH 1/2] bootstrap, gnulib-tool: correct the translations wget command
Using the -np (--no-parent) option doesn't prevent wget from
traversing the given URL to a default depth of 5, and since
the domain directory contains a href="/latest/" link, this
means that wget searches through all domains anyway and will
also download PO files that are meant for other packages.
When getting the PO files for the nano domain, for example,
you will end up with af.po and ast.po (and many others) too,
but there are no African nor Asturian translations for nano.
So, use the --level option instead, to stop wget from looking
any further than the given URL.
* build-aux/bootstrap (po_download_command_format2): Restrict
recursion to a single level.
* gnulib-tool (func_import): Likewise.
* pygnulib/GLImport.py (GLImport.execute): Likewise.
---
build-aux/bootstrap | 2 +-
gnulib-tool | 2 +-
pygnulib/GLImport.py | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/build-aux/bootstrap b/build-aux/bootstrap
index fa9d7c94a..4a37ed0d0 100755
--- a/build-aux/bootstrap
+++ b/build-aux/bootstrap
@@ -173,7 +173,7 @@ po_download_command_format=\
# Fallback for downloading .po files (if rsync fails).
po_download_command_format2=\
-"wget --mirror -nd -q -np -A.po -P '%s' \
+"wget --mirror --level=1 -nd -q -A.po -P '%s' \
https://translationproject.org/latest/%s/";
# Prefer a non-empty tarname (4th argument of AC_INIT if given), else
diff --git a/gnulib-tool b/gnulib-tool
index 92bfee4fe..a0a52ce80 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -5441,7 +5441,7 @@ s,//*$,/,'
rsync --delete --include "*.po" --exclude "*" -Lrtz
"${TP_RSYNC_URI}gnulib/" . && return
fi
-wget --no-verbose --mirror -nd -np -A.po -P . "${TP_URL}gnulib/"
+wget --no-verbose --mirror -l1 -nd -A.po -P . "${TP_URL}gnulib/"
}
)
else
diff --git a/pygnulib/GLImport.py b/pygnulib/GLImport.py
index b495d2dfe..3b4729ee7 100644
--- a/pygnulib/GLImport.py
+++ b/pygnulib/GLImport.py
@@ -1210,7 +1210,7 @@ AC_DEFUN([%s_FILE_LIST], [\n''' % macro_prefix
args = ['rsync', '--include', '*.po', '--exclude', '*',
'-Lrtz', '%sgnulib/' % TP_RSYNC_URI, '.']
result = sp.call(args, shell=True)
if result != 0: # use wget
-args = ['wget', '--no-verbose', '--mirror', '-nd', '-np',
'-A.po', '-P', '.',
+args = ['wget', '--no-verbose', '--mirror', '--level=1',
'-nd', '-A.po', '-P', '.',
'%sgnulib/' % TP_URL]
sp.call(args, shell=True)
else: # if self.config['dryrun']
--
2.17.1
Re: [PATCH V2] localcharset: short-circuit the search for an alias on a Mac
Hi Bruno, Op 21-04-18 om 12:41 schreef Bruno Haible: > Thanks, applied. (For some background: a bug reporter found that on a Mac lots of time would be spent in locale_charset() when nano called wcwidth(): https://savannah.gnu.org/bugs/?53562#comment16.) > I added a comment. > Explanations about the code belong in the code, as comments, IMO. > Readers of the code should not be forced to constantly refer to > ChangeLog entries and commit messages in order to understand the code. True. Much better this way. Thanks. Benno
[PATCH V2] localcharset: short-circuit the search for an alias on a Mac
* lib/localcharset.c (get_charset_aliases): Add a tautological UTF-8 entry to speed up the search for this case. Most machines default to a UTF-8 locale nowadays, so begin the list of aliases with a dummy UTF-8 entry so it will be found immediately and a time-consuming search through the rest of the list is avoided. --- ChangeLog | 10 ++ lib/localcharset.c | 3 ++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index f5752a217..1c6f32294 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2018-04-21 Benno Schulenberg(tiny change) + + localcharset: short-circuit the search for an alias on a Mac + * lib/localcharset.c (get_charset_aliases): Add a tautological + UTF-8 entry to speed up the search for this case. + Most machines default to a UTF-8 locale nowadays, so begin the + list of aliases with a dummy UTF-8 entry so it will be found + immediately and a time-consuming search through the rest of + the list is avoided. + 2018-04-11 Paul Eggert fts: add comment diff --git a/lib/localcharset.c b/lib/localcharset.c index a73d6bdd1..66f6dacc0 100644 --- a/lib/localcharset.c +++ b/lib/localcharset.c @@ -263,7 +263,8 @@ get_charset_aliases (void) /* To avoid the trouble of installing a file that is shared by many GNU packages -- many packaging systems have problems with this --, simply inline the aliases here. */ - cp = "ISO8859-1" "\0" "ISO-8859-1" "\0" + cp = "UTF-8" "\0" "UTF-8" "\0" + "ISO8859-1" "\0" "ISO-8859-1" "\0" "ISO8859-2" "\0" "ISO-8859-2" "\0" "ISO8859-4" "\0" "ISO-8859-4" "\0" "ISO8859-5" "\0" "ISO-8859-5" "\0" -- 2.16.3
[PATCH] localcharset: short-circuit the search for an alias on a Mac
* lib/localcharset.c (get_charset_aliases): Add a tautological UTF-8 entry to speed up the search for this case. Most machines default to a UTF-8 locale nowadays, so begin the list of aliases with a dummy UTF-8 entry so it will be found immediately and a time-consuming search through the rest of the list is avoided. --- ChangeLog | 10 ++ lib/localcharset.c | 3 ++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index f5752a217..1c6f32294 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2018-04-21 Benno Schulenberg(tiny change) + + localcharset: short-circuit the search for an alias on a Mac + * lib/localcharset.c (get_charset_aliases): Add a tautological + UTF-8 entry to speed up the search for this case. + Most machines default to a UTF-8 locale nowadays, so begin the + list of aliases with a dummy UTF-8 entry so it will be found + immediately and a time-consuming search through the rest of + the list is avoided. + 2018-04-11 Paul Eggert fts: add comment diff --git a/lib/localcharset.c b/lib/localcharset.c index a73d6bdd1..9ea964581 100644 --- a/lib/localcharset.c +++ b/lib/localcharset.c @@ -263,7 +263,8 @@ get_charset_aliases (void) /* To avoid the trouble of installing a file that is shared by many GNU packages -- many packaging systems have problems with this --, simply inline the aliases here. */ - cp = "ISO8859-1" "\0" "ISO-8859-1" "\0" + cp = "UTF-8" "\0" "UTF-8" "\0"; + "ISO8859-1" "\0" "ISO-8859-1" "\0" "ISO8859-2" "\0" "ISO-8859-2" "\0" "ISO8859-4" "\0" "ISO-8859-4" "\0" "ISO8859-5" "\0" "ISO-8859-5" "\0" -- 2.16.3
[PATCH] stat: fix compilation failure on macOS Sierra
Reported by Marius Schamschula in https://savannah.gnu.org/bugs/?52546. * lib/stat.c: Add missing include of stat-time.h. --- lib/stat.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/stat.c b/lib/stat.c index 30ba67efc..f52ae9222 100644 --- a/lib/stat.c +++ b/lib/stat.c @@ -47,6 +47,8 @@ orig_stat (const char *filename, struct stat *buf) above. */ #include "sys/stat.h" +#include "stat-time.h" + #include #include #include -- 2.14.3
Re: clang's Undefined Sanitizer
Op 24-08-2017 om 11:34 schreef Bruno Haible: This part of the patch: [...] discards your change http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=e29357c8f445320cb3084352579fb2648cce4d0f I haven't gotten any answer to my inquiries https://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg9.html Can you confirm that you can use a newer GCC on Haiku, and that therefore said change was not actually needed? I couldn't find it on the site of Haiku, but finally found on the ffmpeg site that one can get a newer gcc (5.4.0 at the moment) on Haiku by making sure that "/system/bin/x86" is at the beginning of PATH: https://trac.ffmpeg.org/wiki/CompilationGuide/Haiku With that gcc, nano can be compiled on Haiku without a problem, also with current gnulib. So the change of the above patch is not needed for those who know where a less ancient toolchain hides itself on a Haiku system. Thanks, Benno
Re: clang's Undefined Sanitizer
Hi Bruno, Op 24-08-2017 om 11:34 schreef Bruno Haible: [...] discards your change http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=e29357c8f445320cb3084352579fb2648cce4d0f I haven't gotten any answer to my inquiries https://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg9.html Can you confirm that you can use a newer GCC on Haiku, and that therefore said change was not actually needed? I will look into that over the weekend. Thanks for caring for this. Benno
[patch] glob: do not place declarations after code, so it will compile on Haiku
Hi,
Trying to build nano from git on Haiku failed because, among other
things, in the gnulib module glob, a variable is declared after a
bit of code and the gcc-2* compiler on Haiku does not permit that.
(This is on a 32-bit machine.)
Attached is a patch that avoids the issue. (For my build, I need
only the first hunk, but since a comment on the next function says
to keep the two functions in sync...)
(Please CC; not subscribed.)
Benno
>From 63c8fb5f56210989ba33230c77febbc3323aafa0 Mon Sep 17 00:00:00 2001
From: Benno Schulenberg
Date: Sat, 1 Jul 2017 18:05:00 +0200
Subject: [PATCH] glob: declare variables at the very start of their scope
* lib/glob.c (convert_dirent, convert_dirent64): Give each fragment
its separate scope, so the functions will compile on Haiku.
---
lib/glob.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/lib/glob.c b/lib/glob.c
index d4fdc1737..dc0aff693 100644
--- a/lib/glob.c
+++ b/lib/glob.c
@@ -189,8 +189,11 @@ convert_dirent (const struct dirent *source)
struct readdir_result result = { NULL, };
return result;
}
- struct readdir_result result = READDIR_RESULT_INITIALIZER (source);
- return result;
+ else
+{
+ struct readdir_result result = READDIR_RESULT_INITIALIZER (source);
+ return result;
+}
}
#ifndef COMPILE_GLOB64
@@ -204,8 +207,11 @@ convert_dirent64 (const struct dirent64 *source)
struct readdir_result result = { NULL, };
return result;
}
- struct readdir_result result = READDIR_RESULT_INITIALIZER (source);
- return result;
+ else
+{
+ struct readdir_result result = READDIR_RESULT_INITIALIZER (source);
+ return result;
+}
}
#endif
--
2.13.1
why does the gnupload script itself ask for the passphrase?
Hi, When using the gnupload script to upload a release tarball, it first asks (on the terminal): "Enter GPG passphrase:". I type the passphrase, it says: "Signing nano-1.2.3.tar.xz ...", and then the graphical gpg-agent pops up and asks for the passphrase again. What gives? It seems I could put "use-agent" in my gpg.conf to get around this. But that is a dummy option for gpg2, so the script should really check also for the gpg version before asking the passphrase itself. Benno -- http://www.fastmail.com - mmm... Fastmail...
[patch] fix the grammar of some comment lines
Hi,
Looking at propernam(), I noticed a few tiny grammar mistakes
in the comments. Attached patch fixes those.
Benno
--
http://www.fastmail.com - Access your email from home and the web
From f4637c6a3dc674fb97c570f57aec06680551183d Mon Sep 17 00:00:00 2001
From: Benno Schulenberg
Date: Sun, 4 Jan 2015 11:23:51 +0100
Subject: [PATCH] Fix the grammar of some comment lines.
* lib/propername.h: Remove a mistaken comma and a duplicate "from",
and use an adequate verb and tense.
---
lib/propername.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/propername.h b/lib/propername.h
index e3ab860..9034d35 100644
--- a/lib/propername.h
+++ b/lib/propername.h
@@ -26,12 +26,12 @@
have in common?
A non-ASCII name. This causes trouble in the --version output. The simple
- "solution", unfortunately mutilates the name.
+ "solution" unfortunately mutilates the name.
- $ du --version| grep Granlund
+ $ du --version | grep Granlund
Ãcrit par Torbjorn Granlund, David MacKenzie, Paul Eggert et Jim Meyering.
- $ ptx --version| grep Pinard
+ $ ptx --version | grep Pinard
Ãcrit par F. Pinard.
What is desirable, is to print the full name if the output character set
@@ -51,11 +51,11 @@
output will look like this:
()
- To use the 'propername' module is done in three simple steps:
+ To use the 'propername' module requires three simple steps:
1) Add it to the list of gnulib modules to import,
- 2) Change the arguments of version_etc, from
+ 2) Change the arguments of version_etc(),
from "Paul Eggert"
to proper_name ("Paul Eggert")
--
1.7.0.4
Re: Vietnamese .po file causes coreutils build failure [Re: bootstrap: TP urls changed
Jim Meyering wrote: > You can argue that the translation project should not publish > such a .po file, and I agree that "upstream" (in the TP > .po-checking code) is the right place to fix this, but can you > get them to fix it quickly I've run the following on all files in the latest/ directory that had the same problem, among them coreutils/ja.po: sed -i '/msgstr\[1\]/d' the.po And checked that they now pass 'msgfmt -c -o /dev/null the.po'. (There's still one coreutils po file for which 'msgfmt -c' reports a fatal error, but I can't see anything wrong with the indicated messages. It might be a bug in 'msgfmt'. coreutils/be.po:2298: number of format specifications in 'msgid' and 'msgstr[0]' does not match coreutils/be.po:2306: number of format specifications in 'msgid' and 'msgstr[0]' does not match msgfmt: found 2 fatal errors) > Request for the TP coordinator: > === > > Would you please consider adding a msgfmt check like the one > above, to prevent publication of any new .po file with that > error? I've just now tried uploading a grep-2.5.1a.nl.po file containing the "...but some messages have 2 plural forms" error -- it gets rejected. So the check is apparently already in place. Benno
