Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c
Eric Blake <[EMAIL PROTECTED]> wrote: ... > Subject: [PATCH] csplit: prefer sigaction over signal > > * bootstrap.conf (gnulib_modules): Import sigaction. > * src/csplit.c (sigprocmask, siginterrupt) [SA_NOCLDSTOP]: Delete > workarounds. > (interrupt_handler, main): Drop use of signal. Rely on sigaction > to block fatal signal during cleanup, and to restore it to default > in case of nested signals. Impeccable! Thank you. Please push it. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding bug-gnulib] According to Jim Meyering on 10/16/2008 1:30 AM: > Eric Blake <[EMAIL PROTECTED]> wrote: > ... >> Subject: [PATCH] csplit: prefer sigaction over signal >> >> * bootstrap.conf (gnulib_modules): Import sigaction. >> * src/csplit.c (sigprocmask, siginterrupt) [SA_NOCLDSTOP]: Delete >> workarounds. >> (interrupt_handler, main): Drop use of signal. Rely on sigaction >> to block fatal signal during cleanup, and to restore it to default >> in case of nested signals. > > Impeccable! > Thank you. Please push it. Done. Meanwhile, back to my original question: According to Eric Blake on 10/13/2008 10:18 PM: > Round 1: csplit. The use of signal here mirrors what Bruno's fatal-signal > module in gnulib provides, although the set of signals masked is > different. Which would you prefer, a patch that swaps over to > fatal-signal usage (leaving at least SIGPOLL and SIGALRM unprotected), or > this patch? I'm kind of leaning towards simplifying this file by using > fatal-signal, but had already written this, and wanted some feedback. > When used in a library, the gnulib fatal-signal module must assume that the rest of the program can use SIGPOLL and SIGALRM for its own purposes. But when used in a stand-alone app, such as csplit, where it is known in advance that these signals are not used, it would be nice to include them in the set of fatal signals. In other words, right now, csplit is _not_ using fatal-signals, because it wants to react to additional signals beyond the default provided by the gnulib module. Is there a way we could extend the API of fatal-signals to allow an application to request that SIGPOLL and SIGALRM be added to the set of signals to react to? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj3Mh4ACgkQ84KuGfSFAYD5FgCggtmDZhyYJM9vggcVQJuJuDZ+ aE8An0toPdDJdzN15j1G5zHmuMbADD+T =ZQSs -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 10/10/2008 7:15 AM: >> I've wanted to get rid of "signal" uses for ages. >> Are you interested in doing it? > > Yes, I'll tackle this. Round 2 begins with a question. src/install.c has the following use of signal, needed on the code path that invokes strip(1) as a child process: #ifdef SIGCHLD /* System V fork+wait does not work if SIGCHLD is ignored. */ signal (SIGCHLD, SIG_DFL); #endif I just checked POSIX, and this is entirely true - the exec*() family is allowed to inherit an ignored SIGCHLD, in deference to older systems like SysV; and wait()/waitpid() are allowed to fail with ECHILD if SIGCHLD is ignored. But most systems these days explicitly set SIGCHLD to SIG_DFL on fork; are there still any modern systems where the explicit signal change is needed? I see several options for this code in order to remove the use of signal: 1. delete the signal altogether, on the assumption that no modern system inherits an ignored SIGCHLD 2. switch to sigaction to force SIGCHLD to SIG_DFL 3. switch to the gnulib execute module, which makes this code portable to mingw (the current fork/exec sequence excludes mingw, which lacks fork), and in the process isolates the portability problem of ignored SIGCHLD to gnulib and makes it so that install.c need not mess with at all I'm kind of leaning towards option 3, but want some agreement before proceeding, as it is certainly more invasive to the current code, even though it adds more portability as a result. But in looking at the gnulib code for execute.c, I don't see any mention of this SIGCHLD anomaly, where wait/waitpid fail if SIGCHLD is ignored. On the other hand, gnulib's execute module uses waitid rather than waitpid; I guess that this choice of API is immune to the SysV behavior? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj3PJQACgkQ84KuGfSFAYDb5ACfT34DqsCuMcdXfPnkuZ3N0wkf EgkAmwYW8OMR53sJAdTggjOPvZ1BEfhY =u7oV -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] build: when po-check fails, say why and suggest a fix
A colleague noticed in libvirt that the output of a failed po-check rule
was unnecessarily cryptic. Here's a fix:
>From 089424f94e5be30aa0ec8d7f5293ff314def4de1 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Thu, 16 Oct 2008 14:22:46 +0200
Subject: [PATCH] build: when po-check fails, say why and suggest a fix
* maint.mk (po-check): Before, when this check failed, it just
spat out a diff mentioning two temporary files. Now, it tells
you what's wrong and suggests a fix with a patch using the name
of the affected file (rather than temporary file names) in the
diff output.
---
maint.mk | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/maint.mk b/maint.mk
index 8db32d9..2752486 100644
--- a/maint.mk
+++ b/maint.mk
@@ -597,10 +597,15 @@ m4-check:
&& { echo '$(ME): quote the first arg to AC_DEFUN' 1>&2; \
exit 1; } || :
+fix_po_file_diag = \
+'you have changed the set of files with translatable diagnostics;\n\
+apply the above patch\n'
+
# Verify that all source files using _() are listed in po/POTFILES.in.
+po_file = po/POTFILES.in
po-check:
- @if test -f po/POTFILES.in; then\
- grep -E -v '^(#|$$)' po/POTFILES.in \
+ @if test -f $(po_file); then\
+ grep -E -v '^(#|$$)' $(po_file) \
| grep -v '^src/false\.c$$' | sort > [EMAIL PROTECTED];
\
files=; \
for file in $$($(VC_LIST_EXCEPT)) lib/*.[ch]; do \
@@ -617,7 +622,8 @@ po-check:
done; \
grep -E -l '\b(N?_|gettext *)\([^)"]*("|$$)' $$files \
| sort -u > [EMAIL PROTECTED];
\
- diff -u [EMAIL PROTECTED] [EMAIL PROTECTED] || exit 1;
\
+ diff -u -L $(po_file) -L $(po_file) [EMAIL PROTECTED] [EMAIL
PROTECTED] \
+ || { printf '$(ME): '$(fix_po_file_diag) 1>&2; exit 1; }; \
rm -f [EMAIL PROTECTED] [EMAIL PROTECTED];
\
fi
--
1.6.0.2.98.gc82e
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c
Eric Blake <[EMAIL PROTECTED]> wrote: > According to Eric Blake on 10/10/2008 7:15 AM: >>> I've wanted to get rid of "signal" uses for ages. >>> Are you interested in doing it? >> >> Yes, I'll tackle this. > > Round 2 begins with a question. src/install.c has the following use of > signal, needed on the code path that invokes strip(1) as a child process: > > #ifdef SIGCHLD > /* System V fork+wait does not work if SIGCHLD is ignored. */ > signal (SIGCHLD, SIG_DFL); > #endif > > I just checked POSIX, and this is entirely true - the exec*() family is > allowed to inherit an ignored SIGCHLD, in deference to older systems like > SysV; and wait()/waitpid() are allowed to fail with ECHILD if SIGCHLD is > ignored. But most systems these days explicitly set SIGCHLD to SIG_DFL on > fork; are there still any modern systems where the explicit signal change > is needed? > > I see several options for this code in order to remove the use of signal: > 1. delete the signal altogether, on the assumption that no modern system > inherits an ignored SIGCHLD > 2. switch to sigaction to force SIGCHLD to SIG_DFL > 3. switch to the gnulib execute module, which makes this code portable to > mingw (the current fork/exec sequence excludes mingw, which lacks fork), > and in the process isolates the portability problem of ignored SIGCHLD to > gnulib and makes it so that install.c need not mess with at all > > I'm kind of leaning towards option 3, but want some agreement before > proceeding, as it is certainly more invasive to the current code, even > though it adds more portability as a result. Invasive for a good cause ;-) #3 sounds like it's worth a try, at least. > But in looking at the gnulib code for execute.c, I don't see any mention > of this SIGCHLD anomaly, where wait/waitpid fail if SIGCHLD is ignored. > On the other hand, gnulib's execute module uses waitid rather than > waitpid; I guess that this choice of API is immune to the SysV behavior? Coreutils has a test for the install bug that prompted adding the signal call: tests/install/trap, so at worst, we should discover quickly whether execute.c needs a similar work-around. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
od -tx1|-tx2|-to1|-to2 output problem
When using od with output formats of 1 or 2 bytes, the printed
output
can be wrong, particularly--but not exclusively--with non-printing
characters. Specifically, the output is sometimes printed as an
asterisk
('*') instead of the regular output--the whole line being affected. For
example, on Cygwin (the most current 1.5.25-15):
$ od --version
od (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Jim Meyering.
$ print -n '\0112\0106\0111\0106\\0001\0001\\\0001' | od
-toC -w1
000 112
001 106
002 111
003 106
004 000
005 001
*
007 000
*
011 001
012
I get an identical result on RHEL3 with od version 4.5.3. (I'm using
ksh,
so ksh print is in effect for this example. On Linux echo -n -e can
also
be used. My specific Linux version is Red Hat Linux 3.2.3-59, kernel
2.4.21-57.EL.) In fact, in all cases that I checked on both, the
results
are identical for my two computers.
The problem also happens if the -w1 option is left off, but it does
not occur in the same places. For example (in which you can see that
the
short example above is a subset from the end of the first line):
$ od -tx1 -Ax exp.jpg | head -10
00 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01
10 00 01 00 00 ff db 00 84 00 08 06 06 07 06 05 08
20 07 07 07 09 09 08 0a 0c 14 0d 0c 0b 0b 0c 19 12
30 13 0f 14 1d 1a 1f 1e 1d 1a 1c 1c 20 24 2e 27 20
40 22 2c 23 1c 1c 28 37 29 2c 30 31 34 34 34 1f 27
50 39 3d 38 32 3c 2e 33 34 32 01 09 09 09 0c 0b 0c
60 18 0d 0d 18 32 21 1c 21 32 32 32 32 32 32 32 32
70 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
*
90 32 32 32 32 32 32 32 32 32 32 ff c0 00 0b 08 01
The line that is omitted is all 0x32 (a repeat of line 0x70). (Every
JPEG file that I tried demonstrates the problem, by the way. For that
matter, every file that is long enough demonstrates it.)
The problem happens with -to1, -toC, -tx1, -txC, -to2, and -tx2.
The output line that gets corrupted is the same whether o or x is
chosen.
It happens more often with respect to byte count when -w1 is used.
It does happen with plain text files, too, but not quite as often.
Because I have seen identical results with two different versions
on
two different OSs, I am sending this to coreutils rather than to
either of the two OS owners, as it sure seems to not be OS related.
Craig Howland
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: od -tx1|-tx2|-to1|-to2 output problem
"Howland Craig D (Craig)" <[EMAIL PROTECTED]> wrote: > When using od with output formats of 1 or 2 bytes, the printed > output > can be wrong, particularly--but not exclusively--with non-printing Thank you for the report. However, that is standard and required behavior. To turn it off, use -v (aka --output-duplicates). $ printf abbbc |od -aAn -w1 a b * c $ printf abbbc |od -vaAn -w1 a b b b c >From "info coreutils od" `-v' `--output-duplicates' Output consecutive lines that are identical. By default, when two or more consecutive output lines would be identical, `od' outputs only the first line, and puts just an asterisk on the following line to indicate the elision. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: od -tx1|-tx2|-to1|-to2 output problem
Howland Craig D (Craig) wrote:
> When using od with output formats of 1 or 2 bytes, the printed
> output can be wrong, particularly--but not exclusively--with
> non-printing characters. Specifically, the output is sometimes
> printed as an asterisk ('*') instead of the regular output--the
> whole line being affected.
Does adding -v resolve your problem? I think it is just what you are
looking for here.
info coreutils 'od invocation'
`-v'
`--output-duplicates'
Output consecutive lines that are identical. By default, when two
or more consecutive output lines would be identical, `od' outputs
only the first line, and puts just an asterisk on the following
line to indicate the elision.
http://www.opengroup.org/onlinepubs/009695399/utilities/od.html
-v
Write all input data. Without the -v option, any number of groups
of output lines, which would be identical to the immediately
preceding group of output lines (except for the byte offsets),
shall be replaced with a line containing only an asterisk ( '*' ).
As it turns out the traditional legacy behavior of the original 'od'
program is to collapse "uninteresting" output into a "*" line. That
is just the way that it has always been. But you can turn it off.
> $ print -n '\0112\0106\0111\0106\\0001\0001\\\0001' | od -toC -w1
Thank you for the nice small example for discussion. That was great!
Just fyi but note that 'print' isn't portable and 'print -n' even less
so. ('echo' is okay for simple strings but is worse for escape
sequences.) Use of the standard 'printf' is strongly encouraged when
printing escape characters. It can be used portably.
> Because I have seen identical results with two different
> versions on two different OSs, I am sending this to coreutils rather
> than to either of the two OS owners, as it sure seems to not be OS
> related.
Sure! Hope this helps.
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: problem with bootstrapping coreutils with automake 1.10.1
Jim Meyering <[EMAIL PROTECTED]> writes: > 1.10a is deemed (at least by automake and m4) to indicate a newer > version than 1.10.1. counter-intuitive? This matters because > sort --version now disagrees with that ordering: > > $ printf 'automake-1.10%s\n' .1 a|sort -V > automake-1.10a > automake-1.10.1 Sigh. I suppose we should get to the bottom of this. GNU tools should agree on how to compare version numbers. Personally, I would have expected the behavior of sort -V; I'm surprised that other tools disagree. > This stems from the new gnulib filevercmp module. > > There's actually a minor dependency in coreutils on the > newer automake. By "newer" do you mean "newer than 1.10.1"? If so, do you recall which post-1.10.1 feature is being used by coreutils? If that feature is important I suppose I should upgrade to automake 1.10a. (I assume 1.10a refers the latest bleeding-edge version checked out from Savannah?) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: problem with bootstrapping coreutils with automake 1.10.1
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> 1.10a is deemed (at least by automake and m4) to indicate a newer >> version than 1.10.1. counter-intuitive? This matters because >> sort --version now disagrees with that ordering: >> >> $ printf 'automake-1.10%s\n' .1 a|sort -V >> automake-1.10a >> automake-1.10.1 > > Sigh. I suppose we should get to the bottom of this. GNU tools should > agree on how to compare version numbers. Personally, I would have > expected the behavior of sort -V; I'm surprised that other tools > disagree. > >> This stems from the new gnulib filevercmp module. >> >> There's actually a minor dependency in coreutils on the >> newer automake. > > By "newer" do you mean "newer than 1.10.1"? Yes. 1.10a is newer. > If so, do you recall which > post-1.10.1 feature is being used by coreutils? If that feature is Two things come to mind, but there may be more. Neither of these is a show-stopper: One change fixes a "make distcheck" failure. Another that is merely an optimization is the fact that it now relies on latest automake for efficient multi-file installation, i.e., install f1 f2 f3 ... destdir, rather than running install separately for each installed file. > important I suppose I should upgrade to automake 1.10a. (I assume 1.10a > refers the latest bleeding-edge version checked out from Savannah?) Yes. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH x 5] warnings, some legit
Jim Meyering <[EMAIL PROTECTED]> writes:
> +#define TMP (char *) "/tmp"
> ...
How about the following change to mktemp.c instead? It's simpler, and
avoids the need for the macro and the cast.
2008-10-16 Paul Eggert <[EMAIL PROTECTED]>
* src/mktemp.c (main): Add 'const' twice to avoid GCC warning.
diff --git a/src/mktemp.c b/src/mktemp.c
index 0555d41..ffb21d4 100644
--- a/src/mktemp.c
+++ b/src/mktemp.c
@@ -126,8 +126,8 @@ mkdtemp_len (char *tmpl, size_t suff_len, bool dry_run)
int
main (int argc, char **argv)
{
- char *dest_dir;
- char *dest_dir_arg = NULL;
+ char const *dest_dir;
+ char const *dest_dir_arg = NULL;
bool suppress_stderr = false;
int c;
unsigned int n_args;
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] : ls: clarify documentation of exit statuses
Jim Meyering <[EMAIL PROTECTED]> writes: > Good thing I tried to compile before pushing! > The above lacks \n\ on the "0 if OK" line. It's also lacking a close-parenthesis in the text. Also, that wording is a bit verbose for my taste; the verbosity makes it a bit hard to see the exit-status pattern. How about this more-concise version? 2008-10-16 Paul Eggert <[EMAIL PROTECTED]> * src/ls.c (usage): Describe exit statuses more concisely. diff --git a/src/ls.c b/src/ls.c index ea35b17..34e43ed 100644 --- a/src/ls.c +++ b/src/ls.c @@ -4532,10 +4532,8 @@ colors, and can be set easily by the dircolors command.\n\ \n\ Exit status:\n\ 0 if OK,\n\ - 1 if minor problems (e.g., failure to access a file or directory not\n\ -specified as a command line argument,\n\ - 2 if serious trouble (e.g., memory exhausted, invalid option or failure\n\ -to access a file or directory specified as a command line argument).\n\ + 1 if minor problems (e.g., cannot access subdirectory),\n\ + 2 if serious trouble (e.g., cannot access command-line argument).\n\ "), stdout); emit_bug_reporting_address (); } ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] : ls: clarify documentation of exit statuses
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> Good thing I tried to compile before pushing! >> The above lacks \n\ on the "0 if OK" line. > > It's also lacking a close-parenthesis in the text. Also, that wording > is a bit verbose for my taste; the verbosity makes it a bit hard to see > the exit-status pattern. How about this more-concise version? > > 2008-10-16 Paul Eggert <[EMAIL PROTECTED]> > > * src/ls.c (usage): Describe exit statuses more concisely. Sure. I too prefer the look of yours. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH x 5] warnings, some legit
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> +#define TMP (char *) "/tmp" >> ... > > How about the following change to mktemp.c instead? It's simpler, and > avoids the need for the macro and the cast. > > 2008-10-16 Paul Eggert <[EMAIL PROTECTED]> > > * src/mktemp.c (main): Add 'const' twice to avoid GCC warning. Ahh... much better. no-casts is always better. Thanks! I've just pushed that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c
Eric Blake <[EMAIL PROTECTED]> writes: > I just checked POSIX, and this is entirely true - the exec*() family is > allowed to inherit an ignored SIGCHLD, in deference to older systems like > SysV; and wait()/waitpid() are allowed to fail with ECHILD if SIGCHLD is > ignored. But most systems these days explicitly set SIGCHLD to SIG_DFL on > fork; are there still any modern systems where the explicit signal change > is needed? I'd be a bit leery of assuming this. It was such a pervasive problem back in the day. I'd be a bit surprised if the problem were eliminated from all modern systems in all compilation modes. > But in looking at the gnulib code for execute.c, I don't see any mention > of this SIGCHLD anomaly, where wait/waitpid fail if SIGCHLD is ignored. > On the other hand, gnulib's execute module uses waitid rather than > waitpid; I guess that this choice of API is immune to the SysV behavior? Yes, I expect so. The simplest thing is to leave install.c alone. Porting to mingw is low priority, surely. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH x 5] warnings, some legit
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Here's a 5-patch series from a week or so ago.
> It started out with the aim to avoid some warnings.
> Some of those warnings were legitimate.
>
> At first I was tempted to simply ignore any freopen failure,
> thinking that it was so unlikely as to be truly ignorable.
> And in addition, most are guarded by "if (O_BINARY &&...",
> so wouldn't even be compiled on systems I care about.
> However, there are actually many ways in which freopen can
> fail, so I wrote xfreopen and used that everywhere.
>
> Feedback welcome.
> I'll wait a day or two, just in case...
...
>>From 6fc767036a513dad05c43cca2253e7f0a1c3cde0 Mon Sep 17 00:00:00 2001
> From: Jim Meyering <[EMAIL PROTECTED]>
> Date: Sun, 12 Oct 2008 16:09:00 +0200
> Subject: [PATCH] mktemp: diagnose freopen failure
>
> * src/mktemp [--quiet]: Don't ignore freopen failure.
> ---
> src/mktemp.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/src/mktemp.c b/src/mktemp.c
> index 295d134..8998f5c 100644
> --- a/src/mktemp.c
> +++ b/src/mktemp.c
> @@ -190,7 +190,9 @@ main (int argc, char **argv)
> {
>/* From here on, redirect stderr to /dev/null.
> A diagnostic from getopt_long, above, would still go to stderr. */
> - freopen ("/dev/null", "wb", stderr);
> + if (!freopen ("/dev/null", "wb", stderr))
> +error (EXIT_FAILURE, errno,
> + _("failed to redirect stderr to /dev/null"));
> }
>
>n_args = argc - optind;
> --
> 1.6.0.2.98.gc82e
I've pushed this one.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [coreutils] coreutils-7.0 expr exposes long-standing bug in matlab startup script
Excellent stuff. You got a net reduction of 366 lines,
and another 91 lines are not used in the common case
where GMP is available.
I'm a bit worried by signed overflow checking in the following.
I know gcc won't do it's ignore undefined signed overflow
code shenanigans with this, but does this assume 2s compliment
architectures? If so is this OK?
+static void
+mpz_add (mpz_t r, mpz_t a0, mpz_t b0)
+{
+ intmax_t a = a0[0];
+ intmax_t b = b0[0];
+ intmax_t val = a + b;
+ if ((val < a) != (b < 0))
+integer_overflow ('+');
What about the INT_MIN/-1 exception case in the following.
Oh I see it's short circuited in that case.
This code deserves an award for brevity or something :)
+mpz_mul (mpz_t r, mpz_t a0, mpz_t b0)
+{
+ intmax_t a = a0[0];
+ intmax_t b = b0[0];
+ intmax_t val = a * b;
+ if (! (a == 0 || b == 0
+|| ((val < 0) == ((a < 0) ^ (b < 0)) && val / a == b)))
+integer_overflow ('*');
I've attached a patch to standardize the format of the
AUTHORS define to that used in other utils with multiple authors.
I've also added you to the list since you basically rewrote
expr with this patch.
cheers,
Pádraig.
>From 057e83d69a6b212e6aa3c0943065609ab06877c5 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <[EMAIL PROTECTED]>
Date: Thu, 16 Oct 2008 19:09:59 +0100
Subject: [PATCH] expr: Fixup authors
* src/expr.c: Standardise the format of AUTHORS to
that used in other utils with multiple authors.
Also add Paul Eggert since he basically rewrote it
with his bignum fixes.
* AUTHORS (expr): Add Paul Eggert.
---
AUTHORS|2 +-
src/expr.c |5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/AUTHORS b/AUTHORS
index 9c3d990..fa3c029 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -25,7 +25,7 @@ du: Torbjörn Granlund, David MacKenzie, Paul Eggert, Jim Meyering
echo: Brian Fox, Chet Ramey
env: Richard Mlynarik, David MacKenzie
expand: David MacKenzie
-expr: Mike Parker, James Youngman
+expr: Mike Parker, James Youngman, Paul Eggert
factor: Paul Rubin
false: Jim Meyering
fmt: Ross Paterson
diff --git a/src/expr.c b/src/expr.c
index de7a63d..65e74af 100644
--- a/src/expr.c
+++ b/src/expr.c
@@ -145,7 +145,10 @@ mpz_out_str (FILE *stream, int base, mpz_t z)
/* The official name of this program (e.g., no `g' prefix). */
#define PROGRAM_NAME "expr"
-#define AUTHORS proper_name ("Mike Parker"), proper_name ("James Youngman")
+#define AUTHORS \
+ proper_name ("Mike Parker"), \
+ proper_name ("James Youngman"), \
+ proper_name ("Paul Eggert")
/* Exit statuses. */
enum
--
1.5.3.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: od -tx1|-tx2|-to1|-to2 output problem
Thanks to both Jim and Bob for the answer. Using -v gives the behavior that I was expecting (and shows that there is not a problem with od, except for what I would consider to be an odd default--which we're stuck with for the historical reasons given). I do have one suggestion/request, though: please explain this behavior better in the man page. Both explanations are good, but they came from the info page. I don't know how most people go about it, but I rarely use info, using man as normal practice. Not being an old-time power user of od, the man page entry of "-v, --output-duplicates do not use * to mark line suppression" meant nothing to me--and with no other mention in the man page of line suppression it wouldn't. Given the bizarre default of suppressing output, I suggest that the better info entry for -v is worth pulling into the man page. Thanks also to Bob for pointing out printf instead of print. I was wondering what was best to use--knowing that print is problematic for portability---but since I started on a mainframe with System V, printf is not in my normal usage pattern. Craig ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request for coreutil paste
Robert C. Kahlert wrote: > File #1: >abc >def >ghi >jkl >mno > > > File #2: >1 >2 > > Output of paste file1 file2 > abc 1 > def 2 > ghi 1 > jkl 2 > mno 1 It can already be done with a combination of 'paste', 'cat', 'head', 'wc': $ while :; do cat file2 || exit; done | head -n `wc -l < file1` | paste file1 - abc 1 def 2 ghi 1 jkl 2 mno 1 If some new options were to be introduced for this use-case, it would be preferrable to introduce two new, more widely applicable options: 1) An option "paste --shortest" that causes 'paste' to terminate when one of the input files has reached its end, 2) An option "yes -f FILE" or "cat --repeat FILE" that has the same effect as (while :; do cat file2 || exit; done) The solution could then be written as $ yes -f file2 | paste --shortest file1 - Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Problem with ubuntu 8.04
I am new to Linux. 20 day ago I installed Ubuntu 8.04 and enjoyed it. 3 days ago I downloaded the recommended updates (120 Mega), after that I also installed Wine, a version found on a magazine I think it was 1.01 or similar). Now when I start ubuntu, after the request of inserting name and password I receive the following message: "user's $Home/.dmrc file being ignored. This prevents the default session and language from being saved. File should be owned by user and have 644 permissions. User's $Home directory must be owned by user and not writable by other users". When I press OK, after a few seconds a second message appears: "The Gnome session manager was unable to lock the file '/home/oreste/.Iceauthority! Please report this as a gnome bug" And after that everything goes back to the request of name and password. I tried different sessions but with no result. Of course I do not know how to use the line commands. Please Help Oreste ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: od -tx1|-tx2|-to1|-to2 output problem
"Howland Craig D (Craig)" <[EMAIL PROTECTED]> wrote: > Thanks to both Jim and Bob for the answer. Using -v gives the behavior > that I was expecting (and shows that there is not a problem with od, > except for what I would consider to be an odd default--which we're stuck > with for the historical reasons given). > > I do have one suggestion/request, though: please explain this behavior > better in the man page. Both explanations are good, but they came from > the info page. I don't know how most people go about it, but I rarely > use info, using man as normal practice. Not being an old-time power > user of od, the man page entry of > "-v, --output-duplicates > do not use * to mark line suppression" > meant nothing to me--and with no other mention in the man page of line > suppression it wouldn't. Given the bizarre default of suppressing > output, > I suggest that the better info entry for -v is worth pulling into the > man page. Sorry, but od's --help output (and man page generated from that) is already one of the longest. It is designed to be a *quick* reference. If we start pulling in full option explanations, it would be less useful in general. We can only hope that people will learn to heed the "SEE ALSO" reference: The full documentation for od is maintained as a Texinfo manual. If the info and od programs are properly installed at your site, the com- mand info coreutils od should give you access to the complete manual. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
