output of 'date' is not properly localized
Hi,
On http://www.opengroup.org/onlinepubs/95399/utilities/date.html
it says under the examples:
$ LANG=da_DK.iso_8859-1 date
ons 02 okt 1991 15:03:32 CET
But when coreutils' current date is used (with LC_TIME and LC_ALL
unset):
$ LANG=da_DK.utf8 src/date
søn aug 31 13:21:21 CEST 2008
The day and month are reversed and the year is at the end instead of
after the month. For Dutch the same misformat is used: an American
format with only the abbreviations translated to Dutch.
date uses 'nl_langinfo (_DATE_FMT)', but the manpage for nl_langinfo
does not mention _DATE_FMT; it only lists D_T_FMT, D_FMT and T_FMT.
After applying the attached first patch (changing _DATE_FMT to
D_T_FMT) things are correct (using libc-2.7):
$ LANG=da_DK.utf8 date
søn 31 aug 2008 13:24:32 CEST
The second patch removes a comment that seems mistaken, because it
doesn't take into account that LC_TIME could be for example da_DK.
Alternatively, it could let translators specify a fallback format
by doing something like this:
setlocale (LC_MESSAGES, getlocale (LC_TIME));
format = _(%a %b %e %H:%M:%S %Z %Y);
setlocale (LC_ALL, );
Benno
From 5e17acc09261e16e747c58583510d66549185c5a Mon Sep 17 00:00:00 2001
From: Benno Schulenberg [EMAIL PROTECTED]
Date: Sun, 31 Aug 2008 13:09:52 +0200
Subject: [PATCH] date: call nl_langinfo with proper argument
---
src/date.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/date.c b/src/date.c
index 3cfcc62..4e84a5f 100644
--- a/src/date.c
+++ b/src/date.c
@@ -109,8 +109,8 @@ static struct option const long_options[] =
# define TZSET /* empty */
#endif
-#ifdef _DATE_FMT
-# define DATE_FMT_LANGINFO() nl_langinfo (_DATE_FMT)
+#ifdef D_T_FMT
+# define DATE_FMT_LANGINFO() nl_langinfo (D_T_FMT)
#else
# define DATE_FMT_LANGINFO()
#endif
--
1.5.6.4
From 46bff8f13ff524fcdfc8d969b8a739b70405f44f Mon Sep 17 00:00:00 2001
From: Benno Schulenberg [EMAIL PROTECTED]
Date: Sun, 31 Aug 2008 13:34:06 +0200
Subject: [PATCH] date: correct a non-localization comment
---
src/date.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/date.c b/src/date.c
index 4e84a5f..2eccef0 100644
--- a/src/date.c
+++ b/src/date.c
@@ -451,13 +451,8 @@ main (int argc, char **argv)
format = DATE_FMT_LANGINFO ();
if (! *format)
{
- /* Do not wrap the following literal format string with _(...).
- For example, suppose LC_ALL is unset, LC_TIME=POSIX,
- and LANG=ko_KR. In that case, POSIX says that LC_TIME
- determines the format and contents of date and time strings
- written by date, which means date must generate output
- using the POSIX locale; but adding _() would cause date
- to use a Korean translation of the format. */
+ /* Do not wrap the following literal format string with _(); it
+ is a fallback format for when localization isn't working. */
format = %a %b %e %H:%M:%S %Z %Y;
}
}
--
1.5.6.4
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Double include of getopt.h in env.c and groups.c (coreutils-6.12)
Is there a reason that getopt.h gets included twice? src/env.c: #include getopt.h #include sys/types.h #include getopt.h src/groups.c: #include getopt.h #include sys/types.h #include pwd.h #include grp.h #include getopt.h ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Double include of getopt.h in env.c and groups.c (coreutils-6.12)
Jerry Snitselaar [EMAIL PROTECTED] wrote: Is there a reason that getopt.h gets included twice? src/env.c: #include getopt.h #include sys/types.h #include getopt.h src/groups.c: #include getopt.h #include sys/types.h #include pwd.h #include grp.h #include getopt.h No. You've just fixed both ;-) Thanks! From 63a7120c283ab4ad6ce204ea47dbe45f561a34c0 Mon Sep 17 00:00:00 2001 From: Jerry Snitselaar [EMAIL PROTECTED] Date: Sun, 31 Aug 2008 15:58:27 +0200 Subject: [PATCH] env, groups: remove duplicate inclusion of getopt.h * src/env.c: Remove redundant #include. * src/groups.c: Likewise. Tiny change. --- src/env.c|1 - src/groups.c |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/env.c b/src/env.c index 67e411f..97bec71 100644 --- a/src/env.c +++ b/src/env.c @@ -78,7 +78,6 @@ #include config.h #include stdio.h -#include getopt.h #include sys/types.h #include getopt.h diff --git a/src/groups.c b/src/groups.c index c71667b..907af1c 100644 --- a/src/groups.c +++ b/src/groups.c @@ -19,7 +19,6 @@ #include config.h #include stdio.h -#include getopt.h #include sys/types.h #include pwd.h #include grp.h -- 1.6.0.1.157.g7df43 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tee logs no output if stdout is closed
Hi Jim,
On 2008-07-01 you replied to a proposed new 'tee' option that makes it ignore
SIGPIPE in
http://lists.gnu.org/archive/html/bug-coreutils/2008-07/msg5.html:
Thanks for the patch, but I'm reluctant to use it
in part because it covers only the write syscalls deriving
from tee's explicit fwrite call. It does not handle
an EPIPE failure that comes of a close_stdout-induced
write syscall, so you'd still get the offending diagnostics
some of the time.
Right. close_stdout and more generally close_stream should be changed to
handle an EPIPE failure. An EPIPE errno value means that the kernel is telling
the program This pipe/socket has no readers any more. You can stop writing
to it. But in close_stream we are already stopping the output to this
pipe/socket. There's no point in signalling an error about this situation.
Also, if the reader process terminated only a moment later, the fflush and
fclose would succeed, and the output would land in the kernel's pipe buffer
and be discarded at that place.
I'm therefore proposing
- a gnulib patch to ignore EPIPE in close_stream,
- a coreutils patch to add option '-p' to 'tee'. Revised so that when _all_
output destinations of 'tee' have no readers any more, 'tee' terminates
with SIGPIPE (like all reasonable filter programs that have only 1 output
destination do).
Both patches are attached.
Bruno
2008-08-31 Bruno Haible [EMAIL PROTECTED]
New tee option -p.
* src/tee.c (ignore_sigpipe): New variable.
(long_options): Add option -p.
(usage): Document option -p.
(main): Handle option -p.
(tee_files): When option -p is specified, ignore SIGPIPE write errors
until the last open output descriptor is closed.
* doc/coreutils.texi (tee invocation): Document option -p.
--- src/tee.c.orig 2008-08-31 17:22:12.0 +0200
+++ src/tee.c 2008-08-31 17:15:15.0 +0200
@@ -41,10 +41,14 @@
/* If true, ignore interrupts. */
static bool ignore_interrupts;
+/* If true, ignore failed writes to pipes with no readers. */
+static bool ignore_sigpipe;
+
static struct option const long_options[] =
{
{append, no_argument, NULL, 'a'},
{ignore-interrupts, no_argument, NULL, 'i'},
+ {ignore-sigpipe, no_argument, NULL, 'p'},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{NULL, 0, NULL, 0}
@@ -64,6 +68,7 @@
\n\
-a, --append append to the given FILEs, do not overwrite\n\
-i, --ignore-interrupts ignore interrupt signals\n\
+ -p, --ignore-sigpipe ignore failed writes to pipes with no readers\n\
), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
@@ -93,7 +98,7 @@
append = false;
ignore_interrupts = false;
- while ((optc = getopt_long (argc, argv, ai, long_options, NULL)) != -1)
+ while ((optc = getopt_long (argc, argv, aip, long_options, NULL)) != -1)
{
switch (optc)
{
@@ -105,6 +110,10 @@
ignore_interrupts = true;
break;
+ case 'p':
+ ignore_sigpipe = true;
+ break;
+
case_GETOPT_HELP_CHAR;
case_GETOPT_VERSION_CHAR (PROGRAM_NAME, AUTHORS);
@@ -117,6 +126,9 @@
if (ignore_interrupts)
signal (SIGINT, SIG_IGN);
+ if (ignore_sigpipe)
+signal (SIGPIPE, SIG_IGN);
+
/* Do *not* warn if tee is given no file arguments.
POSIX requires that it work when given no arguments. */
@@ -135,6 +147,7 @@
tee_files (int nfiles, const char **files)
{
FILE **descriptors;
+ size_t num_open_descriptors;
char buffer[BUFSIZ];
ssize_t bytes_read;
int i;
@@ -161,6 +174,7 @@
descriptors[0] = stdout;
files[0] = _(standard output);
setvbuf (stdout, NULL, _IONBF, 0);
+ num_open_descriptors = 1;
for (i = 1; i = nfiles; i++)
{
@@ -173,7 +187,10 @@
ok = false;
}
else
- setvbuf (descriptors[i], NULL, _IONBF, 0);
+ {
+ setvbuf (descriptors[i], NULL, _IONBF, 0);
+ num_open_descriptors++;
+ }
}
while (1)
@@ -192,9 +209,41 @@
if (descriptors[i]
fwrite (buffer, bytes_read, 1, descriptors[i]) != 1)
{
- error (0, errno, %s, files[i]);
- descriptors[i] = NULL;
- ok = false;
+ if (ignore_sigpipe errno == EPIPE)
+ {
+ /* Could not write to a pipe with no readers.
+ Close the stream. */
+ fclose (descriptors[i]);
+ /* Close also the underlying file descriptor, to avoid an
+ error message from close_stdout. */
+ if (fileno (descriptors[i]) = 0)
+ close (fileno (descriptors[i]));
+ descriptors[i] = NULL;
+ if (--num_open_descriptors == 0)
+ {
+ /* All output descriptors are closed. We have no reason
+ to continue reading input any more. Raise a SIGPIPE
+ and terminate. */
+ sigset_t sigpipe_set;
+
+ sigemptyset (sigpipe_set);
+ sigaddset (sigpipe_set, SIGPIPE);
+ sigprocmask (SIG_UNBLOCK, sigpipe_set, NULL);
+
+ signal (SIGPIPE, SIG_DFL);
+
+ raise (SIGPIPE);
+
+ /* raise didn't terminate? So force a termination. */
+ goto
Re: Patch to fix data loss with `tail -F'
On Mon, Aug 18, 2008 at 08:13:09PM -0700, Jos Backus wrote: https://savannah.gnu.org/patch/index.php?6612 Please let me know if you see any issues with this change; I'd like to see it adopted for the next coreutils release. *bump* -- Jos Backus jos at catnook.com ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
cut - lack of --merge-delimiters option
coreutils program cut could use a merge delimiters option. Common use case: ls -l | cut ... One needs to print 7-th column of ls -l to see all times of modifications. But there is no constant number of delimiters between column, eg: drwxr-xr-x 23 user group 4096 Mar 16 2006 user drwx-- 2 root root 16384 Dec 19 2003 lost+found merge delimiters option would help a lot in such cases. Without it users are forced to use gawk instead of cut. Are any chances for introducing enhancements like that to coreutils? Thanks, Jan ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Patch to fix data loss with `tail -F'
On Sun, Aug 31, 2008 at 08:07:54PM +0200, Jim Meyering wrote: Jos Backus [EMAIL PROTECTED] wrote: https://savannah.gnu.org/patch/index.php?6612 Please let me know if you see any issues with this change; I'd like to see it adopted for the next coreutils release. Thank you! You're welcome! It will be great to see this change make it into coreutils. That looks like a useful patch. Can you write a small stand-alone script or outline a simple procedure for demonstrating the failure? I'd like to check in a test for the failure along with the fix. Hm, that might not be easy. Did you have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=101979cat=bin ? It outlines my test setup, including the few scripts that were used to detect data loss and verify that the fix indeed works. If daemontools/runit is installed it's a matter of setting up two services and watching their output. Would that be sufficient? -- Jos Backus jos at catnook.com ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cut - lack of --merge-delimiters option
On Sun, Aug 31, 2008 at 07:10:55PM +0200, Jan Skowron wrote: coreutils program cut could use a merge delimiters option. I would rather just be able to use a regexp as a delimiter, which would solve this problem and more. BTW, what's wrong with using AWK? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
descriptions of 'who' differ
Hi, The texts from 'who --help' and 'info who' say different things. The latter does not mention the options -p, -r and -t. It further mentions -H twice, does not list -l, --login and --lookup in their alphabetical positions, and says that -s is ignored, but it is not entirely: it overrides -u. Finally, 'who --help' does not describe the -u option very well: list users logged in. That is the default behaviour. Better would be: also show idle time and PID. (By the way, the description of the -l option on 'man 1p who' is not good: List only those lines on which the system is waiting for someone to login. It cannot be only when -a combines -l with other options. It had better say: List the lines) Benno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cut - lack of --merge-delimiters option
Jan Skowron wrote: coreutils program cut could use a merge delimiters option. Common use case: ls -l | cut ... One needs to print 7-th column of ls -l to see all times of modifications. But there is no constant number of delimiters between If you are only interested in times, why not ask the tool for just that information, e.g. stat -c %y * merge delimiters option would help a lot in such cases. Without it users are forced to use gawk instead of cut. And what's wrong with that? Or stated differently, awk is a standard and portable tool, whereas new version of cut with new option that isn't yet present on many systems isn't. Based on traffic on this list it seems there is still a large number of people using coreutils 5.x which is more than 2 years old at best. Any new option that gets added thus has this waiting period of a number of years before it can be reasonably assumed to be in common use. And even then, people that want to write portable scripts still can't use the option, because it won't be in other 'cut' implementations, such as Darwin's or Sun's or the BSD's, etc. In short: adding options to standard commands when a portable solution already exists does not make a lot of sense, and the coreutils maintainers are very resistant to doing it as a result. Brian ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
final batch of tiny string fixes [patches]
Hi,
Attached the last of the series of tiny fixes for string problems
that I found while updating the Dutch translation for coreutils.
To clarify the change to some strings of uptime.c: some languages
may want to put the translation of up after the uptime instead of
in front; having the up in an unrelated string makes this awkward.
So the patch moves it to the relevant strings, even though this
means some duplication.
Benno
From 4e00ae1354aa80baebf5ac3d2e1efc2c2a779ef3 Mon Sep 17 00:00:00 2001
From: Benno Schulenberg [EMAIL PROTECTED]
Date: Wed, 20 Aug 2008 22:24:38 +0200
Subject: [PATCH] md5sum: avoid possible double singular/plural in warning messages
In many languages in N out of M files failed not only files needs to
be singular or plural depending on M, but also failed needs a singular
or plural form depending on N. Avoid this complication and only say how
many files failed; the total number of files is not really interesting
anyway and only makes the message less clear.
---
src/md5sum.c | 26 +-
1 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/src/md5sum.c b/src/md5sum.c
index 238c02e..8bdbe97 100644
--- a/src/md5sum.c
+++ b/src/md5sum.c
@@ -570,25 +570,17 @@ digest_check (const char *checkfile_name)
{
if (n_open_or_read_failures != 0)
error (0, 0,
- ngettext (WARNING: % PRIuMAX of % PRIuMAX
- listed file could not be read,
- WARNING: % PRIuMAX of % PRIuMAX
- listed files could not be read,
- select_plural (n_properly_formatted_lines)),
- n_open_or_read_failures, n_properly_formatted_lines);
+ ngettext (WARNING: % PRIuMAX file could not be read,
+ WARNING: % PRIuMAX files could not be read,
+ select_plural (n_open_or_read_failures)),
+ n_open_or_read_failures);
if (n_mismatched_checksums != 0)
- {
- uintmax_t n_computed_checksums =
- (n_properly_formatted_lines - n_open_or_read_failures);
- error (0, 0,
- ngettext (WARNING: % PRIuMAX of % PRIuMAX
- computed checksum did NOT match,
- WARNING: % PRIuMAX of % PRIuMAX
- computed checksums did NOT match,
- select_plural (n_computed_checksums)),
- n_mismatched_checksums, n_computed_checksums);
- }
+ error (0, 0,
+ ngettext (WARNING: % PRIuMAX checksum did NOT match,
+ WARNING: % PRIuMAX checksums did NOT match,
+ select_plural (n_mismatched_checksums)),
+ n_mismatched_checksums);
}
}
--
1.5.6.4
From 3ef36c72666f7a6c1bc732c99d192bce8923a698 Mon Sep 17 00:00:00 2001
From: Benno Schulenberg [EMAIL PROTECTED]
Date: Wed, 20 Aug 2008 22:44:33 +0200
Subject: [PATCH] pinky: gettextize two missed strings
Additionally differentiate the strings for unknown idle time and
unknown real name so they can be translated differently.
---
src/pinky.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/pinky.c b/src/pinky.c
index 382f30f..8a7fe8b 100644
--- a/src/pinky.c
+++ b/src/pinky.c
@@ -250,7 +250,8 @@ print_entry (const STRUCT_UTMP *utmp_ent)
name[UT_USER_SIZE] = '\0';
pw = getpwnam (name);
if (pw == NULL)
- printf ( %19s, ???);
+ /* TRANSLATORS: Real name is unknown; at most 19 characters. */
+ printf ( %19s, _(???));
else
{
char *const comma = strchr (pw-pw_gecos, ',');
@@ -273,7 +274,8 @@ print_entry (const STRUCT_UTMP *utmp_ent)
if (last_change)
printf ( %-6s, idle_string (last_change));
else
- printf ( %-6s, ???);
+ /* TRANSLATORS: Idle time is unknown; at most 5 characters. */
+ printf ( %-6s, _(?));
}
printf ( %s, time_string (utmp_ent));
@@ -328,6 +330,7 @@ print_long_entry (const char name[])
printf (_(In real life: ));
if (pw == NULL)
{
+ /* TRANSLATORS: Real name is unknown; no hard limit. */
printf ( %s, _(???\n));
return;
}
--
1.5.6.4
From cc5f373ae5a7e0ea1186cb565c4147f2a155844e Mon Sep 17 00:00:00 2001
From: Benno Schulenberg [EMAIL PROTECTED]
Date: Wed, 20 Aug 2008 22:40:03 +0200
Subject: [PATCH] od: avoid concatening two messages without a newline
Better make them into two separate paragraphs.
Also make the explanation of multiplier suffixes clearer.
---
src/od.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/od.c b/src/od.c
index 5b4b7bd..ac515dd 100644
--- a/src/od.c
+++ b/src/od.c
@@ -385,13 +385,13 @@ for sizeof(double) or L for sizeof(long double).\n\
\n\
RADIX is d for decimal, o for octal, x for hexadecimal or n for none.\n\
BYTES is hexadecimal with 0x or 0X prefix, and may have a multiplier suffix:\n\
-b 512, kB 1000, K 1024, MB 1000*1000, M 1024*1024,\n\
-GB 1000*1000*1000, G 1024*1024*1024, and so on for T, P, E, Z, Y.\n\
+b =512, kB =1000, K =1024, MB =1000*1000, M =1024*1024,\n\
+GB =1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y.\n\
Adding a z suffix to any type displays printable
Re: cut - lack of --merge-delimiters option
On Sun, Aug 31, 2008 at 6:10 PM, Jan Skowron [EMAIL PROTECTED] wrote: coreutils program cut could use a merge delimiters option. Common use case: ls -l | cut ... One needs to print 7-th column of ls -l to see all times of modifications. But there is no constant number of delimiters between column, eg: drwxr-xr-x 23 user group 4096 Mar 16 2006 user drwx-- 2 root root 16384 Dec 19 2003 lost+found merge delimiters option would help a lot in such cases. Without it users are forced to use gawk instead of cut. For this use case you should be using stat --printf or find -printf. Parsing the dates produced by ls is problematic anyway: ~$ ( LC_ALL=C ls -ld ~/source/rekall ~/source/SimCity ) drwxr-xr-x 3 james users 4096 Sep 1 02:09 /home/james/source/SimCity drwxr-xr-x 24 james users 4096 Mar 22 2004 /home/james/source/rekall James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cut - lack of --merge-delimiters option
regexp would slower CUT a little. Merging delimiters will be as quick as current CUT. AWK is bit slower too, slower to write comand, and slower to execute. If you ask me, I would add to CUT regexp and merging delimiters, as separate options. You've asked whats wrong with using AWK. Nothing is wrong, but CUT, TR, GREP, BC, JOIN and many more exists even if you can do anything with AWK. On Sun, Aug 31, 2008 at 22:02, Dan Hipschman [EMAIL PROTECTED] wrote: On Sun, Aug 31, 2008 at 07:10:55PM +0200, Jan Skowron wrote: coreutils program cut could use a merge delimiters option. I would rather just be able to use a regexp as a delimiter, which would solve this problem and more. BTW, what's wrong with using AWK? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cut - lack of --merge-delimiters option
On Sun, Aug 31, 2008 at 10:52:13PM +0200, Jan Skowron wrote: regexp would slower CUT a little. Merging delimiters will be as quick as current CUT. AWK is bit slower too, slower to write comand, and slower to execute. If you ask me, I would add to CUT regexp and merging delimiters, as separate options. You've asked whats wrong with using AWK. Nothing is wrong, but CUT, TR, GREP, BC, JOIN and many more exists even if you can do anything with AWK. By the way, merging delimiters can be done easily with tr -s ' ' | cut -d ' ' It is unlikely this option would be allowed in cut, then, as the tools are designed to be small and used together. Execution speed is probably not a good enough reason. If you wanted anything like this to run super fast, the shell would not be an ideal solution. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
