(no subject)
>From d3ffc5547f1d77131ebdd4641c422072f2743283 Mon Sep 17 00:00:00 2001
From: James Youngman <[EMAIL PROTECTED]>
Date: Sat, 16 Feb 2008 15:43:56 +
Subject: [PATCH] Implement join --check-order.
2008-02-16 James Youngman <[EMAIL PROTECTED]>
* src/join.c (join): Support --check-order and --nocheck-order.
For --check-order, verify that the input files are in sorted
order.
(usage): Mention --check-order and --nocheck-order.
(dupline): Save a copy of the previously-read input line so that
we can detect disorder on the input.
(get_line): Temporarily save a copy of the previous line (by
calling dupline) and check relative ordering (by calling
checkorder) before returning the newly-read line.
(getseq, join): Tell get_line which file we are reading from.
(advance_seq): New function, factoring out some of the code
commonly surrounding calls to getseq.
(checkorder): New function. Verifies that a pair of consecutive
input lines are in sorted order.
* coreutils.texi (join invocation): Document the new options
--check-order and --nocheck-order.
---
doc/coreutils.texi | 19 ++-
src/join.c | 129 ++-
2 files changed, 122 insertions(+), 26 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 23d0ab4..0dd4587 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -5149,9 +5149,16 @@ sort a file on its default join field, but if you select
a non-default
locale, join field, separator, or comparison options, then you should
do so consistently between @command{join} and @command{sort}.
-As a @acronym{GNU} extension, if the input has no unpairable lines the
-sort order can be any order that considers two fields to be equal if and
-only if the sort comparison described above considers them to be equal.
[EMAIL PROTECTED] Unsorted inputs are a common cause of FAQs, but we probably
[EMAIL PROTECTED] should not make --check-order the default, as we documented
this
[EMAIL PROTECTED] extension and so should continue to allow it
+.
+If the @option{--check-order} option is given, unsorted inputs will
+cause a fatal error message. If the @option{--check-order} option is
+not given, a @acronym{GNU} extension is available: if the input has no
+unpairable lines the sort order can be any order that considers two
+fields to be equal if and only if the sort comparison described above
+considers them to be equal.
For example:
@example
@@ -5188,6 +5195,12 @@ The program accepts the following options. Also see
@ref{Common options}.
Print a line for each unpairable line in file @var{file-number} (either
@samp{1} or @samp{2}), in addition to the normal output.
[EMAIL PROTECTED] --check-order
+Check that both input files are in sorted order.
+
[EMAIL PROTECTED] --nocheck-order
+Do not check that both input files are in sorted order. This is the default.
+
@item -e @var{string}
@opindex -e
Replace those output fields that are missing in the input with
diff --git a/src/join.c b/src/join.c
index a6ca7e4..2a5147d 100644
--- a/src/join.c
+++ b/src/join.c
@@ -108,9 +108,21 @@ static struct outlist *outlist_end = &outlist_head;
tab character whose value (when cast to unsigned char) equals TAB. */
static int tab = -1;
+/* If nonzero, check that the input is correctly ordered. */
+static bool check_input_order = false;
+
+enum
+{
+ CHECK_ORDER_OPTION = CHAR_MAX + 1,
+ NOCHECK_ORDER_OPTION
+};
+
+
static struct option const longopts[] =
{
{"ignore-case", no_argument, NULL, 'i'},
+ {"check-order", no_argument, NULL, CHECK_ORDER_OPTION},
+ {"nocheck-order", no_argument, NULL, NOCHECK_ORDER_OPTION},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{NULL, 0, NULL, 0}
@@ -122,6 +134,9 @@ static struct line uni_blank;
/* If nonzero, ignore case when comparing join fields. */
static bool ignore_case;
+
+static void checkorder (const struct line *, const struct line *, int);
+
void
usage (int status)
{
@@ -153,6 +168,8 @@ by whitespace. When FILE1 or FILE2 (not both) is -, read
standard input.\n\
-v FILENUMlike -a FILENUM, but suppress joined output lines\n\
-1 FIELD join on this FIELD of file 1\n\
-2 FIELD join on this FIELD of file 2\n\
+ --check-order check that the input is correctly sorted\n\
+ --nocheck-order do not check that the input is correctly sorted\n\
"), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
@@ -228,12 +245,49 @@ xfields (struct line *line)
extract_field (line, ptr, lim - ptr);
}
+struct line*
+dupline (const struct line *old)
+{
+ struct line *newline = xmalloc (sizeof *newline);
+ size_t i;
+
+ /* Duplicate the buffer. */
+ initbuffer (&newline->buf);
+ newline->buf.buffer = xmalloc (old->buf.size);
+ newline->buf.size = old->buf.size;
+
Do we like the same books?
I just joined Shelfari to connect with other book lovers. Come see the books I love and see if we have any in common. Then pick my next book so I can keep on reading. Click below to join my group of friends on Shelfari! http://www.shelfari.com/Register.aspx?ActivityId=73746131&InvitationCode=64ca462e-afab-4998-b243-ffe9122a4d64 Ikuru Dimieari Shelfari is a free site that lets you share book ratings and reviews with friends and meet people who have similar tastes in books. It also lets you build an online bookshelf, join book clubs, and get good book recommendations from friends. You should check it out. You have received this email because Ikuru Dimieari ([EMAIL PROTECTED]) directly invited you to join his or her community on Shelfari. It is against Shelfari's policies to invite people who you don't know directly. Follow this link (http://www.shelfari.com/actions/[EMAIL PROTECTED]&activityid=73746131) to prevent future invitations to this address. If you believe you do not know this person, you may view (http://www.shelfari.com/o1517708933) his or her Shelfari page or report him or her in our feedback (http://www.shelfari.com/Feedback.aspx) section. Shelfari, 616 1st Ave #300, Seattle, WA 98104 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: (no subject)
Sorry, that was a duplicate patch, badly formatted. Apologies. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Use the gettime module in ls.c.
2008-02-16 James Youngman <[EMAIL PROTECTED]>
Implement TODO list item to make ls.c use the gettime module.
* TODO (ls): Now that we use gettime, remove the TODO entry.
* src/ls.c: Use timespec.h and the gettime module.
(current_time): Change type from time_t to struct timespec.
(current_time_ns): Removed.
(get_current_time): Removed.
(print_long_format): Remove when and when_ns, since we have
when_timespec anyway. Change type of variable six_months_ago from
time_t to struct timespec.
---
TODO |4 +--
src/ls.c | 76 +
2 files changed, 22 insertions(+), 58 deletions(-)
diff --git a/TODO b/TODO
index 3cec054..24369c6 100644
--- a/TODO
+++ b/TODO
@@ -177,11 +177,9 @@ Adapt tools like wc, tr, fmt, etc. (most of the textutils)
to be
pr's use of nstrftime can make it malloc a very large (up to SIZE_MAX) buffer
-ls.c: use gettime rather than clock_gettime, gettimeofday, time
-
-
-Copyright (C) 2002-2007 Free Software Foundation, Inc.
+Copyright (C) 2002-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
diff --git a/src/ls.c b/src/ls.c
index 46713f2..5f466ca 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -101,6 +101,7 @@
#include "quotearg.h"
#include "same.h"
#include "stat-time.h"
+#include "timespec.h"
#include "strftime.h"
#include "strverscmp.h"
#include "xstrtol.h"
@@ -311,8 +312,7 @@ static struct pending *pending_dirs;
/* Current time in seconds and nanoseconds since 1970, updated as
needed when deciding whether a file is recent. */
-static time_t current_time = TYPE_MINIMUM (time_t);
-static int current_time_ns = -1;
+static struct timespec current_time;
static bool print_scontext;
static char UNKNOWN_SECURITY_CONTEXT[] = "?";
@@ -1155,6 +1155,9 @@ main (int argc, char **argv)
print_dir_name = true;
pending_dirs = NULL;
+ current_time.tv_sec = TYPE_MINIMUM (time_t);
+ current_time.tv_nsec = -1;
+
i = decode_switches (argc, argv);
if (print_with_color)
@@ -3306,42 +3309,6 @@ long_time_expected_width (void)
return width;
}
-/* Get the current time. */
-
-static void
-get_current_time (void)
-{
-#if HAVE_CLOCK_GETTIME && defined CLOCK_REALTIME
- {
-struct timespec timespec;
-if (clock_gettime (CLOCK_REALTIME, ×pec) == 0)
- {
- current_time = timespec.tv_sec;
- current_time_ns = timespec.tv_nsec;
- return;
- }
- }
-#endif
-
- /* The clock does not have nanosecond resolution, so get the maximum
- possible value for the current time that is consistent with the
- reported clock. That way, files are not considered to be in the
- future merely because their time stamps have higher resolution
- than the clock resolution. */
-
-#if HAVE_GETTIMEOFDAY
- {
-struct timeval timeval;
-gettimeofday (&timeval, NULL);
-current_time = timeval.tv_sec;
-current_time_ns = timeval.tv_usec * 1000 + 999;
- }
-#else
- current_time = time (NULL);
- current_time_ns = 9;
-#endif
-}
-
/* Print the user or group name NAME, with numeric id ID, using a
print width of WIDTH columns. */
@@ -3441,8 +3408,6 @@ print_long_format (const struct fileinfo *f)
];
size_t s;
char *p;
- time_t when;
- int when_ns;
struct timespec when_timespec;
struct tm *when_local;
@@ -3476,9 +3441,6 @@ print_long_format (const struct fileinfo *f)
abort ();
}
- when = when_timespec.tv_sec;
- when_ns = when_timespec.tv_nsec;
-
p = buf;
if (print_inode)
@@ -3579,35 +3541,38 @@ print_long_format (const struct fileinfo *f)
if (f->stat_ok && when_local)
{
- time_t six_months_ago;
+ struct timespec six_months_ago;
bool recent;
char const *fmt;
/* If the file appears to be in the future, update the current
time, in case the file happens to have been modified since
the last time we checked the clock. */
- if (current_time < when
- || (current_time == when && current_time_ns < when_ns))
+ if (timespec_cmp (current_time, when_timespec) < 0)
{
- /* Note that get_current_time calls gettimeofday which, on some non-
+ /* Note that gettime calls gettimeofday which, on some non-
compliant systems, clobbers the buffer used for localtime's result.
But it's ok here, because we use a gettimeofday wrapper that
saves and restores the buffer around the gettimeofday call. */
- get_current_time ();
+ gettime (¤t_time);
}
/* Consider a time to be recent if it is within the past six
months. A Gregorian year has 365.2425 * 24 * 60 * 60 ==
31556952 seconds on the average. Write this value as an
integer constant to avoid floating point has
TODO entry for getgrouplist
The current coreutils TODO file says:-
Implement Ulrich Drepper's suggestion to use getgrouplist rather than
getugroups. This affects both `id' and `setuidgid', but makes a big
difference on systems with many users and/or groups, and makes id usable
once again on systems where access restrictions make getugroups fail.
But first we'll need a run-test (either in an autoconf macro or at
run time) to avoid the segfault bug in libc-2.3.2's getgrouplist.
In that case, we'd revert to using a new (to-be-written) getgrouplist
module that does most of what `id' already does. Or just avoid the
buggy use of getgrouplist by never passing it a buffer of length zero.
See http://bugzilla.redhat.com/200327
This seems to me to imply that there are safe usages of getgrouplist()
on arbitrary systems. Specifically, that the problem is the zero
length of the buffer. However the manpage for that function says :
The glibc 2.3.2 implementation of this function is broken: it over‐
writes memory when the actual number of groups is larger than *ngroups.
So, is it safe to use getgrouplist() with an iniital value of 1 for
*ngrouplist? My belief is yes, since the relevant bugfix to glibc
seems to be this:
$ cvs diff -r1.33 -r1.34 -upN initgroups.c
Index: initgroups.c
===
RCS file: /cvs/glibc/libc/grp/initgroups.c,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -p -r1.33 -r1.34
--- initgroups.c5 Oct 2004 15:36:26 - 1.33
+++ initgroups.c29 Mar 2005 23:39:59 - 1.34
@@ -1,4 +1,4 @@
-/* Copyright (C) 1989,91,93,1996-2003, 2004 Free Software Foundation, Inc.
+/* Copyright (C) 1989,91,93,1996-2003, 2004, 2005 Free Software
Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
@@ -73,7 +73,9 @@ internal_getgrouplist (const char *user,
/* Start is one, because we have the first group as parameter. */
long int start = 1;
- (*groupsp)[0] = group;
+ /* Never store more than the starting *SIZE number of elements. */
+ if (*size > 0)
+(*groupsp)[0] = group;
if (__nss_group_database != NULL)
{
My take on this is that the manual page is in fact wrong. I'm asking
on the list because I don't want to forge ahead and then introduce a
bug on a system which I can't test on.
James.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: TODO entry for getgrouplist
"James Youngman" <[EMAIL PROTECTED]> wrote: > The current coreutils TODO file says:- > > Implement Ulrich Drepper's suggestion to use getgrouplist rather than > getugroups. This affects both `id' and `setuidgid', but makes a big > difference on systems with many users and/or groups, and makes id usable > once again on systems where access restrictions make getugroups fail. > But first we'll need a run-test (either in an autoconf macro or at > run time) to avoid the segfault bug in libc-2.3.2's getgrouplist. > In that case, we'd revert to using a new (to-be-written) getgrouplist > module that does most of what `id' already does. Or just avoid the > buggy use of getgrouplist by never passing it a buffer of length zero. > See http://bugzilla.redhat.com/200327 > > This seems to me to imply that there are safe usages of getgrouplist() > on arbitrary systems. Specifically, that the problem is the zero > length of the buffer. Right. > However the manpage for that function says : > >The glibc 2.3.2 implementation of this function is broken: it over‐ >writes memory when the actual number of groups is larger than *ngroups. > > So, is it safe to use getgrouplist() with an iniital value of 1 for > *ngrouplist? Yes, that is my understanding, too. If you're suggesting that it'd be best to avoid the problematic usage (and thus not to rely on a configure-time test), then you're on the right track. Then the code will work even when a binary built on a system with newer glibc is run on a system with the broken function. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Use the gettime module in ls.c.
James Youngman <[EMAIL PROTECTED]> wrote: > 2008-02-16 James Youngman <[EMAIL PROTECTED]> > > Implement TODO list item to make ls.c use the gettime module. > * TODO (ls): Now that we use gettime, remove the TODO entry. > * src/ls.c: Use timespec.h and the gettime module. > (current_time): Change type from time_t to struct timespec. > (current_time_ns): Removed. > (get_current_time): Removed. > (print_long_format): Remove when and when_ns, since we have > when_timespec anyway. Change type of variable six_months_ago from > time_t to struct timespec. ... > diff --git a/src/ls.c b/src/ls.c > index 46713f2..5f466ca 100644 > --- a/src/ls.c > +++ b/src/ls.c > @@ -101,6 +101,7 @@ > #include "quotearg.h" > #include "same.h" > #include "stat-time.h" > +#include "timespec.h" Thank you! I've applied that modulo two nits: - don't include timespec.h - don't add trailing blanks Both of which are checked by running "make distcheck". ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Use the gettime module in ls.c.
On Feb 16, 2008 6:35 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > Both of which are checked by running "make distcheck". Thanks. I was unable to do that, because at the moment, tests/cp/acl fails on my machine. I suspect this is because I am using a VPATH build and $PWD includes a symlink, though I have not yet had time to investigate: orbital:cp$ rm acl.log; pwd ; pwd -P; grep "top_srcdir = " Makefile; make acl.log /home/james/source/GNU/coreutils/compile/tests/cp /home/build/james/GNU/coreutils/compile/tests/cp abs_top_srcdir = /home/james/source/GNU/coreutils/coreutils top_srcdir = /home/james/source/GNU/coreutils/coreutils FAIL: acl.log orbital:cp$ cat acl.log FAIL: acl.log (exit: 1) === grep: ../../lib/config.h: No such file or directory Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Time sync
I was thinking of like running date without a daemon, such as; $ date --sync time-a.nist.gov But maybe you're right. Date should be simple, and I can use ntpd instead. On Feb 16, 2008 7:02 AM, Bob Proulx <[EMAIL PROTECTED]> wrote: > Fred . wrote: > > Why is there no 'time synchronization' feature in the 'date' software > > that comes with GNU Coreutils? > > Tasks such as that require a long running deamon process to keep the > system in step with the outside world. The date command is a simple > run and exit command. It is not designed to be a daemon. Also very > good alternatives already exist. It wouldn't make sense to duplicate > that code in date. > > > It would be nice to be able to sync the date with remote Internet > > time servers. > > See the ntpd project. It is the standard upon which all others > build. If you are running a standard software distribution then it is > very likely that ntpd is already included. > > http://www.ntp.org/ > > http://en.wikipedia.org/wiki/Network_Time_Protocol > > Bob > ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Use the gettime module in ls.c.
"James Youngman" <[EMAIL PROTECTED]> wrote: > On Feb 16, 2008 6:35 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: >> Both of which are checked by running "make distcheck". > > Thanks. I was unable to do that, because at the moment, tests/cp/acl > fails on my machine. I suspect this is because I am using a VPATH > build and $PWD includes a symlink, though I have not yet had time to > investigate: > > orbital:cp$ rm acl.log; pwd ; pwd -P; grep "top_srcdir = " Makefile; > make acl.log > /home/james/source/GNU/coreutils/compile/tests/cp > /home/build/james/GNU/coreutils/compile/tests/cp > abs_top_srcdir = /home/james/source/GNU/coreutils/coreutils > top_srcdir = /home/james/source/GNU/coreutils/coreutils > FAIL: acl.log > orbital:cp$ cat acl.log > FAIL: acl.log (exit: 1) > === > > grep: ../../lib/config.h: No such file or directory Thanks for reporting that. This patch should fix it. Would you please confirm? diff --git a/tests/check.mk b/tests/check.mk index 48cffa4..8caf29d 100644 --- a/tests/check.mk +++ b/tests/check.mk @@ -44,7 +44,7 @@ TESTS_ENVIRONMENT = \ host_triplet='$(host_triplet)' \ srcdir='$(srcdir)' \ top_srcdir='$(top_srcdir)' \ - CONFIG_HEADER='$(CONFIG_HEADER)' \ + CONFIG_HEADER='$(abs_top_builddir)/lib/config.h' \ CU_TEST_NAME=`basename '$(abs_srcdir)'`,$$tst\ EGREP='$(EGREP)' \ EXEEXT='$(EXEEXT)' \ BTW, you can run the lighter-weight tests with "make syntax-check". Or use make's --keep-going (-k) option: make -k distcheck ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Use the gettime module in ls.c.
On Feb 16, 2008 9:05 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > Thanks for reporting that. This patch should fix it. > Would you please confirm? Yes, that works. The effect of the patch on this system is that the test is now skipped instead of failing. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Mention the new join option --check-order
--- NEWS |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index af27aab..0bf8dbb 100644 --- a/NEWS +++ b/NEWS @@ -17,6 +17,12 @@ GNU coreutils NEWS-*- outline -*- mkdir and split now write --verbose output to stdout, not stderr. +** New features + + join now has a --check-order option which causes join to verify that + the input files are indeed sorted. The option --nocheck-sorted + turns the check off (the check is currently off by default). + * Noteworthy changes in release 6.10 (2008-01-22) [stable] -- 1.5.3.8 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH, 2nd try] Implement join --check-order.
2008-02-16 James Youngman <[EMAIL PROTECTED]>
* src/join.c (join): Support --check-order and --nocheck-order.
For --check-order, verify that the input files are in sorted
order.
(usage): Mention --check-order and --nocheck-order.
(dupline): Save a copy of the previously-read input line so that
we can detect disorder on the input.
(get_line): Temporarily save a copy of the previous line (by
calling dupline) and check relative ordering (by calling
checkorder) before returning the newly-read line.
(getseq, join): Tell get_line which file we are reading from.
(advance_seq): New function, factoring out some of the code
commonly surrounding calls to getseq.
(checkorder): New function. Verifies that a pair of consecutive
input lines are in sorted order.
* coreutils.texi (join invocation): Document the new options
--check-order and --nocheck-order.
* NEWS: Mention the new options.
---
NEWS |6 ++
doc/coreutils.texi | 19 ++-
src/join.c | 129 ++-
3 files changed, 128 insertions(+), 26 deletions(-)
diff --git a/NEWS b/NEWS
index af27aab..0bf8dbb 100644
--- a/NEWS
+++ b/NEWS
@@ -17,6 +17,12 @@ GNU coreutils NEWS-*-
outline -*-
mkdir and split now write --verbose output to stdout, not stderr.
+** New features
+
+ join now has a --check-order option which causes join to verify that
+ the input files are indeed sorted. The option --nocheck-sorted
+ turns the check off (the check is currently off by default).
+
* Noteworthy changes in release 6.10 (2008-01-22) [stable]
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 23d0ab4..0dd4587 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -5149,9 +5149,16 @@ sort a file on its default join field, but if you select
a non-default
locale, join field, separator, or comparison options, then you should
do so consistently between @command{join} and @command{sort}.
-As a @acronym{GNU} extension, if the input has no unpairable lines the
-sort order can be any order that considers two fields to be equal if and
-only if the sort comparison described above considers them to be equal.
[EMAIL PROTECTED] Unsorted inputs are a common cause of FAQs, but we probably
[EMAIL PROTECTED] should not make --check-order the default, as we documented
this
[EMAIL PROTECTED] extension and so should continue to allow it
+.
+If the @option{--check-order} option is given, unsorted inputs will
+cause a fatal error message. If the @option{--check-order} option is
+not given, a @acronym{GNU} extension is available: if the input has no
+unpairable lines the sort order can be any order that considers two
+fields to be equal if and only if the sort comparison described above
+considers them to be equal.
For example:
@example
@@ -5188,6 +5195,12 @@ The program accepts the following options. Also see
@ref{Common options}.
Print a line for each unpairable line in file @var{file-number} (either
@samp{1} or @samp{2}), in addition to the normal output.
[EMAIL PROTECTED] --check-order
+Check that both input files are in sorted order.
+
[EMAIL PROTECTED] --nocheck-order
+Do not check that both input files are in sorted order. This is the default.
+
@item -e @var{string}
@opindex -e
Replace those output fields that are missing in the input with
diff --git a/src/join.c b/src/join.c
index a6ca7e4..2a5147d 100644
--- a/src/join.c
+++ b/src/join.c
@@ -108,9 +108,21 @@ static struct outlist *outlist_end = &outlist_head;
tab character whose value (when cast to unsigned char) equals TAB. */
static int tab = -1;
+/* If nonzero, check that the input is correctly ordered. */
+static bool check_input_order = false;
+
+enum
+{
+ CHECK_ORDER_OPTION = CHAR_MAX + 1,
+ NOCHECK_ORDER_OPTION
+};
+
+
static struct option const longopts[] =
{
{"ignore-case", no_argument, NULL, 'i'},
+ {"check-order", no_argument, NULL, CHECK_ORDER_OPTION},
+ {"nocheck-order", no_argument, NULL, NOCHECK_ORDER_OPTION},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{NULL, 0, NULL, 0}
@@ -122,6 +134,9 @@ static struct line uni_blank;
/* If nonzero, ignore case when comparing join fields. */
static bool ignore_case;
+
+static void checkorder (const struct line *, const struct line *, int);
+
void
usage (int status)
{
@@ -153,6 +168,8 @@ by whitespace. When FILE1 or FILE2 (not both) is -, read
standard input.\n\
-v FILENUMlike -a FILENUM, but suppress joined output lines\n\
-1 FIELD join on this FIELD of file 1\n\
-2 FIELD join on this FIELD of file 2\n\
+ --check-order check that the input is correctly sorted\n\
+ --nocheck-order do not check that the input is correctly sorted\n\
"), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSI
Re: Time sync
On Feb 16, 2008 8:52 PM, Fred . <[EMAIL PROTECTED]> wrote: > I was thinking of like running date without a daemon, such as; > $ date --sync time-a.nist.gov > > But maybe you're right. Date should be simple, and I can use ntpd instead. If it's a one-off, you can use ntpdate instead. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Time sync
Fred . wrote: > I was thinking of like running date without a daemon, such as; > $ date --sync time-a.nist.gov Stepping the time like that is trouble because it means that some system times will be seen twice and other system times will be skipped. Cron tasks that are meant to trigger on a particular second won't happen and others will happen twice at close to the same time. It plays havoc with programs that check the time while running. Take my advice and don't do it! :-) Having said that it is typical to step the time at system boot. At that time processes have yet to start running and it is best to get the time set before they do. If networking is available at boot time most systems will set the time from the pool of ntp servers. The 'ntpdate' command is usually used in this context. Recently ntpdate was obsoleted and all of the its functionality is now available in the ntpd program. See the 'ntpd -q' option for more information. > But maybe you're right. Date should be simple, and I can use ntpd instead. The better way as done by ntpd is to adjust the clock ticks per second such that some system seconds are shorter or longer than others in order to keep the time in line with the outside world. In this way every system time will be seen with none skipped and none twice. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: "mkdir -p" new child dirs don't inherit default POSIX ACLs properly
Paul,
I modified the C program slightly (just to better understand what's going
on) and ran it like this:
-mkdir-test.c--
#include
int
main (void)
{
umask (022);
mkdir ("acl-test/dir-022-777", 0777);
mkdir ("acl-test/dir-022-755", 0755);
umask (0);
mkdir ("acl-test/dir-0-777", 0777);
mkdir ("acl-test/dir-0-755", 0755);
return 0;
}
-mkdir-test.c--
What I learned was that the umask() lines had no affect on the effective
rights mask of the inherited ACLs, but the mode did. The 0777 mkdir lines
all inherited the default mask (rwx) properly and the 0755 lines inherited
the mask as (r-x).
To eliminate kernel and filesystem differences I brought the
coreutils-5.97 package up to the same distro level (Slackware-current) and
also tested on both ReiserFS (my original filesystem) and ext3. There
were no differences in behaviors between ReiserFS and ext3 in any of my
tests, so I won't mention them anymore.
There was a difference in the coreutils versions however... Not in the
behavior of the C program calls, but in the way that "mkdir -p" constructs
those calls from the shell. So, if I understand your last note correctly,
the following should be equivalent:
umask (022);
mkdir ("acl-test/dir-777", 0777);
...and...
umask (0);
mkdir ("acl-test/dir-755", 0755);
With "mkdir -p", the 5.97 coreutils constructs the calls with the umask
022 + mkdir 0777 method and 6.10 uses the umask 0 + mkdir 0755 method.
In 6.10, with my shell environment umask at 022, mkdir -p gives:
umask(0)= 022
mkdir("acl-test", 0755) = -1 EEXIST (File exists)
chdir("acl-test") = 0
mkdir("mkdir-p", 0755) = 0
...and the inherited ACL mask is wrong.
In 5.97, with my shell environment umask at 022, mkdir -p gives:
umask(0)= 022
umask(022) = 0
stat64("acl-test/mkdir-p", 0xbfca8134) = -1 ENOENT (No such file or
directory)
umask(0)= 022
open(".", O_RDONLY|O_LARGEFILE) = 3
mkdir("acl-test", 0755) = -1 EEXIST (File exists)
chdir("acl-test") = 0
umask(022) = 0
mkdir("mkdir-p", 0777) = 0
...and the inherited ACL mask is correct.
So if the shell command "mkdir" under version 6.10 uses 0777 in its system
call, maybe "mkdir -p" should as well? At least for newly created dirs?
I've attached traces for "mkdir -p" and the C code that I called
"mkdir-test.c" for both 5.97 and 6.10 versions of coreutils.
Thanks,
CJM
mkdir-5.97-vs-6.10-traces.tgz
Description: Binary data
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Mention the new join option --check-order
James Youngman wrote: > + join now has a --check-order option which causes join to verify that > + the input files are indeed sorted. The option --nocheck-sorted > + turns the check off (the check is currently off by default). I'm not sure it's worth adding this option. If you know to use it, then you already know the input should be sorted? what am I missing? thanks, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] ls --group-directories-first: symlinks to dirs are dirs too
Eric Blake <[EMAIL PROTECTED]> wrote: ... > This point I can agree with. --group-directories-first is relatively new, > and since it is currently silent about behavior on links, I have no > problem with changing that behavior; however, I would insist that if we > make a change, we add test cases and documentation to lock in that > behavior for the future. Yes. If someone were to prepare a complete patch, (i.e., one that I can simply "git pull ..." or apply with "git am", updating NEWS, coreutils.texi, and ls.c's usage (to adjust ls' --help)) that would make a fine point for further discussion. Code speaks more loudly than words. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Implement join --check-order.
2008-02-16 James Youngman <[EMAIL PROTECTED]>
* src/join.c (join): Support --check-order and --nocheck-order.
For --check-order, verify that the input files are in sorted
order.
(usage): Mention --check-order and --nocheck-order.
(dupline): Save a copy of the previously-read input line so that
we can detect disorder on the input.
(get_line): Temporarily save a copy of the previous line (by
calling dupline) and check relative ordering (by calling
checkorder) before returning the newly-read line.
(getseq, join): Tell get_line which file we are reading from.
(advance_seq): New function, factoring out some of the code
commonly surrounding calls to getseq.
(checkorder): New function. Verifies that a pair of consecutive
input lines are in sorted order.
* coreutils.texi (join invocation): Document the new options
--check-order and --nocheck-order.
---
doc/coreutils.texi | 19 ++-
src/join.c | 129 ++-
2 files changed, 122 insertions(+), 26 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 23d0ab4..0dd4587 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -5149,9 +5149,16 @@ sort a file on its default join field, but if you select
a non-default
locale, join field, separator, or comparison options, then you should
do so consistently between @command{join} and @command{sort}.
-As a @acronym{GNU} extension, if the input has no unpairable lines the
-sort order can be any order that considers two fields to be equal if and
-only if the sort comparison described above considers them to be equal.
[EMAIL PROTECTED] Unsorted inputs are a common cause of FAQs, but we probably
[EMAIL PROTECTED] should not make --check-order the default, as we documented
this
[EMAIL PROTECTED] extension and so should continue to allow it
+.
+If the @option{--check-order} option is given, unsorted inputs will
+cause a fatal error message. If the @option{--check-order} option is
+not given, a @acronym{GNU} extension is available: if the input has no
+unpairable lines the sort order can be any order that considers two
+fields to be equal if and only if the sort comparison described above
+considers them to be equal.
For example:
@example
@@ -5188,6 +5195,12 @@ The program accepts the following options. Also see
@ref{Common options}.
Print a line for each unpairable line in file @var{file-number} (either
@samp{1} or @samp{2}), in addition to the normal output.
[EMAIL PROTECTED] --check-order
+Check that both input files are in sorted order.
+
[EMAIL PROTECTED] --nocheck-order
+Do not check that both input files are in sorted order. This is the default.
+
@item -e @var{string}
@opindex -e
Replace those output fields that are missing in the input with
diff --git a/src/join.c b/src/join.c
index a6ca7e4..2a5147d 100644
--- a/src/join.c
+++ b/src/join.c
@@ -108,9 +108,21 @@ static struct outlist *outlist_end = &outlist_head;
tab character whose value (when cast to unsigned char) equals TAB. */
static int tab = -1;
+/* If nonzero, check that the input is correctly ordered. */
+static bool check_input_order = false;
+
+enum
+{
+ CHECK_ORDER_OPTION = CHAR_MAX + 1,
+ NOCHECK_ORDER_OPTION
+};
+
+
static struct option const longopts[] =
{
{"ignore-case", no_argument, NULL, 'i'},
+ {"check-order", no_argument, NULL, CHECK_ORDER_OPTION},
+ {"nocheck-order", no_argument, NULL, NOCHECK_ORDER_OPTION},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{NULL, 0, NULL, 0}
@@ -122,6 +134,9 @@ static struct line uni_blank;
/* If nonzero, ignore case when comparing join fields. */
static bool ignore_case;
+
+static void checkorder (const struct line *, const struct line *, int);
+
void
usage (int status)
{
@@ -153,6 +168,8 @@ by whitespace. When FILE1 or FILE2 (not both) is -, read
standard input.\n\
-v FILENUMlike -a FILENUM, but suppress joined output lines\n\
-1 FIELD join on this FIELD of file 1\n\
-2 FIELD join on this FIELD of file 2\n\
+ --check-order check that the input is correctly sorted\n\
+ --nocheck-order do not check that the input is correctly sorted\n\
"), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
@@ -228,12 +245,49 @@ xfields (struct line *line)
extract_field (line, ptr, lim - ptr);
}
+struct line*
+dupline (const struct line *old)
+{
+ struct line *newline = xmalloc (sizeof *newline);
+ size_t i;
+
+ /* Duplicate the buffer. */
+ initbuffer (&newline->buf);
+ newline->buf.buffer = xmalloc (old->buf.size);
+ newline->buf.size = old->buf.size;
+ memcpy (newline->buf.buffer, old->buf.buffer, old->buf.length);
+ newline->buf.length = old->buf.length;
+
+ /* Duplicate the field positions. */
+ newline->fields = xmalloc (sizeof *newline->fi
