Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

[Paul Eggert]

On 1/31/24 06:06, Pádraig Brady wrote:

To my mind the most protective option takes precedence.


That's not how POSIX works with mv -i and mv -f. The last flag wins. I 
assume this is so that people can have aliases or shell scripts that 
make -i the default, but you can override by specifying -f on the 
command line. E.g., in mymv:


   #!/bin/sh
   mv -i "$@"

then "mymv -f a b" works as expected.

Wouldn't a similar argument apply to cp's --update options?

Or perhaps we should play it safe, and reject any combination of 
--update etc. options that are incompatible. We can always change our 
mind later and say that later options override earlier ones, or do 
something else that's less conservative.

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

[Paul Eggert]

On 2024-01-30 03:18, Pádraig Brady wrote:

So we now have the proposed change as:

   - revert -n to old silent success behavior
   - document -n as deprecated
   - Leave --update=none as is (will be synonymous with -n)
   - Provide --update=none-fail to diagnose and exit failure


Thanks, that's a better proposal, but I still see several opportunities 
for confusion.


If I understand things correctly, cp --update=none is not synonymous 
with the proposed (i.e., old-behavior) cp -n, because -n overrides 
previous -i options but --update=none does not. Also, -n overrides 
either previous or following --update=UPDATE options, but --update=none 
overrides only previous --update=UPDATE options. (For what it's worth, 
FreeBSD -n overrides


Some of this complication seems to be for consistency with how mv 
behaves with -f, -i, -n, and --update, and similarly with how rm behaves 
with -f, -i, -I, and --interactive. To be honest I don't quite 
understand the reason for all this complexity, which suggests it should 
be documented somewhere (the manual?) if it isn't already.


This raises more questions:

* If we deprecate cp -n, what about mv -n? FreeBSD mv -n behaves like 
Coreutils mv -n: it silently does nothing and exits successfully. So 
there's no compatibility argument for changing mv -n's behavior. 
However, whatever --update option we add to cp (to output a diagnostic 
and exit with failure) should surely also be added to mv, to aid 
consistency.


* Should cp --update=none be changed so that it really behaves like the 
old cp -n, in that it overrides other options in ways that differ from 
how the other --update=UPDATE options behave? I'm leaning toward "no" as 
this adds complexity that I don't see the use for.


* If we don't change cp --update=none's overriding behavior, is it still 
OK to tell users to substitute --update=none for -n even though the two 
options are not exactly equivalent? I'm leaning towards "yes" but would 
like other opinions.

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

[Paul Eggert]

On 1/29/24 08:11, Pádraig Brady wrote:


Right, that's why I'm still leaning towards my proposal in the last mail.


Well, I won't insist on doing nothing; however, the proposal needs 
ironing out and now's a good time to do it before installing changes.




   - revert to previous exit success -n behavior
   - document -n as deprecated
   - provide --update=noclobber to give exit failure functionality


So --update=noclobber would differ in meaning from the deprecated-in-9.5 
--no-clobber, but would agree in meaning with 9.4 --no-clobber? That 
sounds pretty confusing for future users. (And a nit: why should one 
spelling have a hyphen but the other doesn't?)



     - BTW, it probably makes sense to print a diagnostic for each 
skipped file here
   as it's exceptional behavior, for which we're exiting with 
failure for.


Coreutils 9.4 cp -n already does that, no? So I'm not sure what's being 
proposed here.


  $ touch a b
  $ cp -n a b; echo $?
  cp: not replacing 'b'
  1



   - the existing --update=none provides the exit success functionality


It seems to me that this proposal conflates two questions:

* What rules should cp use to decide whether to update a destination?

* When cp decides not to update a destination, what should it do? Exit 
with nonzero status? Output a diagnostic? Both? Neither?


Aren't these independent axes? If so, shouldn't they have independent 
options? For example, since we have --update=older, shouldn't there be a 
way to say "I want to copy A to B only if B is older than A, and I want 
the exit status to be zero only if A was copied to B"?

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

[Paul Eggert]

On 2024-01-28 05:22, Pádraig Brady wrote:

At this stage it seems best for us go back to the original Linux 
behiavor (use case 3),
and to silently deprecate -n in docs to document the portability issues 
with it.


I'm not sure reverting would be best. It would introduce more confusion, 
and would make coreutils incompatible with FreeBSD again.


The recent Debian change indicates that their intent is to move to the 
FreeBSD behavior too. This would improve cross-platform portability and 
I don't think we should discourage that.




  $ cp -n /bin/true tmp
  cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead

This is problematic as:

  - It's noisy


Yes that's a problem, and I doubt whether we should mimic Debian.


  - There is no way to get the behavior of indicating failure if existing files 
present


Yes, it's not a good place to be. Surely current coreutils is better 
than what Debian is doing.



  - The --update=none advice is only portable to newer coreutils


True, but that's not a deal-killer. No advice that we give can be 100% 
portable to all platforms.



We should also provide --update=noclobber for use case 1.
Having the control on the --update option, allows use to more clearly 
deprecate -n.


Adding an --update=noclobber sounds like a good thing to do.

Another possibility is to add a warning that is emitted only at the end 
of 'cp'. The warning would occur only if the exit code differs because 
of this cp -n business. We could stretch things a bit and have a 
configure-time option --enable-compat-warnings that builders like Debian 
could use if they want such warnings.

Bug#1058752: bug#62572: cp --no-clobber behavior has changed

[Paul Eggert]

On 2023-12-16 13:46, Bernhard Voelker wrote:

Whether the implementation is race-prone or not is an internal thing.


I wasn't referring to the internal implementation. I was referring to cp 
users. With the newer Coreutils (FreeBSD) behavior, you can reliably 
write a script to do something if cp -n didn't copy the file because the 
destination already existed. With the older Coreutils behavior you 
cannot do that reliably; there will always be a race condition.

Bug#1058752: bug#62572: cp --no-clobber behavior has changed

[Paul Eggert]

On 2023-12-15 10:49, Michael Stone wrote:

There's no compelling reason to force this change


Well, certainly nobody compelled us at gunpoint

Stlll, Pádraig gave a reasonable summary of why the change was made, 
despite its incompatibility with previous behavior. (One thing I'd add 
is that the FreeBSD behavior is inherently less race-prone.) It seemed 
like a good idea at the time all things considered, and to my mind still 
does.




Essentially the current situation is that -n shouldn't be used if you expect a 
certain behavior for this case and you are writing a script for linux systems. 
Maybe in 10 years you'll be able to assume the new behavior. Better to just 
tell people to not use it at all, and leave the historic behavior alone until 
everyone has stopped using -n entirely.


Even if we tell people not to use -n at all, that doesn't mean we should 
revert to the coreutils 9.1 behavior.


The cat is to some extent out of the bag. Unless one insists on (FreeBSD 
| coreutils 9.2-9.4), or insist on coreutils 7.1-9.1, one should not 
rely on cp -n failing or silently succeeding when the destination 
already exists. This will remain true regardless of whether coreutils 
reverts to its 7.1-9.1 behavior.

Bug#1041588: bug#64773: grep 3.11 -r on 100000+ files fails with "Operation not supported"

[Paul Eggert]

To fix just this bug (as opposed to the other Gnulib-related bugs that 
may be lurking) try applying the attached Gnulib patch to a grep 3.11 
tarball.


Closing the debbugs.gnu.org bug report, as the bug has been fixed upstream.From d4d8abb39eb02c555f062b1f83ffcfac999c582f Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Fri, 5 May 2023 12:02:49 +0200
Subject: [PATCH] dirfd: Fix bogus override (regression 2023-04-26).

Reported by Bjarni Ingi Gislason  in
.

* m4/dirfd.m4 (gl_FUNC_DIRFD): Fix mistake in last change.
---
 ChangeLog   | 7 +++
 m4/dirfd.m4 | 6 +-
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index aaffe12fc1..5f01a52535 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2023-05-05  Bruno Haible  
+
+	dirfd: Fix bogus override (regression 2023-04-26).
+	Reported by Bjarni Ingi Gislason  in
+	.
+	* m4/dirfd.m4 (gl_FUNC_DIRFD): Fix mistake in last change.
+
 2023-05-04  Bruno Haible  
 
 	c32swidth: Add tests.
diff --git a/m4/dirfd.m4 b/m4/dirfd.m4
index d1ee2c7f61..7968b1287c 100644
--- a/m4/dirfd.m4
+++ b/m4/dirfd.m4
@@ -1,4 +1,4 @@
-# serial 27   -*- Autoconf -*-
+# serial 28   -*- Autoconf -*-
 
 dnl Find out how to get the file descriptor associated with an open DIR*.
 
@@ -40,10 +40,6 @@ AC_DEFUN([gl_FUNC_DIRFD],
 HAVE_DIRFD=0
   else
 HAVE_DIRFD=1
-dnl Replace only if the system declares dirfd already.
-if test $ac_cv_have_decl_dirfd = yes; then
-  REPLACE_DIRFD=1
-fi
 dnl Replace dirfd() on native Windows, to support fdopendir().
 AC_REQUIRE([gl_DIRENT_DIR])
 if test $DIR_HAS_FD_MEMBER = 0; then
-- 
2.39.2

Bug#930247: bug#36148: Debian Bug#930247: grep: does not handle backreferences correctly, violating POSIX

[Paul Eggert]

On 12/1/22 17:21, Thorsten Glaser wrote:

Please fix this bug, it’s really bad and embarrassing.


Thanks for reporting it; I wasn't aware of it.

Although you sent your email to 36...@debbugs.gnu.org / 
930247@bugs.debian.9org, your email is reporting a separate bug, and I 
fixed it in the development version of GNU grep by installing the 
attached patch. This patch should appear in the next GNU grep release.


I suggest not closing the original bug reports, since the original bug 
remains. Of course fixes are welcome but they are lower priority.From b061d24916fb9a14da37a3f2a05cb80dc65cfd38 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 5 Dec 2022 14:16:45 -0800
Subject: [PATCH] grep: bug: backref in last of multiple patterns

* NEWS: Mention this.
* src/dfasearch.c (GEAcompile): Trim trailing newline from
the last pattern, even if it has back-references and follows
a pattern that lacks back-references.
* tests/backref: Add test for this bug.
---
 NEWS|  6 ++
 src/dfasearch.c | 25 -
 tests/backref   |  8 
 3 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/NEWS b/NEWS
index da293a3..6c00b2b 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ GNU grep NEWS-*- outline -*-
 
 * Noteworthy changes in release ?.? (-??-??) [?]
 
+** Bug fixes
+
+  When given multiple patterns the last of which has a back-reference,
+  grep no longer sometimes mistakenly matches lines in some cases.
+  [Bug#36148#13 introduced in grep 3.4]
+
 
 * Noteworthy changes in release 3.8 (2022-09-02) [stable]
 
diff --git a/src/dfasearch.c b/src/dfasearch.c
index a71902a..a5b0d90 100644
--- a/src/dfasearch.c
+++ b/src/dfasearch.c
@@ -281,20 +281,19 @@ GEAcompile (char *pattern, idx_t size, reg_syntax_t syntax_bits,
   if (compilation_failed)
 exit (EXIT_TROUBLE);
 
-  if (prev <= patlim)
+  if (patlim < prev)
+buflen--;
+  else if (pattern < prev)
 {
-  if (pattern < prev)
-{
-  idx_t prevlen = patlim - prev;
-  buf = xirealloc (buf, buflen + prevlen);
-  memcpy (buf + buflen, prev, prevlen);
-  buflen += prevlen;
-}
-  else
-{
-  buf = pattern;
-  buflen = size;
-}
+  idx_t prevlen = patlim - prev;
+  buf = xirealloc (buf, buflen + prevlen);
+  memcpy (buf + buflen, prev, prevlen);
+  buflen += prevlen;
+}
+  else
+{
+  buf = pattern;
+  buflen = size;
 }
 
   /* In the match_words and match_lines cases, we use a different pattern
diff --git a/tests/backref b/tests/backref
index 510e130..97cb157 100755
--- a/tests/backref
+++ b/tests/backref
@@ -43,4 +43,12 @@ if test $? -ne 2 ; then
 failures=1
 fi
 
+# https://bugs.gnu.org/36148#13
+echo 'Total failed: 2 (1 ignored)' |
+grep -e '^Total failed: 0$' -e '^Total failed: \([0-9]*\) (\1 ignored)$'
+if test $? -ne 1 ; then
+echo "Backref: Multiple -e test, test #5 failed"
+failures=1
+fi
+
 Exit $failures
-- 
2.38.1

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Paul Eggert]

On 2022-11-06 11:32, Eli Zaretskii wrote:

My question was whether in this scenario, since the parent Emacs
exits, the child Emacs can get SIGHUP, simply because its parent
exited and the read end of the PTY no longer exists.


Yes, my sense from the few experiments I tried, is that it's a plausible 
scenario, though I never observed it actually happening for Emacs doing 
a subprocess compile.

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Paul Eggert]

On 2022-11-05 22:51, Eli Zaretskii wrote:


But is it possible for a program like Emacs to get SIGHUP in such a
situation, or is that highly improbable?  We have standard streams of
the inferior Emacs process connected via PTYs to the parent process, I
believe -- does that deliver SIGHUP or SIGPIPE when the parent exits?


It depends on the OS and the app that invokes Emacs and how that app 
itself was invoked. It's a hairy area.


On a POSIX platform it's certainly *possible* for Emacs to get SIGHUP in 
that situation, because a user can invoke the shell command 'kill -s HUP 
P', where P is the process ID of the inferior Emacs. Whether it's 
*likely* is a bit harder to say. I ran a few little experiments on 
Fedora 36 and Ubuntu 22.10 and found SIGHUP being sent in a few 
situations and not others and didn't have the time or patience to suss 
out exactly why or when.

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Paul Eggert]

On 2022-11-04 00:00, Eli Zaretskii wrote:

We need to establish what is the
source of SIGHUP in these cases.  "These cases" mean, AFAIU, the
situations where Emacs launched an async subprocess to do native
compilation (which is another Emacs process in a --batch session), and
the parent Emacs session is terminated by the user before the async
compilation runs to completion.  Would the child Emacs process get
SIGHUP in this scenario?


Hard for me to say. It's a messy area, with kernels (and Emacs itself) 
sending SIGHUP on various whims.


Does the attached patch fix things? It builds on your commit 
190a6853708ab22072437f6ebd93beb3ec1a9ce6 dated 2020-12-04; I don't know 
why that earlier patch was installed, but it would seem to apply to 
SIGHUP and SIGTERM as well as it applies to SIGINT.diff --git a/src/emacs.c b/src/emacs.c
index 1b2aa9442b..92e2299a04 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -432,9 +432,9 @@ terminate_due_to_signal (int sig, int backtrace_limit)
   if (sig == SIGTERM || sig == SIGHUP || sig == SIGINT)
 	{
 	  /* Avoid abort in shut_down_emacs if we were interrupted
-		 by SIGINT in noninteractive usage, as in that case we
+		 in noninteractive usage, as in that case we
 		 don't care about the message stack.  */
-	  if (sig == SIGINT && noninteractive)
+	  if (noninteractive)
 		clear_message_stack ();
 	  Fkill_emacs (make_fixnum (sig), Qnil);
 	}

Bug#1019724: bug#57604: Bug#1019724: warning: stray \ before - causes autopkgtest failure

[Paul Eggert]

On 9/19/22 05:32, Santiago Ruano Rincón wrote:


as you can read below, there are 4235 packages including the
warning in their build logs. Funnily, grep is also in the list :-)


Grep is on the list because Debian indirectly requires ucf to build 
Grep, and ucf issues the warning about stray \ because ucf mistakenly 
uses a Perlism in a grep regular expression 
. This particular warning doesn't break 
anything; it merely alerts installers of a screwup that happens to work 
but relies on undefined results.


We're thinking about adding a configure-time option to Grep to disable 
warnings about egrep/fgrep, to address the original Grep bug report 
. I'm not so sure about disabling warnings 
about bad escapes, as these warnings are so often a win and so rarely a 
loss, as is the case with ucf. Of course there is a tradeoff here 
between (a) having to wade through a bunch of annoying warnings, and (b) 
fixing packages so that they don't rely on undefined results.


Since the main issue here seems to be libtool-related test failures, how 
about patching libtool and letting the affected packages use the patched 
libtool? You can find a patch here:


https://savannah.gnu.org/patch/index.php?10282
https://savannah.gnu.org/patch/download.php?file_id=53720

The libtool test failures are false alarms, so another option would be 
to ignore the failures until libtool gets fixed.



For more on this thorny topic, please see:

https://www.gnu.org/software/grep/manual/html_node/Problematic-Expressions.html

The stray \ issue is the 19th bullet.

Bug#922552: [bug-diffutils] bug#36488: diffutils 3.7 make check failure ppc64le opensuse on colors test

[Paul Eggert]

On 8/28/21 8:40 AM, Thiago Jung Bauermann via bug-diffutils via All 
diffutils discussion. wrote:



I believe this is the same problem reported in bug 34519.
The Debian build also fails with "diff: standard output: Broken pipe".


Thanks for tracking that down. Frédéric's analysis in 
<https://bugs.debian.org/922552#19> was helpful.


I found some time to look into this bug, and installed into 
Savannah.gnu.org diffutils the attached patch, which I hope fixes the 
bug although I don't have the relevant platform to test it. Please give 
it a try.


Once this patch is part of a release, Debian shouldn't need any patches 
for diffutils.


For now I am closing the diffutils bug report 
<https://bugs.gnu.org/36488>; if I was too optimistic and the patch 
doesn't fix things we can always reopen it.
From 9b20182d48481c7ca647ff8926feeb8e1da4f7b0 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 28 Aug 2021 23:49:32 -0700
Subject: [PATCH] diff: cleanup signal handling just before exit
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This should fix an unlikely signal handling bug with colored
output, and should also fix a Debian FTBFS (Fails To Build From
Source) on powerpc64le-linux.  See Bug#34519 and Frédéric
Bonnard’s report in:
https://bugs.debian.org/922552#19
* bootstrap.conf (gnulib_modules): Add raise, sigprocmask.
* src/diff.c (main): Call cleanup_signal_handlers before exiting.
Don’t bother calling ‘exit’; no longer needed nowadays.
* src/util.c (sigprocmask, siginterrupt) [!SA_NOCLDSTOP]:
Define to 0 instead of empty, since the results are now used.
(sigset_t) [!SA_NOCLDSTOP]: Remove; we now rely on Gnulib.
(xsigaction) [SA_NOCLDSTOP]: New function.
(xsigaddset, xsigismember, xsignal, xsigprocmask): New functions.
(some_signals_caught): New static var.
(process_signals): Omit a conditional branch.
Don’t bother loading interrupt_signal if stop_signal_count is nonzero.
(process_signals, install_signal_handlers):
Check for failures from sigprocmask etc.
(sig, nsig): Now at top level, since multiple functions need them.
(install_signal_handlers): No need for caught_sig array;
just use caught_signals.  However, set some_signals_caught.
(cleanup_signal_handlers): New function.
---
 bootstrap.conf |   2 +
 src/diff.c |   2 +-
 src/diff.h |   1 +
 src/util.c | 187 -
 4 files changed, 127 insertions(+), 65 deletions(-)

diff --git a/bootstrap.conf b/bootstrap.conf
index 6560e9a..e51b2d8 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -65,11 +65,13 @@ mktime
 nstrftime
 progname
 propername
+raise
 rawmemchr
 readme-release
 regex
 sh-quote
 signal
+sigprocmask
 stat
 stat-macros
 stat-time
diff --git a/src/diff.c b/src/diff.c
index a4e5538..3b901aa 100644
--- a/src/diff.c
+++ b/src/diff.c
@@ -853,7 +853,7 @@ main (int argc, char **argv)
   print_message_queue ();
 
   check_stdout ();
-  exit (exit_status);
+  cleanup_signal_handlers ();
   return exit_status;
 }
 
diff --git a/src/diff.h b/src/diff.h
index 03f00a6..f346b43 100644
--- a/src/diff.h
+++ b/src/diff.h
@@ -388,6 +388,7 @@ extern struct change *find_change (struct change *);
 extern struct change *find_reverse_change (struct change *);
 extern enum changes analyze_hunk (struct change *, lin *, lin *, lin *, lin *);
 extern void begin_output (void);
+extern void cleanup_signal_handlers (void);
 extern void debug_script (struct change *);
 extern void fatal (char const *) __attribute__((noreturn));
 extern void finish_output (void);
diff --git a/src/util.c b/src/util.c
index dd6d3bf..8e676c8 100644
--- a/src/util.c
+++ b/src/util.c
@@ -31,10 +31,9 @@
present.  */
 #ifndef SA_NOCLDSTOP
 # define SA_NOCLDSTOP 0
-# define sigprocmask(How, Set, Oset) /* empty */
-# define sigset_t int
+# define sigprocmask(How, Set, Oset) 0
 # if ! HAVE_SIGINTERRUPT
-#  define siginterrupt(sig, flag) /* empty */
+#  define siginterrupt(sig, flag) 0
 # endif
 #endif
 
@@ -160,16 +159,63 @@ print_message_queue (void)
 }
 }
 
-/* The set of signals that are caught.  */
 
+#if SA_NOCLDSTOP
+static void
+xsigaction (int sig, struct sigaction const *restrict act,
+	struct sigaction *restrict oact)
+{
+  if (sigaction (sig, act, oact) != 0)
+pfatal_with_name ("sigaction");
+}
+#endif
+
+static void
+xsigaddset (sigset_t *set, int sig)
+{
+  if (sigaddset (set, sig) != 0)
+pfatal_with_name ("sigaddset");
+}
+
+static bool
+xsigismember (sigset_t const *set, int sig)
+{
+  int mem = sigismember (set, sig);
+  if (mem < 0)
+pfatal_with_name ("sigismember");
+  assume (mem == 1);
+  return mem;
+}
+
+typedef void (*signal_handler) (int);
+static signal_handler
+xsignal (int sig, signal_handler func)
+{
+  signal_handler h = signal (sig, func);
+  if (h == SIG_ERR)
+pfatal_with_name ("signal");
+  return h;
+}
+
+static void
+xsigprocmask (int how, sigset_t const *restrict set, sig

Bug#897653: tar 1.30 breaks pristine-tar

[Paul Eggert]

On 05/14/2018 07:56 AM, Antonio Terceiro wrote:

I still need to study the  > code a bit further to try to come up with a better 
suggestion.
Sorry, the only suggestion I can make is that you should just use the 
new GNU tar. The old one was obviously busted and it generated busted 
tarballs.

Bug#851934: bug#23035: date: regression in timezone printing (+%Z)

[Paul Eggert]

Thanks for the heads-up. Rather than add that tzset call, which is a bit of a 
hack, I'd rather make parse_datetime2 more reentrant so that it's immune to this 
problem. So I installed this:


http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=4e6e16b3f43ce96302b1e52e48730c1f15e18c14

into Gnulib to improve the parse_datetime2 API, and installed the attached 
patches into coreutils. This uncovered a bug in one of our recently-added test 
cases, which the attached patches also fix.
From 22767d84c2d80a66d2fc886f55872616432b786d Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Fri, 20 Jan 2017 18:08:03 -0800
Subject: [PATCH 1/2] build: update gnulib submodule to latest

---
 gnulib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnulib b/gnulib
index 0e68c6a..4e6e16b 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 0e68c6a37ed08fc553dd6fb097d97d798dcfa40d
+Subproject commit 4e6e16b3f43ce96302b1e52e48730c1f15e18c14
-- 
2.9.3

From 8b1bb0fa4859ff8460c9f7ecb94ce411d9baa9b3 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Fri, 20 Jan 2017 18:24:02 -0800
Subject: [PATCH 2/2] date: fix TZ= regression

Problem reported by Paul Wise for Debian, in:
https://bugs.debian.org/851934
This is fallout from the fix for GNU Bug#23035.
* src/date.c (batch_convert): New args TZ and TZSTRING.
All uses changed.
(batch_convert, main): Adjust to parse_datetime2 API change.
(main): Allocate time zone object.
* tests/misc/date-debug.sh: Fix incorrect test case,
caught by the fix.
* tests/misc/date.pl: Test the fix.
---
 src/date.c   | 14 +-
 tests/misc/date-debug.sh |  4 ++--
 tests/misc/date.pl   |  6 ++
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/src/date.c b/src/date.c
index eed0901..eb7c624 100644
--- a/src/date.c
+++ b/src/date.c
@@ -286,7 +286,8 @@ Show the local time for 9AM next Friday on the west coast of the US\n\
Return true if successful.  */
 
 static bool
-batch_convert (const char *input_filename, const char *format, timezone_t tz)
+batch_convert (const char *input_filename, const char *format,
+   timezone_t tz, char const *tzstring)
 {
   bool ok;
   FILE *in_stream;
@@ -320,7 +321,8 @@ batch_convert (const char *input_filename, const char *format, timezone_t tz)
   break;
 }
 
-  if (! parse_datetime2 (, line, NULL, parse_datetime_flags))
+  if (! parse_datetime2 (, line, NULL,
+ parse_datetime_flags, tz, tzstring))
 {
   if (line[line_length - 1] == '\n')
 line[line_length - 1] = '\0';
@@ -502,10 +504,11 @@ main (int argc, char **argv)
 }
 }
 
-  timezone_t tz = tzalloc (getenv ("TZ"));
+  char const *tzstring = getenv ("TZ");
+  timezone_t tz = tzalloc (tzstring);
 
   if (batch_file != NULL)
-ok = batch_convert (batch_file, format, tz);
+ok = batch_convert (batch_file, format, tz, tzstring);
   else
 {
   bool valid_date = true;
@@ -545,7 +548,8 @@ main (int argc, char **argv)
   if (set_datestr)
 datestr = set_datestr;
   valid_date = parse_datetime2 (, datestr, NULL,
-parse_datetime_flags);
+parse_datetime_flags,
+tz, tzstring);
 }
 }
 
diff --git a/tests/misc/date-debug.sh b/tests/misc/date-debug.sh
index 06de8dd..48f4605 100755
--- a/tests/misc/date-debug.sh
+++ b/tests/misc/date-debug.sh
@@ -48,10 +48,10 @@ date: new date/time = '(Y-M-D) 1990-12-14 00:00:00 TZ=+09:00'
 date: '(Y-M-D) 1990-12-14 00:00:00 TZ=+09:00' = 661100400 epoch-seconds
 date: after time adjustment (+0 hours, -90 minutes, +0 seconds, +0 ns),
 date: new time = 661095000 epoch-seconds
-date: output timezone: -06:00 (set from TZ="America/Belize" environment value)
+date: output timezone: +09:00 (set from TZ="Asia/Tokyo" environment value)
 date: final: 661095000.0 (epoch-seconds)
 date: final: (Y-M-D) 1990-12-13 13:30:00 (UTC0)
-date: final: (Y-M-D) 1990-12-13 07:30:00 (output timezone TZ=-06:00)
+date: final: (Y-M-D) 1990-12-13 22:30:00 (output timezone TZ=+09:00)
 Thu Dec 13 07:30:00 CST 1990
 EOF
 
diff --git a/tests/misc/date.pl b/tests/misc/date.pl
index 519c247..f026909 100755
--- a/tests/misc/date.pl
+++ b/tests/misc/date.pl
@@ -291,6 +291,12 @@ my @Tests =
   {ERR => "date: invalid date 'TZ=\"\"\"'\n"},
   {EXIT => 1},
  ],
+
+ # https://bugs.debian.org/851934#10
+ ['cross-TZ-mishandled', "-d 'TZ=\"EST5\" 1970-01-01 00:00'",
+  {ENV => 'TZ=PST8'},
+  {OUT => 'Wed Dec 31 21:00:00 PST 1969'},
+ ],
 );
 
 # Repeat the cross-dst test, using Jan 1, 2005 and every interval from 1..364.
-- 
2.9.3

Bug#842339: [Bug-tar] possible fixes for CVE-2016-6321

[Paul Eggert]

Thanks for the heads-up. Yes, it appears the 2003 change was not sufficiently 
paranoid about ".." in member names. Luckily, the tar manual still documents the 
pre-2003 behavior, so we can restore that behavior as a simple bug fix. I 
installed the attached patch into Savannah as one way to do that. This patch 
causes 'tar' to issue two diagnostics when given a member name containing "..", 
and I suppose tar should be cleaned up at some point to issue just one 
diagnostic. The main thing, though, is that the patch is simple and fixes the 
security gotcha in question.


I don't view this as a serious bug, as the tar manual has long said that you 
should extract untrusted tarballs only into empty directories, and doing that 
forestalls the attack even without this patch. (There are other reasons for this 
longstanding recommendation.)
From 99ceaad4d0efd8669b373e1f542f7205f2548456 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@penguin.cs.ucla.edu>
Date: Sat, 29 Oct 2016 21:04:40 -0700
Subject: [PATCH] When extracting, skip ".." members

* NEWS: Document this.
* src/extract.c (extract_archive): Skip members whose names
contain "..".
---
 NEWS  | 8 +++-
 src/extract.c | 8 
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index caa77bc..07daaa7 100644
--- a/NEWS
+++ b/NEWS
@@ -1,9 +1,15 @@
-GNU tar NEWS - User visible changes. 2016-05-27
+GNU tar NEWS - User visible changes. 2016-10-29
 Please send GNU tar bug reports to <bug-...@gnu.org>
 
 
 version 1.29.90 (Git)
 
+* Member names containing '..' components are now skipped when extracting.
+
+This fixes tar's behavior to match its documentation, and is a bit
+safer when extracting untrusted archives over old files (an unsafe
+practice that the tar manual has long recommended against).
+
 * Report erroneous use of positional options.
 
 During archive creation or update, tar keeps track of positional
diff --git a/src/extract.c b/src/extract.c
index f982433..7904148 100644
--- a/src/extract.c
+++ b/src/extract.c
@@ -1629,12 +1629,20 @@ extract_archive (void)
 {
   char typeflag;
   tar_extractor_t fun;
+  bool skip_dotdot_name;
 
   fatal_exit_hook = extract_finish;
 
   set_next_block_after (current_header);
 
+  skip_dotdot_name = (!absolute_names_option
+		  && contains_dot_dot (current_stat_info.orig_file_name));
+  if (skip_dotdot_name)
+ERROR ((0, 0, _("%s: Member name contains '..'"),
+	quotearg_colon (current_stat_info.orig_file_name)));
+
   if (!current_stat_info.file_name[0]
+  || skip_dotdot_name
   || (interactive_option
 	  && !confirm ("extract", current_stat_info.file_name)))
 {
-- 
2.7.4

Bug#809007: [bug-diffutils] bug#22245: [la...@debian.org: Bug#809007: diffutils: FTBFS: FAIL: test-update-copyright.sh]

[Paul Eggert]

Santiago Vila wrote:

I find a little bit odd that only the left brace is escaped in
the git commit above. Sure, it will remove the warning about the
left brace, but it looks a little bit inconsistent.


It depends on which sort of consistency one wants. I mildly prefer omitting 
backslashes when not needed, as this helps avoid usages like:


grep '\[.*\]' *.c

which has undefined behavior due to the '\]'. Admittedly that's a POSIX regular 
expression, not Perl.

Bug#699325: Emacs 24.3 occasionally crashes (segfault) just after starting it

[Paul Eggert]

I audited the Emacs trunk source code for getenv-related races that have 
undefined behavior and could have the reported symptoms.  I found some other 
races and installed a fix for them as Emacs trunk bzr 118095.  I expect this 
patch to be harder to backport to older Emacs versions, and less urgent as the 
races appear to be less likely.


Since we have fixes installed in the trunk I'll take the liberty of closing the 
Emacs bug report.  Please let us know if the bug occurs even with the fixes; if 
that happens I plan to reopen the bug report and look into it further.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#699325: Emacs 24.3 occasionally crashes (segfault) just after starting it

[Paul Eggert]

The failure scenario described in https://bugs.debian.org/699325#17 was fixed 
in Emacs trunk bzr 111064; see Bug#13054 http://bugs.gnu.org/13054.  This fix 
is in the next Emacs release, and the fix should be easily backportable to older 
Emacs releases.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#404048: unstable, gzip, apt-get dist-upgrade - error

[Paul Eggert]

I installed this:

2006-12-29  Paul Eggert  [EMAIL PROTECTED]

* doc/gzip.texi: Swap order of dircategory entries, to pacify
Debian install-info 1.10.28.  This should fix
http://bugs.debian.org/404048.

--- doc/gzip.texi   8 Dec 2006 18:45:37 -   1.3
+++ doc/gzip.texi   30 Dec 2006 03:15:13 -
@@ -27,15 +27,17 @@ Free Documentation License''.
 @end copying

 @c Debian install-info (up through at least version 1.9.20) uses only the
[EMAIL PROTECTED] first dircategory.  Put this one first, as it is more useful 
in practice.
[EMAIL PROTECTED] Individual utilities
[EMAIL PROTECTED] first dircategory.  But install-info 1.10.28 rejects any 
attempt to
[EMAIL PROTECTED] put the more-useful individual utility first.  So put the 
less-useful
[EMAIL PROTECTED] general category first.
[EMAIL PROTECTED] Utilities
 @direntry
-* gzip: (gzip)Invoking gzip.Compress files.
+* Gzip: (gzip). The gzip command for compressing files.
 @end direntry

[EMAIL PROTECTED] Utilities
[EMAIL PROTECTED] Individual utilities
 @direntry
-* Gzip: (gzip). The gzip command for compressing files.
+* gzip: (gzip)Invoking gzip.Compress files.
 @end direntry

 @titlepage


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#403243: [patch] AC_FUNC_GETMNTENT not defining HAVE_GETMNTENT to 1 but to empty

[Paul Eggert]

Ben Pfaff [EMAIL PROTECTED] writes:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403243

Thanks, I installed that into Autoconf.  Here's the patch
again, for autoconf-patches:

2006-12-15  Paul Eggert  [EMAIL PROTECTED]

* lib/autoconf/functions.m4 (AC_FUNC_GETMNTENT):
Define HAVE_GETMNTENT to 1, not to the empty string.
Problem originally reported by Jochen Friedrich in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403243.

--- lib/autoconf/functions.m4   4 Dec 2006 23:54:25 -   1.117
+++ lib/autoconf/functions.m4   16 Dec 2006 05:38:39 -
@@ -798,7 +798,7 @@
 # -lseq on Dynix/PTX, -lgen on Unixware.
 AC_SEARCH_LIBS(getmntent, [sun seq gen],
   [ac_cv_func_getmntent=yes
-   AC_DEFINE([HAVE_GETMNTENT], [],
+   AC_DEFINE([HAVE_GETMNTENT], 1,
  [Define to 1 if you have the `getmntent' function.])],
   [ac_cv_func_getmntent=no])
 ])



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#366660: gzip unlinks input before closing output, results in data loss

[Paul Eggert]

This bug has now been fixed upstream, here:

ftp://alpha.gnu.org/gnu/gzip/gzip-1.3.6.tar.gz

The upstream version should have all the fixes in Debian's 1.3.5-15
package.  However, upstream doesn't have functionality improvements
like --rsyncable; just bug fixes for now.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#395466: AM_PATH_CHECK causes possibly undefined macro errors

[Paul Eggert]

Ralf Wildenhues [EMAIL PROTECTED] writes:

 It is broken, the bug should be moved to this package, and
 to fix it, the package should add something like
   m4_pattern_allow([^AM_PATH_CHECK$])
 to its macro.

I agree that the bug should be moved to the 'check' package.

As I understand it, the 'check' maintainers already know that it is
broken to use AM_PATH_CHECK, and have renamed it to PKG_CHECK_MODULES.
The code in question is merely a backwards-compatibility reminder to
users that they shouldn't use the old AM_PATH_CHECK macro any more.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#385720: m4: INTERNAL ERROR: recursive push_string (fwd)

[Paul Eggert]

Eric Blake [EMAIL PROTECTED] writes:

 In the meantime, perhaps Autoconf should document that
 all autom4te input files should always end in newline.

Nh.  Let's just fix the bug in M4.  It's clearly a bug.
The GNU tradition is to handle arbitrary input files,
and not to insist on text files in the POSIX sense.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#372179: AC_CANONICAL_SYSTEM overwrites $@

[Paul Eggert]

Ralf Wildenhues [EMAIL PROTECTED] writes:

 What do the other Autoconf developers think about this?  Safe enough to
 apply now, or postpone until after 2.60 (and require the APR people to
 keep (ab)using Autoconf internal interfaces, and dragging along a
 modified version of the _AC_INIT_PARSE_ARGS macro)?

Personally, I'd wait.  Even if you say the new interface is
undocumented and unsupported, if you publish 2.60 that way, either
people will switch from the old undocumented method to the new
undocumented method (in which case you're stuck with the new one, and
you don't want this), or people will not switch (in which case why
bother?).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#372241: Bug#372179: marked as done (autoconf: AC_CANONICAL_SYSTEM overwrites $@)

[Paul Eggert]

Stepan Kasal [EMAIL PROTECTED] writes:

 I agree that we should document this limitation.  I would document
 that any Autoconf macro can change the positional parameters.

That's what I did in the patch I installed yesterday
http://lists.gnu.org/archive/html/autoconf-patches/2006-06/msg00065.html.

 There is only one question: should we make the commitment that
 AC_INIT leaves the parameters untached or not?

Yes (the patch yesterday says that).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#372179: AC_CANONICAL_SYSTEM overwrites $@

[Paul Eggert]

Tollef Fog Heen [EMAIL PROTECTED] writes:

 Apart from the «ewww» factor, why can't it do its work in a subshell
 and echo back the parameters to be set and those get eval-ed by
 configure?

Yes, something like that might work, given that you know the values
can't contain ' (though you should probably check this).

It's unlikely that we'll buy the change back into Autoconf, though.

Bug#372179: AC_CANONICAL_SYSTEM overwrites $@

[Paul Eggert]

Ben Pfaff [EMAIL PROTECTED] writes:

 In the long term, I suspect that the Autoconf macros in the
 apr-util package should be fixed, and that autoconf-doc should
 document that $@ may be changed by some macros.

I've done the latter by installing the patch at the end of this
message into Autoconf CVS.

 In the short term, I'm willing to help out, if necessary, by putting
 some kind of Debian-specific patch that saves and restores the
 positional parameters (if indeed there's a way to do that) around
 AC_CANONICAL_SYSTEM.

I don't know of any portable, reliable way to do it in general,
but you can approximate it by doing something like this:

   # Save $@.
   args=
   for arg
   do
 case $arg in
 *\'*) arg=`echo $arg | sed s/'/'''/g`;;
 esac
 args=$args '$arg'
   done

   # Restore $@.
   eval set x $args
   shift

But even this isn't correct in general, e.g., it mishandles args
containing backslashes, or equal to '-n', or with trailing newlines.

Here's the patch I installed.

2006-06-14  Paul Eggert  [EMAIL PROTECTED]

* doc/autoconf.texi (Initializing configure, Shell Substitutions):
Warn about $@ not persisting.  Problem reported by Julien Danjou in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372179.

--- doc/autoconf.texi   14 Jun 2006 05:14:09 -  1.1044
+++ doc/autoconf.texi   14 Jun 2006 19:11:21 -
@@ -1747,6 +1747,14 @@ Exactly @var{bug-report}.
 @end table
 @end defmac
 
+If your @command{configure} script does its own option processing, it
+should inspect @samp{$@@} or @samp{$*} immediately after calling
[EMAIL PROTECTED], because other Autoconf macros liberally use the
[EMAIL PROTECTED] command to process strings, and this has the side effect
+of updating @samp{$@@} and @samp{$*}.  However, we suggest that you use
+standard macros like @code{AC_ARG_ENABLE} instead of attempting to
+implement your own option processing.  @xref{Site Configuration}.
+
 
 @node Notices
 @section Notices in @command{configure}
@@ -11297,6 +11305,11 @@ case $# in
 esac
 @end example
 
+Autocoonf macros often use the @command{set} command to update
[EMAIL PROTECTED]@@}, so if you are writing shell code intended for
[EMAIL PROTECTED] you should not assume that the value of @samp{$@@}
+persists for any length of time.
+
 
 @item [EMAIL PROTECTED]@}
 @cindex positional parameters


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]