Re: date command
Felix Joussein [EMAIL PROTECTED] wrote: Hello Jim, Hi Felix, Thanks for the report. It would probably have been resolved by now (10 hours later) if you had sent it to the bug-reporting/discussion list rather than just to me. I'm forwarding it there now. within a project which is related to date/time opeartions I was about to rebuild system which was originaly based on Ret Hat 7.2 Linux to Debian/Etch. The project is almost done when I tried out the following with the date command from Debian/Etch: date -s '01/31/2008 14:20:60' - Invalid date using the date command from the former Red Hat 7.2 date -s '01/31/2008 14:20:60' - Working Apperarently the new date command from Debian/Etch which is of the version /bin/date --version date (GNU coreutils) 5.97 Copyright © 2006 Free Software Foundation, Inc. Dieses Programm ist freie Software. Sie dürfen Kopien davon weitergeben gemäß der GNU General Public License http://www.gnu.org/licenses/gpl.html. Es gibt KEINERLEI GARANTIE, so weit das Gesetz es erlaubt. Geschrieben von David MacKenzie. has problems to interpret the 60th second, whereas the date command from Red Hat 7.1, which is of the version /usr/local/bin/date --version date (GNU sh-utils) 2.0 Written by David MacKenzie. Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. does it perfectly. Basicaly the goal ist, to set back the time at a certain moment for 1 Second. It's all about the leap-second which might be set every last second of the 31th of dec. or 30th of june... Doing this with the new date command the time is set back to 2 seconds rather then one... with the old date command using the minute's 60st second a step-back for one second is possible. Do you have any idea how this may happen? Regads and thanks for your help, -- mit freundlichen Grüßen Felix Joussein Integrated Network Design Firma Felix Joussein [EMAIL PROTECTED] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date command
On Feb 1, 2008 8:24 AM, Jim Meyering [EMAIL PROTECTED] wrote: Basicaly the goal ist, to set back the time at a certain moment for 1 Second. It's all about the leap-second which might be set every last second of the 31th of dec. or 30th of june... Doing this with the new date command the time is set back to 2 seconds rather then one... with the old date command using the minute's 60st second a step-back for one second is possible. Do you have any idea how this may happen? Leap seconds occur in UTC. They are often handled by the kernel (if at all) and a common way to do this is to run an NTP client.See also http://www.cis.udel.edu/~mills/leap.html It is normally not necessary to introduce a manual adjustment with date in order to maintain synchronisation. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Need help understanding sort tests
Andy Jewell [EMAIL PROTECTED] writes: Here are the commands, and the expected output. (The tests are 10f and 10g). sort -t : -k 1.3,1.3 :ba :ab sort -k 1.4,1.4 b ba a ab In both of these cases it seems that the explicit -k matches an empty string, The ranges endpoints are inclusive. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date command
Hello James, thank you for your brief answer. Basically I am aware of what you said, but as I am operating an NTP Server which get it's timescale directly from an ATOM clock via the serial interface, which makes it to a STRATUM 1 server, I have to set the leap second manually by date command or similar to push forward the ntp-server timescale for this one second when ever the IERS announces a leap second. The prior system was running on a Red Hat 7.2 where the date command was able to set the 60th second... unfortunately the version of the coreutils which is shipped in debian/etch does not. I'm helping myself now by using the old date command from the Red Hat distribution which seams to work for my needs but never then less: Why has a 8 year old version of date a feature, which it's actual version doesn't have? I cannot imagine, that the code which is necessary to set the 60th second would blow up the code that much, that the date project-team decides to blow out that code... I'm really confused about that fact! Thank you for helping me with my problem. many regards, Felix Joussein James Youngman schrieb: On Feb 1, 2008 8:24 AM, Jim Meyering [EMAIL PROTECTED] wrote: Basicaly the goal ist, to set back the time at a certain moment for 1 Second. It's all about the leap-second which might be set every last second of the 31th of dec. or 30th of june... Doing this with the new date command the time is set back to 2 seconds rather then one... with the old date command using the minute's 60st second a step-back for one second is possible. Do you have any idea how this may happen? Leap seconds occur in UTC. They are often handled by the kernel (if at all) and a common way to do this is to run an NTP client.See also http://www.cis.udel.edu/~mills/leap.html It is normally not necessary to introduce a manual adjustment with date in order to maintain synchronisation. James. -- mit freundlichen Grüßen Felix Joussein Integrated Network Design Firma Felix Joussein [EMAIL PROTECTED] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date command
On Fri, 1 Feb 2008, Felix Joussein wrote: Basically I am aware of what you said, but as I am operating an NTP Server which get it's timescale directly from an ATOM clock via the serial interface, which makes it to a STRATUM 1 server, I have to set the leap second manually by date command or similar to push forward the ntp-server timescale for this one second when ever the IERS announces a leap second. The prior system was running on a Red Hat 7.2 where the date command was able to set the 60th second... unfortunately the version of the coreutils which is shipped in debian/etch does not. I'm helping myself now by using the old date command from the Red Hat distribution which seams to work for my needs but never then less: Why has a 8 year old version of date a feature, which it's actual version doesn't have? I cannot imagine, that the code which is necessary to set the 60th second would blow up the code that much, that the date project-team decides to blow out that code... Hi Felix, I simply don't think it's possible to use date for the stated goal. There is no built-in historical knowledge of leap seconds for the purposes of allowing the occasional :60 setting - incidentally, the example given 01/31/2008 14:20:60 was not an official leap second. These notes explain how the underlying timers are incremented through a leap second: http://www.cis.udel.edu/~mills/leap.html Once a leap second has passed, effectively the system forgets it ever happened. The following wall-clock timestamps were actually 11 seconds apart, but date shows only a 10 second gap. $ date -u -d '2005-12-31 23:59:55' +%s 1136073595 $ date -u -d '2006-01-01 00:00:05' +%s 1136073605 The right way (I think) for what you're trying to do is obtain in advance a copy of the leapseconds file supported by ntpd; latest version here: http://www.cis.udel.edu/~mills/leap-seconds.3331497600 Stratum-1 clocks need to be told when a leap second is approaching, to propagate this information through the leap bits to their configured slaves. If this is not done correctly the machines will not march in step, and the way the ntp protocol works doesn't allow for spot fixes at or after a discontinuity; the semi-random polling interval would almost guarantee your population of machines would learn of (and apply) the change at different times. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Need help understanding sort tests
In the test suite for sort (coreutils 6.9), there are two tests that seem to be testing for incorrect behavior. I'm hoping someone will help me understand why the behavior in the test is correct. Here are the commands, and the expected output. (The tests are 10f and 10g). sort -t : -k 1.3,1.3 :ba :ab sort -k 1.4,1.4 b ba a ab In both of these cases it seems that the explicit -k matches an empty string, which would compare equal, so it would fall back to the last resort memcmp of the whole line, which would produce the opposite ordering from above. So what am I missing? many thanks, adj ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Need help understanding sort tests
Yes, I know that the range endpoints are inclusive. In the first example, the first field is empty, and so the inclusive character range 3-3 is also empty In the second example, the first field is length one, and so the inclusive character range 4-4 is empty adj On Feb 1, 2008, at 9:33 AM, Andreas Schwab wrote: Andy Jewell [EMAIL PROTECTED] writes: Here are the commands, and the expected output. (The tests are 10f and 10g). sort -t : -k 1.3,1.3 :ba :ab sort -k 1.4,1.4 b ba a ab In both of these cases it seems that the explicit -k matches an empty string, The ranges endpoints are inclusive. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort: memory exhausted with 50GB file
On Sun, 27 Jan 2008, Paul Eggert wrote: Leo Butler [EMAIL PROTECTED] writes: wc is counting with long ints, and the first line of this 50GB file is a string of \0 whose length appears to be negative when counted with long ints. (Details below). I believe that this must be an error in the header file where 'uintmax_t' is defined. If the header misdefines uintmax_t, that will break several programs in coreutils, not just 'wc' (or 'sort', for that matter). Can you investigate why this is happening? You can build coreutils 6.10 from scratch and look in config.log to see why it is mishandling uintmax_t. I inferred the error from the symptoms and I wrote before testing the inference. I have since checked and uintmax_t appears to be correctly defined. I believe that the coreutils info documentation could benefit from an explicit definition of 'characters' vs. 'bytes' in the documentation of wc and allied programs. It took me a rather long time to infer the correct definition but once I knew it, the diagnosis was trivial. I needn't have bothered you folks at all... LB ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] mkdir/split: send --verbose output to stdout
FWIW, make distcheck still fails...
Steven Schubiger
diff --git a/ChangeLog b/ChangeLog
index 62c7930..459aa46 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2008-02-01 Steven Schubiger [EMAIL PROTECTED]
+
+ * src/mkdir.c: Send --verbose output to stdout.
+ * src/split.c: Likewise.
+ Update texinfo documentation for split.
+ Adjust tests for mkdir/split.
+ * tests/mkdir/p-v: Capture verbose output which previously was
+ being emitted to stderr from stdout.
+ * tests/misc/split-a: Likewise.
+
2008-01-31 Bob Proulx [EMAIL PROTECTED]
Improve wording of date and time man page.
diff --git a/TODO b/TODO
index a442620..3cec054 100644
--- a/TODO
+++ b/TODO
@@ -46,14 +46,6 @@ And once that's done, add an exclusion so that `cp --link'
no longer incurs the overhead of saving src. dev/ino and dest. filename
in the hash table.
-See if we can be consistent about where --verbose sends its output:
- These all send --verbose output to stdout:
-head, tail, rm, cp, mv, ln, chmod, chown, chgrp, install, ln
- These send it to stderr:
-shred mkdir split
- shred must write --verbose output to stderr
- readlink is different
-
Write an autoconf test to work around build failure in HPUX's 64-bit mode.
See notes in README -- and remove them once there's a work-around.
diff --git a/doc/ChangeLog b/doc/ChangeLog
index 5043a8f..8dcc4df 100644
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -1,3 +1,8 @@
+2008-02-01 Steven Schubiger [EMAIL PROTECTED]
+
+ * coreutils.texi (split invocation): Remove the mention
+ of --verbose output being printed to stderr.
+
2007-10-05 Jim Meyering [EMAIL PROTECTED]
* coreutils.texi (chroot invocation): List two systems on which
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 40aee6f..aca5fbd 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -2838,7 +2838,7 @@ Use digits in suffixes rather than lower-case letters.
@itemx --verbose
@opindex --verbose
-Write a diagnostic to standard error just before each output file is opened.
+Write a diagnostic just before each output file is opened.
@end table
diff --git a/src/mkdir.c b/src/mkdir.c
index 0704077..aaaf3f8 100644
--- a/src/mkdir.c
+++ b/src/mkdir.c
@@ -1,5 +1,5 @@
/* mkdir -- make directories
- Copyright (C) 90, 1995-2002, 2004-2007 Free Software Foundation, Inc.
+ Copyright (C) 90, 1995-2002, 2004-2008 Free Software Foundation, Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -79,6 +79,18 @@ Mandatory arguments to long options are mandatory for short
options too.\n\
exit (status);
}
+/* Verbose formatted output of variable count of arguments. */
+static void
+verbose_output (const char *const fmt, ...)
+{
+ va_list ap;
+ va_start (ap, fmt);
+ fprintf (stdout, %s: , program_name);
+ vfprintf (stdout, fmt, ap);
+ fprintf (stdout, \n);
+ va_end (ap);
+}
+
/* Options passed to subsidiary functions. */
struct mkdir_options
{
@@ -105,7 +117,7 @@ announce_mkdir (char const *dir, void *options)
{
struct mkdir_options const *o = options;
if (o-created_directory_format)
-error (0, 0, o-created_directory_format, quote (dir));
+verbose_output (o-created_directory_format, quote (dir));
}
/* Make ancestor directory DIR, whose last component is COMPONENT,
diff --git a/src/split.c b/src/split.c
index 5807a1c..f84d40e 100644
--- a/src/split.c
+++ b/src/split.c
@@ -1,5 +1,5 @@
/* split.c -- split a file into pieces.
- Copyright (C) 1988, 1991, 1995-2007 Free Software Foundation, Inc.
+ Copyright (C) 1988, 1991, 1995-2008 Free Software Foundation, Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -122,8 +122,8 @@ Mandatory arguments to long options are mandatory for short
options too.\n\
-l, --lines=NUMBER put NUMBER lines per output file\n\
), DEFAULT_SUFFIX_LENGTH);
fputs (_(\
- --verbose print a diagnostic to standard error just\n\
-before each output file is opened\n\
+ --verbose print a diagnostic just before each\n\
+output file is opened\n\
), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
@@ -208,7 +208,7 @@ cwrite (bool new_file_flag, const char *bp, size_t bytes)
next_file_name ();
if (verbose)
- fprintf (stderr, _(creating file %s\n), quote (outfile));
+ fprintf (stdout, _(creating file %s\n), quote (outfile));
output_desc = open (outfile,
O_WRONLY | O_CREAT | O_TRUNC | O_BINARY,
(S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP
diff --git a/tests/misc/split-a b/tests/misc/split-a
index 794115f..a8eed38 100755
---
Re: [PATCH] Add svg to the dircolors list
Mike Frysinger wrote: Signed-off-by: Mike Frysinger [EMAIL PROTECTED] --- src/dircolors.hin |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/dircolors.hin b/src/dircolors.hin index 3c171f9..14ba451 100644 --- a/src/dircolors.hin +++ b/src/dircolors.hin @@ -138,6 +138,7 @@ EXEC 01;32 .tif 01;35 .tiff 01;35 .png 01;35 +.svg 01;35 .mng 01;35 .pcx 01;35 .mov 01;35 How about .svgz? -- Matthew It's impossible! But... do-able. -- Robert MacDougal (Sean Connery, Entrapment) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date command
Felix Joussein [EMAIL PROTECTED] writes: Basicaly the goal ist, to set back the time at a certain moment for 1 Second. It's all about the leap-second which might be set every last second of the 31th of dec. or 30th of june... But the stated time stamp (01/31/2008 14:20:60) is not a leap second. So it doesn't seem to be an example of the goal that you were trying to accomplish. Most systems don't support leap seconds, but if you are on a system that does support them, then leap-second time stamps should continue to work. (If they don't work, please report them as a bug.) However, invalid time stamps like 01/31/2008 14:20:60 are not supported. Such strings used to have an (undocumented) behavior, but the behavior was inconsistent and the inconsistencies caused some other problems, so we thought it better to simply reject them. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
