Re: [coreutils] How to check uniqueness on one or multiple columns in a table and print the duplicated rows?
On 17/06/10 21:53, Peng Yu wrote: Hi, Uniq doesn't have an option to check the uniqueness for a given column (although it can exclude the first a few columns). It will need 'cut' to check uniqueness on a give number of columns and print the duplicated rows. This is not convenient. I'm wondering if there is a better way to do so. Not at the moment no. It's on the list of tasks to add field support to uniq
bug#6442: About the modifier of -k option in sort
On 17/06/10 03:07, Peng Yu wrote: Hello, The modifiers of -k are discussed in the examples in 'info sort' rather than in the main entry of -k. I feel that this be improved by clearly describe each modifier under the main entry of -k. It is not very clear to how many modifiers there are. The sort --help (man) output has been improved lately, to group the ordering options, and these are referenced in the detailed description of POS You are looking at the latest version right? Would the following be enough to highlight the info you might have missed? --- a/src/sort.c +++ b/src/sort.c @@ -386,7 +386,7 @@ Other options:\n\ ), stdout); fputs (_(\ -k, --key=POS1[,POS2] start a key at POS1 (origin 1), end it at POS2\n\ -(default end of line)\n\ +(default end of line). See POS syntax below\n\ -m, --merge merge already sorted files; do not sort\n\ ), stdout); fputs (_(\
bug#6427: Autotest: enable colored test results.
On 06/17/2010 01:06 PM, Ralf Wildenhues wrote: * Pádraig Brady wrote on Tue, Jun 15, 2010 at 11:50:01AM CEST: On 14/06/10 21:23, Eric Blake wrote: ls --color = color ls --color=yes = color ls --color=auto = plain ls --color=always = color grep --color = plain grep --color=yes = color grep --color=auto = plain grep --color=always = color That is, ls --color implies ls --color=always, while grep --color implies grep --color=always. grep --color=auto you mean. Yep, sorry for my typo. I don't know either. However, I also think Autotest need not wait for standardization in order to gain color support. We can still fix the details later. True enough. ls has these synonyms: always, yes, force, never, no, none, auto, tty, if-tty, NULL We only document the first column which is a good thing. I agree, and implemented that in the updated patch. The patch below has --color equal --color=always. Since I'm less concerned about this detail than about the fact that the patch may not go in at all, I'm adding a second patch, to be squashed in with the first, if you prefer --color to be equal to --color=auto. OK to commit 1 or 1+2? For now, let's match ls (--color equals --color=always, patch 1 only), and you are free to push after fixing one nit: +--color ) + at_color=always + ;; +--color=* ) + case $at_optarg in + no | never | none) at_color=never ;; + auto | tty | if-tty) at_color=auto ;; + always | yes | force) at_color=always ;; + esac Let's add a *) option and cause a fatal error if we don't recognize the argument given to the --color option. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#6442: About the modifier of -k option in sort
2010/6/17 Pádraig Brady p...@draigbrady.com: On 17/06/10 03:07, Peng Yu wrote: Hello, The modifiers of -k are discussed in the examples in 'info sort' rather than in the main entry of -k. I feel that this be improved by clearly describe each modifier under the main entry of -k. It is not very clear to how many modifiers there are. The sort --help (man) output has been improved lately, to group the ordering options, and these are referenced in the detailed description of POS You are looking at the latest version right? Would the following be enough to highlight the info you might have missed? --- a/src/sort.c +++ b/src/sort.c @@ -386,7 +386,7 @@ Other options:\n\ ), stdout); fputs (_(\ -k, --key=POS1[,POS2] start a key at POS1 (origin 1), end it at POS2\n\ - (default end of line)\n\ + (default end of line). See POS syntax below\n\ -m, --merge merge already sorted files; do not sort\n\ ), stdout); fputs (_(\ Is it in the latest version? If yes, I'll install it. coreutils-8.5.tar.xz.sig 23-Apr-2010 12:42 836 BTW, how to figure out what version of my coreutils is? I 'man sort', it shows the following at the bottom of that page. I don't understand 7.4 is of date March 2010, it should be May 2009 according to http://ftp.gnu.org/gnu/coreutils/, right? GNU coreutils 7.4 March 2010 SORT(1) -- Regards, Peng
bug#6442: About the modifier of -k option in sort
On 06/17/2010 03:11 PM, Peng Yu wrote: You are looking at the latest version right? Would the following be enough to highlight the info you might have missed? --- a/src/sort.c +++ b/src/sort.c @@ -386,7 +386,7 @@ Other options:\n\ ), stdout); fputs (_(\ -k, --key=POS1[,POS2] start a key at POS1 (origin 1), end it at POS2\n\ -(default end of line)\n\ +(default end of line). See POS syntax below\n\ -m, --merge merge already sorted files; do not sort\n\ ), stdout); fputs (_(\ Is it in the latest version? If yes, I'll install it. coreutils-8.5.tar.xz.sig 23-Apr-2010 12:42 836 No, the whole point of this patch is that it is for the latest coreutils.git, which is post 8.5 (but will be in 8.6 if you like how it is worded). BTW, how to figure out what version of my coreutils is? I 'man sort', it shows the following at the bottom of that page. I don't understand 7.4 is of date March 2010, it should be May 2009 according to http://ftp.gnu.org/gnu/coreutils/, right? No, that just means that whoever pre-built coreutils 7.4 for your distro did so in March 2010, even though they used a tarball from May 2009. You can _always_ use 'sort --version' to find the actual version on your machine (and using --version works for almost every GNU program out there, the few exceptions being programs like /bin/test that have behavior mandated by POSIX when given a single argument). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#6427: Autotest: enable colored test results.
* Pádraig Brady wrote on Tue, Jun 15, 2010 at 11:50:01AM CEST:
On 14/06/10 21:23, Eric Blake wrote:
ls --color = color
ls --color=yes = color
ls --color=auto = plain
ls --color=always = color
grep --color = plain
grep --color=yes = color
grep --color=auto = plain
grep --color=always = color
That is, ls --color implies ls --color=always, while grep --color
implies grep --color=always.
grep --color=auto you mean.
It's probably worth a bug report to coreutils (cc'd), since I prefer the
grep behavior. Should we also raise a bug against the GNU Coding
Standards to codify a preferred variant?
Yes I prefer the grep behavior, but I'm not sure we can
change ls at this stage?
I don't know either. However, I also think Autotest need not wait for
standardization in order to gain color support. We can still fix the
details later.
ls has these synonyms:
always, yes, force,
never, no, none,
auto, tty, if-tty, NULL
We only document the first column which is a good thing.
I agree, and implemented that in the updated patch.
I've wondered about how general the color codes we use are.
Using termcap/terminfo would be most general but since
we've had no reports about it yet I think we should stick
with the simple hardcoded scheme.
I.E. the following currently outputs colors:
TERM=dumb ls --color=auto
I regard it as fairly unproblematic if --color does the wrong thing on a
dumb terminal for now (Automake hasn't seen a bug report to this end
yet either). Thanks for the suggestions.
In the attched patch, I also moved the AT_COLOR_TESTS entry up a bit,
because the paragraph after AT_TESTED really belongs to the macro
definition. And added another diversion HELP_TUNING_BEGIN, to cope with
the ordering issues.
The patch below has --color equal --color=always. Since I'm less
concerned about this detail than about the fact that the patch may not
go in at all, I'm adding a second patch, to be squashed in with the
first, if you prefer --color to be equal to --color=auto.
OK to commit 1 or 1+2?
Thanks,
Ralf
Autotest: enable colored test results.
* lib/autotest/general.m4 (HELP_TUNING_BEGIN): New diversion.
(HELP_TUNING, HELP_OTHER, HELP_END): Bump diversion numbers.
(AT_INIT): Accept
--color and --color=never|auto|always. If desired, colorize
test results and testsuite summary on standard output.
[HELP_TUNING]: Divert content instead to ...
[HELP_TUNING_BEGIN]: ... this diversion, m4_wrapped until the
end, when we know whether AT_COLOR_TESTS has been specified.
(AT_COLOR_TESTS): New macro, set the default for color to auto.
* doc/autoconf.texi (Writing Testsuites): Document it.
(testsuite Invocation): Document --color* options.
* tests/local.at: Call AT_COLOR_TESTS for Autoconf's testsuite.
* tests/autotest.at (color test results): New test, mirroring
color.test from Automake.
* NEWS: Update.
diff --git a/NEWS b/NEWS
index f2290a1..0ff482f 100644
--- a/NEWS
+++ b/NEWS
@@ -36,6 +36,8 @@ GNU Autoconf NEWS - User visible changes.
AT_ARG_OPTION has been changed in that the negative of a long option
--OPTION is now --no-OPTION rather than --noOPTION.
+** Autotest testsuites may optionally provide colored test results.
+
* Major changes in Autoconf 2.65 (2009-11-21) [stable]
Released by Eric Blake, based on git versions 2.64.*.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 48f8589..3bb6b6d 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -23478,6 +23478,12 @@ It it recommended that you use a package-specific
prefix to @var{options}
names in order to avoid clashes with future Autotest built-in options.
@end defmac
+...@defmac AT_COLOR_TESTS
+...@atindex{color_tests}
+Enable colored test results by default when the output is connected to
+a terminal.
+...@end defmac
+
@defmac AT_TESTED (@var{executables})
@atindex{TESTED}
Log the file name and answer to @option{--version} of each program in
@@ -23868,6 +23874,14 @@ then concurrently running tests will finish before
exiting.
Force more verbosity in the detailed output of what is being done. This
is the default for debugging scripts.
+...@item --color
+...@itemx --co...@r{[}=never@r{|}a...@r{|}alw...@r{]}
+Enable colored test results. Without an argument, or with @samp{always},
+test results will be colored. With @samp{never}, color mode is turned
+off. Otherwise, if either the macro @code{AT_COLOR_TESTS} is used by
+the testsuite author, or the argument @samp{auto} is given, then test
+results are colored if standard output is connected to a terminal.
+
@item --debug
@itemx -d
Do not remove the files after a test group was performed ---but they are
diff --git a/lib/autotest/general.m4 b/lib/autotest/general.m4
index 0bc529f..68b80b4 100644
--- a/lib/autotest/general.m4
+++ b/lib/autotest/general.m4
@@ -62,8 +62,10 @@ Copyright (C) 2000, 2001, 2002, 2003, 2004, 2005, 2006,
2007, 2008,
# -
