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
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
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
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
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
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
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
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
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
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
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
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 \
art 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
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.
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.
542f7205f2548456 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 "..".
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
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
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
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
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
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
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
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
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
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.
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
., 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
28 matches
Mail list logo
