Re: [PATCH] maint: use a wildcard to include all syntax check exceptions in dist
Pádraig Brady wrote: I noticed a couple of syntax check exception files missing from the distribution tarball. Specifically .x-sc_require_config_h_first and .x-sc_error_message_uppercase The attached patch changes things so we don't have to maintain the list. Good catch. I've suspected there were a few like that, but didn't really care, since it's not very useful to run make syntax-check from an unpacked-tarball directory. However, using a wildcard there would violate a pretty important rule: - don't distribute wildcard-selected file names Otherwise, you can accidentally distribute .x-sc_foo~, or .x-sc_some-experimental-or-rejected-change I haven't looked closely enough to say yet, but consider two alternatives: - stop distributing those .x-sc_ files altogether, or - add a check to ensure that all version-controlled .x-sc_ names are in that list I've done something like the latter with this rule in tests/check.mk: # Ensure that all version-controlled executable files are listed in TESTS. # Collect test names from the line matching /^TESTS = \\$$/ to the following # one that does not end in '\'. ... vc_exe_in_TESTS: Makefile From 2f6339766a0f32ab709b2ab2fc24c67b5b071cce Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com Date: Thu, 4 Jun 2009 18:31:16 +0100 Subject: [PATCH] maint: use a wildcard to include all syntax check exceptions in dist * Makefile.am: A couple of syntax check exception files were missing from the distribution target. Specifically .x-sc_require_config_h_first and .x-sc_error_message_uppercase Instead of adding them, simplify the list to a wildcard which `make` will expand when it resolves its prerequisites. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: wish: cp: output some sort of message if copying was interrupted
On Fri, 5 Jun 2009, Elmar Stellnberger wrote: Yes that will be a good solution for the usage of cp within shell scripts. However in most cases I invoke cp directly via the command line so that it is somehow awkward and very easy to forget having to issue always an extra command that tests for the return value (i.e. cp echo xx). The scenario under discussion was a simultaneous (long-running) cp and killall -s SIGINT cp. Shouldn't the user expect the POSIX-defined default behaviour for the signal? It is not possible to create a shell alias for this since testing for the return value must take place right -after- executing cp. Shell functions allow arguments and multiple commands. What about nonetheless issuing a message on stderr as long as no -q/--quiet option is given for the cases where the return value becomes nonzero? Other coreutils as rm are even more verbose than that, so why just solely not cp? Making a difference just on cp will be somehow conterintuitive. rm hug rm: remove write-protected regular empty file `hug'? y rm: cannot remove `hug': Permission denied cp does print diagnostic messages to stderr in many cases where the return value is nonzero, e.g. permission errors. It is not an error to terminate immediately on SIGINT however, so I'm unsure it's worthwhile adding such output to cp given that wrapper scripts and shell functions can provide the same feature if so desired. P.S.: In what kind of situation will it not be adequate to resume copying by issuing the same cp-command again? cp is not always idempotent, e.g. when using --backup. It's also inefficient to overwrite destination files which already exist; rsync would be better for repeat copies. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[egg...@cs.ucla.edu: Re: sort -N patch: sort in natural order]
Hello,
attached there is a patch against coreutils-6.10/sort.c implementing
Natural order sorting (e.g. A1 A2 A10), using -N parameter.
Please, consider it's inclusion in upstream :-)
Signing papers with copyright is not a problem.
Best regards,
Martin Sarfy
- Forwarded message from Paul Eggert egg...@cs.ucla.edu -
To: Martin Sarfy mar...@sarfy.cz
Subject: Re: sort -N patch: sort in natural order
From: Paul Eggert egg...@cs.ucla.edu
Date: Thu, 04 Jun 2009 12:10:04 -0700
Could you please send this directly to bug-coreut...@gnu.org?
Also, assuming it meets favor there, will you and your employer be willing
to sign papers assigning copyright to the FSF?
- End forwarded message -
--
Best regards
Martin Sarfy
--- coreutils-6.10-sort.c 2009-06-04 17:27:35.0 +0200
+++ coreutils-6.10-sort-natural.c 2009-06-04 17:27:44.0 +0200
@@ -170,6 +170,7 @@
bool random; /* Sort by random hash of key. */
bool general_numeric; /* Flag for general, numeric comparison.
Handle numbers in exponential notation. */
+ bool natural; /* Flag for natural order comparison. */
bool month; /* Flag for comparison by month name. */
bool reverse; /* Reverse the sense of comparison. */
struct keyfield *next; /* Next keyfield to try. */
@@ -327,6 +328,7 @@
-i, --ignore-nonprintingconsider only printable characters\n\
-M, --month-sortcompare (unknown) `JAN' ... `DEC'\n\
-n, --numeric-sort compare according to string numerical value\n\
+ -N, --natural-order-sortsort strings containing numbers in natural order\n\
-R, --random-sort sort by random hash of keys\n\
--random-source=FILEget random bytes from FILE (default /dev/urandom)\n\
-r, --reverse reverse the result of comparisons\n\
@@ -394,7 +396,7 @@
RANDOM_SOURCE_OPTION
};
-static char const short_options[] = -bcCdfgik:mMno:rRsS:t:T:uy:z;
+static char const short_options[] = -bcCdfgik:mMnNo:rRsS:t:T:uy:z;
static struct option const long_options[] =
{
@@ -409,6 +411,7 @@
{merge, no_argument, NULL, 'm'},
{month-sort, no_argument, NULL, 'M'},
{numeric-sort, no_argument, NULL, 'n'},
+ {natural-order-sort, no_argument, NULL, 'N'},
{random-sort, no_argument, NULL, 'R'},
{random-source, required_argument, NULL, RANDOM_SOURCE_OPTION},
{output, required_argument, NULL, 'o'},
@@ -1514,6 +1517,139 @@
return strnumcmp (a, b, decimal_point, thousands_sep);
}
+/* Perform 'natural order' comparisons of strings (A1 A2 A10)
+ Adoption for sort from strnatcmp.c by Martin Sarfy mar...@sarfy.cz
+ Original author (C) 2000, 2004 by Martin Pool mbp sourcefrog net */
+
+static inline int
+nat_isdigit(char a)
+{
+ return isdigit((unsigned char) a);
+}
+
+
+static inline int
+nat_isspace(char a)
+{
+ return isspace((unsigned char) a);
+}
+
+
+static inline char
+nat_toupper(char a)
+{
+ return toupper((unsigned char) a);
+}
+
+static int
+nat_compare_right(char const *a, char const *b)
+{
+ int bias = 0;
+
+ /* The longest run of digits wins. That aside, the greatest
+value wins, but we can't know that it will until we've scanned
+both numbers to know that they have the same magnitude, so we
+remember it in BIAS. */
+ for (;; a++, b++) {
+ if (!nat_isdigit(*a)!nat_isdigit(*b))
+ return bias;
+ else if (!nat_isdigit(*a))
+ return -1;
+ else if (!nat_isdigit(*b))
+ return +1;
+ else if (*a *b) {
+ if (!bias)
+bias = -1;
+ } else if (*a *b) {
+ if (!bias)
+bias = +1;
+ } else if (!*a!*b)
+ return bias;
+ }
+
+ return 0;
+}
+
+
+static int
+nat_compare_left(char const *a, char const *b)
+{
+ /* Compare two left-aligned numbers: the first to have a
+different value wins. */
+ for (;; a++, b++) {
+ if (!nat_isdigit(*a)!nat_isdigit(*b))
+ return 0;
+ else if (!nat_isdigit(*a))
+ return -1;
+ else if (!nat_isdigit(*b))
+ return +1;
+ else if (*a *b)
+ return -1;
+ else if (*a *b)
+ return +1;
+ }
+
+ return 0;
+}
+
+
+static int strnatcmp0(char const *a, char const *b, int fold_case)
+{
+ int ai, bi;
+ char ca, cb;
+ int fractional, result;
+
+ /* assert(a b); */
+ ai = bi = 0;
+ while (1) {
+ ca = a[ai]; cb = b[bi];
+
+ /* skip over leading spaces or zeros */
+ while (nat_isspace(ca))
+ ca = a[++ai];
+
+ while (nat_isspace(cb))
+ cb = b[++bi];
+
+ /* process run of digits */
+ if (nat_isdigit(ca)nat_isdigit(cb)) {
+ fractional = (ca == '0' || cb == '0');
+
+ if (fractional) {
+if ((result = nat_compare_left(a+ai, b+bi)) != 0)
+ return result;
+ } else {
+if ((result = nat_compare_right(a+ai, b+bi)) != 0)
+
Re: wish: cp: output some sort of message if copying was interrupted
Philip Rowlands schrieb: On Sun, 24 May 2009, Elmar Stellnberger wrote: If I issue a 'cp -a' on one konsole and a 'killall -s SIGINT cp' on another konsole cp -a will terminate just as if it had finished copying. Not quite; the exit status passed to the calling process will show the signal used to terminate cp. This can in turn be used to diagnose a display any desired message, for example in bash: $ PROMPT_COMMAND='[ $? -ne 0 ] echo Command exited abnormally' $ true $ false Command exited abnormally Alternatively it would be possible to construct a signal-aware wrapper around cp and other interactive processes. My regard would be to let it print something like 'copying interrupted' (... and may be continued by issuing the same command once more). As the tools already exist to build this feature it's not a good fit for adding to cp. The specific message regarding resumed copies would be highly dependent on the arguments to cp. Cheers, Phil Yes that will be a good solution for the usage of cp within shell scripts. However in most cases I invoke cp directly via the command line so that it is somehow awkward and very easy to forget having to issue always an extra command that tests for the return value (i.e. cp echo xx). What about nonetheless issuing a message on stderr as long as no -q/--quiet option is given for the cases where the return value becomes nonzero? It is not possible to create a shell alias for this since testing for the return value must take place right -after- executing cp. A wrapper shell script however would make things even worse since shell scripts will as well be invoked fromout of other shell scripts instead of being applied for user issued commands only. Other coreutils as rm are even more verbose than that, so why just solely not cp? Making a difference just on cp will be somehow conterintuitive. rm hug rm: remove write-protected regular empty file `hug'? y rm: cannot remove `hug': Permission denied P.S.: In what kind of situation will it not be adequate to resume copying by issuing the same cp-command again? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: wish: cp: output some sort of message if copying was interrupted
Philip Rowlands schrieb:
On Fri, 5 Jun 2009, Elmar Stellnberger wrote:
Yes that will be a good solution for the usage of cp within shell
scripts. However in most cases I invoke cp directly via the command line
so that it is somehow awkward and very easy to forget having to issue
always an extra command that tests for the return value (i.e. cp echo
xx).
The scenario under discussion was a simultaneous (long-running) cp and
killall -s SIGINT cp. Shouldn't the user expect the POSIX-defined
default behaviour for the signal?
It is not possible to create a shell alias for this since testing for
the return value must take place right -after- executing cp.
Shell functions allow arguments and multiple commands.
What about nonetheless issuing a message on stderr as long as no
-q/--quiet option is given for the cases where the return value becomes
nonzero?
Other coreutils as rm are even more verbose than that, so why just
solely not cp? Making a difference just on cp will be somehow
conterintuitive.
rm hug
rm: remove write-protected regular empty file `hug'? y
rm: cannot remove `hug': Permission denied
cp does print diagnostic messages to stderr in many cases where the
return value is nonzero, e.g. permission errors. It is not an error to
terminate immediately on SIGINT however, so I'm unsure it's worthwhile
adding such output to cp given that wrapper scripts and shell functions
can provide the same feature if so desired.
P.S.: In what kind of situation will it not be adequate to resume
copying by issuing the same cp-command again?
cp is not always idempotent, e.g. when using --backup. It's also
inefficient to overwrite destination files which already exist; rsync
would be better for repeat copies.
Cheers,
Phil
Providing a wrapper that checks the return value is not too difficult:
cp() { command cp $@ || echo error $? copying files.; }
However outputting an interrupted by keyboard message on SIGINT seems to
be more tricky since installing a signal handler beforehand invoking cp
will not do this job:
cp() { local sigh=$(trap -p SIGINT); trap echo copying interrupted by
SIGINT/Ctrl-C. 2 SIGINT
command cp $@ || echo error copying files.;
trap $sigh SIGINT; }
-- same results as with pure cp() from above as any new process will
install its own signal handlers
If the goal(-dir) did not exist beforehand invocation of copy specifying
the --update switch to cp should suffice for a continuation of copying.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [egg...@cs.ucla.edu: Re: sort -N patch: sort in natural order]
Martin Sarfy wrote: Hello, attached there is a patch against coreutils-6.10/sort.c implementing Natural order sorting (e.g. A1 A2 A10), using -N parameter. Please, consider it's inclusion in upstream :-) Signing papers with copyright is not a problem. Best regards, Martin Sarfy - Forwarded message from Paul Eggert egg...@cs.ucla.edu - To: Martin Sarfy mar...@sarfy.cz Subject: Re: sort -N patch: sort in natural order From: Paul Eggert egg...@cs.ucla.edu Date: Thu, 04 Jun 2009 12:10:04 -0700 Could you please send this directly to bug-coreut...@gnu.org? Also, assuming it meets favor there, will you and your employer be willing to sign papers assigning copyright to the FSF? - End forwarded message - Thanks very much for that. However I think this option added in release 7.0 covers this functionality? -V, --version-sort natural sort of (version) numbers within text Could you check if your patch handles cases that -V doesn't? cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [egg...@cs.ucla.edu: Re: sort -N patch: sort in natural order]
You are right, -V is exactly the same algorithm. The moral of the story is that next time I will patch against latest greatest source code version :-) Have a nice day Martin On Fri, Jun 05, 2009 at 04:43:05PM +0100, Pádraig Brady wrote: Thanks very much for that. However I think this option added in release 7.0 covers this functionality? -V, --version-sort natural sort of (version) numbers within text Could you check if your patch handles cases that -V doesn't? cheers, Pádraig. -- Best regards Martin Sarfy ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
