Re: use maintainer-makefile
Jim Meyering j...@meyering.net writes: Simon Josefsson wrote: Hi! The patch below makes coreutils use maint.mk from gnulib. The maint.mk files are now almost the same, so I hope this is acceptable. You'll have to update the gnulib subproject to 7f62c240e to make bootstrap import the new maint.mk though, and I don't know how that is handled in coreutils. What do you think? Hi Simon, Thank you. Great! To update the submodule to latest, I did this: ( cd gnulib git pull ) then ran git commit --amend -a to add that change to your change set. I didn't know this command, thanks for explaining. /Simon ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: make check problems with coreutils 7.2 and earlier
Erik Auerswald wrote: On Fri, Apr 24, 2009 at 07:26:45AM +0200, Jim Meyering wrote: Tim Mooney wrote: ./configure --prefix=/local/gnu --exec-prefix=/local/gnu --build x86_64-sun-solaris2.10 --sysconfdir=/etc/local/gnu --libdir=/local/gnu/lib/64 --mandir=/local/gnu/share/man --infodir=/local/gnu/share/info --localstatedir=/var/local/gnu --disable-nls checking for a BSD-compatible install... /local/gnu/bin/ginstall -c checking whether build environment is sane... yes Considering all of the programs from /usr/xpg4/bin mentioned in that output, I suspect you have an unusual PATH. What is your PATH? Just for info: the /usr/xpg4/bin directory is one of several to make Solaris standards compliant. You can use different binary dirs to have compliance to different versions of the standards. Sorry, I don't have access to a Solaris machine right now, so I can't check all the details. Thanks, I have long experience with Solaris' /usr/xpg4/bin. I don't expect that there's anything wrong with using those tools at all, and confirmed that coreutils-7.2 built and passed tests with /usr/xpg4/bin first in the shell's search path. However, it is unusual enough to put that directory so early in ones path that I suspect there might be something else unusual about Tim's PATH. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: use maintainer-makefile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 4/23/2009 11:45 PM: To update the submodule to latest, I did this: ( cd gnulib git pull ) then ran git commit --amend -a to add that change to your change set. You can also run: git submodule foreach git pull origin master to avoid the subshell. Personally, I did: git config --global alias.syncsub \ 'submodule foreach git pull origin master' so that I can just do 'git syncsub' to get the same effect. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknxp9QACgkQ84KuGfSFAYB4iQCgmkKn7EG1yAazz4jOYrINjv3N cgUAnie8yxQmsbqp6HQ7N313l9qLEOnw =kfsp -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: join utility segfults
Ondřej Vašík wrote: Pádraig Brady wrote: Roman Kirillov wrote: [kiril...@chiark py-src]$ join s1.txt s2.txt Segmentation fault files: http://sigizmund.info/upload/s12.tgz (28 mb) This issue seems related to the i18n patch applied by your distro Just would like to add that it's already fixed in Fedora rawhide package, so I'll fix it in next Fedora coreutils update for F-9/F-10. In F-8 not, it's already EOL. To keep the list informed about the conclusion... It turned out that it was not really fixed in rawhide at the time of my reply. Just due to better memory management change in join.c done by Bo Borgerson between 6.12 and 7.0 was the occurance chance of the segfault reduced from 100% to ~10%. After investigation of the problem the culprit is now known. Multibyte patch was checking for exact equality/non-equality with the limit of the file, so the limit was skipped(and therefore SIGSEGV occured). Problem was fixed and built in koji (Rawhide branch) as http://koji.fedoraproject.org/koji/buildinfo?buildID=99330 and reported against RHEL-5 as https://bugzilla.redhat.com/show_bug.cgi?id=497368 . Patch to fix the issue could be found in that bugzilla, should work for affected Fedora's and RHEL (or derived Distros). Additionally the issue could be easily workarounded by using singlebyte locales (e.g. LC_ALL=C join). Greetings, Ondřej Vašík signature.asc Description: Toto je digitálně podepsaná část zprávy ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: make check problems with coreutils 7.2 and earlier
Hello Jim, On Fri, Apr 24, 2009 at 07:26:45AM +0200, Jim Meyering wrote: Tim Mooney wrote: ./configure --prefix=/local/gnu --exec-prefix=/local/gnu --build x86_64-sun-solaris2.10 --sysconfdir=/etc/local/gnu --libdir=/local/gnu/lib/64 --mandir=/local/gnu/share/man --infodir=/local/gnu/share/info --localstatedir=/var/local/gnu --disable-nls checking for a BSD-compatible install... /local/gnu/bin/ginstall -c checking whether build environment is sane... yes Considering all of the programs from /usr/xpg4/bin mentioned in that output, I suspect you have an unusual PATH. What is your PATH? Just for info: the /usr/xpg4/bin directory is one of several to make Solaris standards compliant. You can use different binary dirs to have compliance to different versions of the standards. Sorry, I don't have access to a Solaris machine right now, so I can't check all the details. Best regards, Erik -- But if you assume a bomb as small as the non-functioning space in a wristwatch can blow up an airplane, you've got problems far bigger than one particular brand of wristwatch. -- Bruce Schneier ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] mv: do not produce diagnostics for xattr/selinux preserving failures
Hello,
Ondřej Vašík wrote:
Jim Meyering píše v Pá 17. 04. 2009 v 13:54 +0200:
Ondřej Vašík wrote:
as reported in rhbz #496142 by Eric Sandeen, mv produces a lot of
unwanted messages when moving files to filesystem without xattr support.
I guess mv selinux/xattr diagnostic error messages should be reduced as
is done for cp -a, attached patch should do that.
...
+ mv: do not produce diagnostic errors for preserving xattr's to
+ prevent message spam on file systems without xattr support.
Thanks for the patch, but mv's charter is stricter than that of cp -a.
I.e., people expect mv to preserve all attributes when the source
and destination are on the same file system, so IMHO, failure to
preserve any attribute (e.g., for an inter-device mv) requires
_some_ diagnosis.
However, when there are many files, and mv is failing to preserve some
attribute repeatedly, it would make sense to print only the first N
such diagnostics, and then for the N+1st, print one more saying that
there have been additional attribute-preservation failures, but mv will
not display any more.
Changing proposed patch to not display diagnostics for ENODATA and
ENOTSUP errno's - as is done for mv and SELinux contexts.
Actually I found that it was not exactly the same - as for
require-preserve=xattr error was hidden even for the failure. This
should be addressed by the first patch.
It reminds me another issue - due to reduce_diagnostic, if you use cp -a
--preserve=xattr,context , failure diagnostic is reduced, but the
command itself fails. Additionally for cp and --require-preserve=context
and ENODATA/ENOTSUP errors on destination filesystem cp just passes
without error - with no context preserved. All those things are
addressed by the second patch.
Greetings,
Ondřej Vašík
From 3bf0e97d6564ef1aee5a4bf97931884df1b9501a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ond=C5=99ej=20Va=C5=A1=C3=ADk?= ova...@redhat.com
Date: Fri, 17 Apr 2009 11:00:35 +0200
Subject: [PATCH] mv: do not produce xattr preserving failures when not supported by filesystem
*src/copy.c: Do not show error diagnostics when xattrs not supported and
preservation of xattrs is not explicitly required (reported by
Eric Sandeen in rhbz #496142)
---
NEWS |3 +++
src/copy.c | 20 ++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index d8ffde0..063d07f 100644
--- a/NEWS
+++ b/NEWS
@@ -42,6 +42,9 @@ GNU coreutils NEWS-*- outline -*-
LS_COLORS environment variable. To disable it you can add something like
this to your profile: eval `dircolors | sed s/hl=[^:]*:/hl=:/`
+ mv: do not produce diagnostic errors for preserving xattr's on file
+ systems without xattr support.
+
* Noteworthy changes in release 7.1 (2009-02-21) [stable]
diff --git a/src/copy.c b/src/copy.c
index 9b0e139..d9db23c 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -139,6 +139,22 @@ copy_attr_error (struct error_context *ctx ATTRIBUTE_UNUSED,
int err = errno;
va_list ap;
+ if (errno != ENOTSUP errno != ENODATA)
+{
+ /* use verror module to print error message */
+ va_start (ap, fmt);
+ verror (0, err, fmt, ap);
+ va_end (ap);
+}
+}
+
+static void
+copy_attr_allerror (struct error_context *ctx ATTRIBUTE_UNUSED,
+ char const *fmt, ...)
+{
+ int err = errno;
+ va_list ap;
+
/* use verror module to print error message */
va_start (ap, fmt);
verror (0, err, fmt, ap);
@@ -163,7 +179,7 @@ copy_attr_by_fd (char const *src_path, int src_fd,
{
struct error_context ctx =
{
-.error = copy_attr_error,
+.error = x-require_preserve_xattr ? copy_attr_allerror : copy_attr_error,
.quote = copy_attr_quote,
.quote_free = copy_attr_free
};
@@ -177,7 +193,7 @@ copy_attr_by_name (char const *src_path, char const *dst_path,
{
struct error_context ctx =
{
-.error = copy_attr_error,
+.error = x-require_preserve_xattr ? copy_attr_allerror : copy_attr_error,
.quote = copy_attr_quote,
.quote_free = copy_attr_free
};
--
1.5.6.1.156.ge903b
From 5023cacf5c62c95b1f9c41ef7c7684209a5abc82 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ond=C5=99ej=20Va=C5=A1=C3=ADk?= ova...@redhat.com
Date: Fri, 24 Apr 2009 14:29:45 +0200
Subject: [PATCH] cp: diagnose failure when preserving xattr/context required even with -a option
* src/copy.c (copy_attr_by_fs): Always show diagnostics when preserving xattrs
is required
(copy_attr_by_name): Likewise
(copy_reg): Always show diagnostics when preserving SELinux
context is required
(copy_internal): Likewise + Do not ignore ENOTSUP and ENODATA
errors when preserving SELinux context is required
* NEWS (Bug fixes): mention it
---
NEWS |5 +
src/copy.c | 16 +---
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/NEWS b/NEWS
index 063d07f..b3fb475 100644
--- a/NEWS
+++
[PATCH] build: use automake's new $(AM_V_GEN) and $(AM_V_at) variables
With the change below, the default build output for generated files in src/ is slightly more succinct: $ cd src make GEN wheel.h GEN wheel-size.h GEN version.h GEN version.c GEN fs.h make all-am make[1]: Entering directory `/h/meyering/w/co/coreutils/src' CC version.o CC uname.o CC hostid.o ... From 207daac5c1e9b22348d65439281f4da6dce9bdb2 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Fri, 24 Apr 2009 15:16:46 +0200 Subject: [PATCH] build: use automake's new $(AM_V_GEN) and $(AM_V_at) variables * src/Makefile.am (dircolors.h, wheel-size.h, wheel.h, fs.h): (version.c, version.h): Mark with $(AM_V_GEN) and $(AM_V_at), so that the latest automake prints GEN $@ by default. --- src/Makefile.am | 56 ++ 1 files changed, 31 insertions(+), 25 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index a266d7b..1997573 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -290,26 +290,29 @@ editpl = sed -e 's,@''PERL''@,$(PERL),g' BUILT_SOURCES += dircolors.h dircolors.h: dcgen dircolors.hin - @rm -f $@ $...@-t - $(PERL) -w -- $(srcdir)/dcgen $(srcdir)/dircolors.hin $...@-t - @chmod a-w $...@-t - mv $...@-t $@ + $(AM_V_GEN) + $(AM_V_at)rm -f $@ $...@-t + $(AM_V_at)$(PERL) -w -- $(srcdir)/dcgen $(srcdir)/dircolors.hin $...@-t + $(AM_V_at)chmod a-w $...@-t + $(AM_V_at)mv $...@-t $@ wheel_size = 5 BUILT_SOURCES += wheel-size.h wheel-size.h: Makefile.am - @rm -f $@ $...@-t - echo '#define WHEEL_SIZE $(wheel_size)' $...@-t - @chmod a-w $...@-t - mv $...@-t $@ + $(AM_V_GEN) + $(AM_V_at)rm -f $@ $...@-t + $(AM_V_at)echo '#define WHEEL_SIZE $(wheel_size)' $...@-t + $(AM_V_at)chmod a-w $...@-t + $(AM_V_at)mv $...@-t $@ BUILT_SOURCES += wheel.h wheel.h: wheel-gen.pl Makefile.am - @rm -f $@ $...@-t - $(srcdir)/wheel-gen.pl $(wheel_size) $...@-t - @chmod a-w $...@-t - mv $...@-t $@ + $(AM_V_GEN) + $(AM_V_at)rm -f $@ $...@-t + $(AM_V_at)$(srcdir)/wheel-gen.pl $(wheel_size) $...@-t + $(AM_V_at)chmod a-w $...@-t + $(AM_V_at)mv $...@-t $@ # false exits nonzero even with --help or --version. # test doesn't support --help or --version. @@ -318,25 +321,28 @@ AM_INSTALLCHECK_STD_OPTIONS_EXEMPT = false test BUILT_SOURCES += fs.h fs.h: stat.c extract-magic - rm -f $@ - $(PERL) $(srcdir)/extract-magic $(srcdir)/stat.c $...@t - @chmod a-w $...@t - mv $...@t $@ + $(AM_V_GEN) + $(AM_V_at)rm -f $@ + $(AM_V_at)$(PERL) $(srcdir)/extract-magic $(srcdir)/stat.c $...@t + $(AM_V_at)chmod a-w $...@t + $(AM_V_at)mv $...@t $@ BUILT_SOURCES += version.c version.c: Makefile - rm -f $@ - printf '#include config.h\n' $...@t - printf 'char const *Version = $(PACKAGE_VERSION);\n' $...@t - @chmod a-w $...@t - mv $...@t $@ + $(AM_V_GEN) + $(AM_V_at)rm -f $@ + $(AM_V_at)printf '#include config.h\n' $...@t + $(AM_V_at)printf 'char const *Version = $(PACKAGE_VERSION);\n' $...@t + $(AM_V_at)chmod a-w $...@t + $(AM_V_at)mv $...@t $@ BUILT_SOURCES += version.h version.h: Makefile - rm -f $@ - printf 'extern char const *Version;\n' $...@t - @chmod a-w $...@t - mv $...@t $@ + $(AM_V_GEN) + $(AM_V_at)rm -f $@ + $(AM_V_at)printf 'extern char const *Version;\n' $...@t + $(AM_V_at)chmod a-w $...@t + $(AM_V_at)mv $...@t $@ DISTCLEANFILES = version.c version.h MAINTAINERCLEANFILES = $(BUILT_SOURCES) -- 1.6.3.rc1.223.g2f326 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] mv: do not produce diagnostics for xattr/selinux preserving failures
Ondřej Vašík wrote:
Ondřej Vašík wrote:
It reminds me another issue - due to reduce_diagnostic, if you use cp -a
--preserve=xattr,context , failure diagnostic is reduced, but the
command itself fails. Additionally for cp and --require-preserve=context
and ENODATA/ENOTSUP errors on destination filesystem cp just passes
without error - with no context preserved. All those things are
addressed by the second patch.
The second patch was incorrect, sorry, it's Friday afternoon...
corrected version attached...
Greetings,
Ondřej
From 0191d1b04d89e29d346a941246ffc27c4248438e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ond=C5=99ej=20Va=C5=A1=C3=ADk?= ova...@redhat.com
Date: Fri, 24 Apr 2009 14:29:45 +0200
Subject: [PATCH] cp: diagnose failure when preserving xattr/context required even with -a option
* src/copy.c (copy_attr_by_fs): Always show diagnostics when preserving xattrs
is required
(copy_attr_by_name): Likewise
(copy_reg): Always show diagnostics when preserving SELinux
context is required
(copy_internal): Likewise + Do not ignore ENOTSUP and ENODATA
errors when preserving SELinux context is required
* NEWS (Bug fixes): mention it
---
NEWS |5 +
src/copy.c | 16 +---
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/NEWS b/NEWS
index 063d07f..b3fb475 100644
--- a/NEWS
+++ b/NEWS
@@ -19,6 +19,11 @@ GNU coreutils NEWS-*- outline -*-
The bug strikes only with both --recursive (-r, -R) and --link (-l).
[bug introduced in coreutils-7.1]
+ cp now correctly diagnoses selinux/xattr failures when option
+ --preserve=context,xattr is specified with combination with option -a.
+ Additionally do not ignore unsupported operation error when preserving
+ SELinux context was explicitly requested.
+
ls --sort=version (-v) sorted names beginning with . inconsistently.
Now, names that start with . are always listed before those that don't.
diff --git a/src/copy.c b/src/copy.c
index d9db23c..6450826 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -184,7 +184,8 @@ copy_attr_by_fd (char const *src_path, int src_fd,
.quote_free = copy_attr_free
};
return 0 == attr_copy_fd (src_path, src_fd, dst_path, dst_fd, 0,
-x-reduce_diagnostics ? NULL : ctx);
+(x-reduce_diagnostics
+ !x-require_preserve_xattr)? NULL : ctx);
}
static bool
@@ -198,7 +199,8 @@ copy_attr_by_name (char const *src_path, char const *dst_path,
.quote_free = copy_attr_free
};
return 0 == attr_copy_file (src_path, dst_path, 0,
- x- reduce_diagnostics ? NULL :ctx);
+ (x- reduce_diagnostics
+!x-require_preserve_xattr)? NULL :ctx);
}
#else /* USE_XATTR */
@@ -481,7 +483,7 @@ copy_reg (char const *src_name, char const *dst_name,
security_context_t con = NULL;
if (getfscreatecon (con) 0)
{
- if (!x-reduce_diagnostics)
+ if (!x-reduce_diagnostics || x-require_preserve_context)
error (0, errno, _(failed to get file system create context));
if (x-require_preserve_context)
{
@@ -494,7 +496,7 @@ copy_reg (char const *src_name, char const *dst_name,
{
if (fsetfilecon (dest_desc, con) 0)
{
- if (!x-reduce_diagnostics)
+ if (!x-reduce_diagnostics || x-require_preserve_context)
error (0, errno,
_(failed to set the security context of %s to %s),
quote_n (0, dst_name), quote_n (1, con));
@@ -1747,7 +1749,7 @@ copy_internal (char const *src_name, char const *dst_name,
{
if (setfscreatecon (con) 0)
{
- if (!x-reduce_diagnostics)
+ if (!x-reduce_diagnostics || x-require_preserve_context)
error (0, errno,
_(failed to set default file creation context to %s),
quote (con));
@@ -1761,9 +1763,9 @@ copy_internal (char const *src_name, char const *dst_name,
}
else
{
- if (errno != ENOTSUP errno != ENODATA)
+ if ((errno != ENOTSUP errno != ENODATA) || x-require_preserve_context)
{
- if (!x-reduce_diagnostics)
+ if (!x-reduce_diagnostics || x-require_preserve_context)
error (0, errno,
_(failed to get security context of %s),
quote (src_name));
--
1.5.6.1.156.ge903b
signature.asc
Description: Toto je digitálně podepsaná část zprávy
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: use maintainer-makefile
Eric Blake wrote: You can also run: git submodule foreach git pull origin master to avoid the subshell. Personally, I did: git config --global alias.syncsub \ 'submodule foreach git pull origin master' so that I can just do 'git syncsub' to get the same effect. Much nicer. Thanks! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: make check problems with coreutils 7.2 and earlier
In regard to: Re: make check problems with coreutils 7.2 and earlier, Jim...:
Considering all of the programs from /usr/xpg4/bin mentioned
in that output, I suspect you have an unusual PATH.
What is your PATH?
/local/bin:/local/sbin:/local/krb5/bin:/local/krb5/sbin:/usr/j2se/bin:/opt/SUNWspro/bin:/usr/xpg4/bin:/usr/bin:/usr/ccs/bin:/usr/sbin:/sbin:/usr/sadm/bin:/usr/ucb:/usr/games:/local/gnu/bin:/faculty/ndsu/mooney/bin:/local/tex/bin:/local/bin/X11:/usr/X11/bin:/usr/openwin/bin:/usr/dt/bin:/local/gnu/bin/X11:/opt/openoffice.org3/program:.
It might be useful also to add an echo PATH: $PATH to one of the
tests and check the .log file to see if that prints anything different.
Ok, did that with misc/help-version, and the PATH is exactly the same
as shown above:
FAIL: misc/help-version.log (exit: 1)
=
+ test x/local/gnu/bin/bash = x
+ export SHELL
+ . ./test-lib.sh
++ unset function_test
++ eval 'function_test() { return 11; }; function_test'
+++ function_test
+++ return 11
++ test 11 '!=' 11
+++ pwd
++ test_dir_=/local/src/RPM/BUILD/coreutils-7.2/tests
+++ this_test_
+++ echo ././misc/help-version
+++ sed 's,.*/,,'
++ this_test=help-version
+++ /local/src/RPM/BUILD/coreutils-7.2/src/mktemp -d --tmp=/local/src/RPM/BUILD/
coreutils-7.2/tests cu-help-version.XX
++ t_=/local/src/RPM/BUILD/coreutils-7.2/tests/cu-help-version.29Q48d3pLw
++ trap remove_tmp_ 0
++ trap 'Exit $?' 1 2 13 15
++ cd /local/src/RPM/BUILD/coreutils-7.2/tests/cu-help-version.29Q48d3pLw
++ diff --version
++ grep GNU
++ cmp --version
++ grep GNU
+ echo 'Start of misc/help-version, PATH: /local/bin:/local/sbin:/local/krb5/bin
:/local/krb5/sbin:/usr/j2se/bin:/opt/SUNWspro/bin:/usr/xpg4/bin:/usr/bin:/usr/cc
s/bin:/usr/sbin:/sbin:/usr/sadm/bin:/usr/ucb:/usr/games:/local/gnu/bin:/faculty/
ndsu/mooney/bin:/local/tex/bin:/local/bin/X11:/usr/X11/bin:/usr/openwin/bin:/usr
/dt/bin:/local/gnu/bin/X11:/opt/openoffice.org3/program:.'
Start of misc/help-version, PATH: /local/bin:/local/sbin:/local/krb5/bin:/local/
krb5/sbin:/usr/j2se/bin:/opt/SUNWspro/bin:/usr/xpg4/bin:/usr/bin:/usr/ccs/bin:/u
sr/sbin:/sbin:/usr/sadm/bin:/usr/ucb:/usr/games:/local/gnu/bin:/faculty/ndsu/moo
ney/bin:/local/tex/bin:/local/bin/X11:/usr/X11/bin:/usr/openwin/bin:/usr/dt/bin:
/local/gnu/bin/X11:/opt/openoffice.org3/program:.
+ expected_failure_status_nohup=127
+ expected_failure_status_timeout=125
+ expected_failure_status_printenv=2
+ expected_failure_status_tty=3
+ expected_failure_status_sort=2
+ expected_failure_status_expr=3
+ expected_failure_status_lbracket=2
+ expected_failure_status_dir=2
+ expected_failure_status_ls=2
+ expected_failure_status_vdir=2
[remaining output elided]
Even if I modify my environment so that xpg4 is not in my PATH, I get the
same results.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: list statistical properties for the list of files passed
James Youngman wrote:
It's not such a great idea to do that. Far better to chop that up
into at least 1000 subdirectories. But take care not to use more than
about 32,000 subdirectories, as some Linux filesystems either don't
allow it (ext3) or some operations become less efficient at that point
(ext4's st_nlink changes meaning).
Totally agree with you. Unfortunately I'm barred from waking the system
architects with my Cluex4 :
http://farm4.static.flickr.com/3662/3468737759_2e788e9576.jpg?v=0
i have been awaken already too many times in the middle of the night by the
filesystem reaching 98% inode capacity
I'm not sure determine_median_access_time has such a big potential
user base, to be honest.
However, I'm not sure what your performance requirements are, but if
performance is an issue, bear in mind that there are several
partitioning algorithms that allow you to find the median of a dataset
without fully sorting it.
James.
nothing that complicated: find /path/to/dir/with/10M/files -type f
+atime $MEDIAN_FILE_DATE -exec rm -f {} \;
this runs sparingly enough and the server generates enough files to
usually get rid of a couple of million files which have a date stamp of
the most busiest days older than 30-40 days, without me having to
investigate the filesystem. Yes, I am lazy :))
thank you for the reply. next time i'm in boston, i promise to drop a
case of Tanglefoot Ale http://www.tanglefoot.co.uk/ into the FSF offices
as a thank you.
PS (lack of tanglefoot, it'll be sammy adams honey wheat :D )
George
--
Check out our new sister company - www.wrenkitchens.com - 0845 404 1000 -
Quality Kitchens at Affordable Prices
-
Ebuyer is a limited company registered in England, 03941136, Ebuyer UK Limited,
Howden, East Yorkshire, DN14 7UW.
Ebuyer UK Limited is registered as a producer under the Waste Electrical and
Electronic Equipment Directive (2002/96/EC): WEE/FK0254QU
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: join utility segfults
Chaps, Adding Vartika from our Linux support team to the chain – he's got some questions to ask. In the meanwhile, he's a contact person at Y! regarding this. R -- Roman Kirillov Yahoo! GeoInformatics Group Y!Im: roman.kirillov | kiril...@yahoo-inc.com | +44(0)2071311384 On 24 Apr 2009, at 11:59, Ondřej Vašík wrote: Ondřej Vašík wrote: Pádraig Brady wrote: Roman Kirillov wrote: [kiril...@chiark py-src]$ join s1.txt s2.txt Segmentation fault files: http://sigizmund.info/upload/s12.tgz (28 mb) This issue seems related to the i18n patch applied by your distro Just would like to add that it's already fixed in Fedora rawhide package, so I'll fix it in next Fedora coreutils update for F-9/F-10. In F-8 not, it's already EOL. To keep the list informed about the conclusion... It turned out that it was not really fixed in rawhide at the time of my reply. Just due to better memory management change in join.c done by Bo Borgerson between 6.12 and 7.0 was the occurance chance of the segfault reduced from 100% to ~10%. After investigation of the problem the culprit is now known. Multibyte patch was checking for exact equality/non-equality with the limit of the file, so the limit was skipped(and therefore SIGSEGV occured). Problem was fixed and built in koji (Rawhide branch) as http://koji.fedoraproject.org/koji/buildinfo?buildID=99330 and reported against RHEL-5 as https://bugzilla.redhat.com/show_bug.cgi?id=497368 . Patch to fix the issue could be found in that bugzilla, should work for affected Fedora's and RHEL (or derived Distros). Additionally the issue could be easily workarounded by using singlebyte locales (e.g. LC_ALL=C join). Greetings, Ondřej Vašík ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: join utility segfults
Thanks Roman! BTW, I am a she :) I see the RHEL5 bugzilla# in the email chain. Is there one for RHEL4 as well? I doubt this will be fixed in RHEL4 though but I'll open a Yahoo ticket with RH to make sure we are aware of which RHEL5 release the fix gets targeted to. I'll update the internal ticket with this information. Vartika -Original Message- From: Roman Kirillov Sent: Friday, April 24, 2009 11:37 AM To: Ondřej Vašík Cc: Pádraig Brady; bug-coreutils@gnu.org; Vartika Agarwal Subject: Re: join utility segfults Chaps, Adding Vartika from our Linux support team to the chain - he's got some questions to ask. In the meanwhile, he's a contact person at Y! regarding this. R -- Roman Kirillov Yahoo! GeoInformatics Group Y!Im: roman.kirillov | kiril...@yahoo-inc.com | +44(0)2071311384 On 24 Apr 2009, at 11:59, Ondřej Vašík wrote: Ondřej Vašík wrote: Pádraig Brady wrote: Roman Kirillov wrote: [kiril...@chiark py-src]$ join s1.txt s2.txt Segmentation fault files: http://sigizmund.info/upload/s12.tgz (28 mb) This issue seems related to the i18n patch applied by your distro Just would like to add that it's already fixed in Fedora rawhide package, so I'll fix it in next Fedora coreutils update for F-9/F-10. In F-8 not, it's already EOL. To keep the list informed about the conclusion... It turned out that it was not really fixed in rawhide at the time of my reply. Just due to better memory management change in join.c done by Bo Borgerson between 6.12 and 7.0 was the occurance chance of the segfault reduced from 100% to ~10%. After investigation of the problem the culprit is now known. Multibyte patch was checking for exact equality/non-equality with the limit of the file, so the limit was skipped(and therefore SIGSEGV occured). Problem was fixed and built in koji (Rawhide branch) as http://koji.fedoraproject.org/koji/buildinfo?buildID=99330 and reported against RHEL-5 as https://bugzilla.redhat.com/show_bug.cgi?id=497368 . Patch to fix the issue could be found in that bugzilla, should work for affected Fedora's and RHEL (or derived Distros). Additionally the issue could be easily workarounded by using singlebyte locales (e.g. LC_ALL=C join). Greetings, Ondřej Vašík ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Human readable sort
I wrote the following patch to the 7.2 branch of coreutils to allow
`sort` to sort by human readable byte sizes. I looked around a bit to
see what the status of previous attempts to integrate this
functionality were, but didn't see any very recent activity. This is
my first interaction with coreutils, so if I missed something obvious,
please point me towards it.
Is the last potential patch (
http://www.mail-archive.com/bug-coreutils@gnu.org/msg14080.html )
moving through? If not, if I cleaned this up ( tabs, documentation,
and test cases ) and applied it to the current HEAD on savannah is
there a chance of getting this functionality into sort?
Patch assumptions :
* that numbers will use the best representation ( never uses 1024b
instead of 1k, etc )
* that the sizes will be specified via suffixes of b, K, M, G, T, P,
E, Z, Y or their alternately cased variants
The first assumption results in checking only the suffix when they differ.
This enables it to match the output of `du -h / du --si`, but possibly
not other tools that do not conform to these assumptions.
-
--- orig/coreutils-7.2/src/sort.c 2009-03-29 13:44:10.0 -0400
+++ coreutils-7.2/src/sort.c2009-04-24 14:03:47.0 -0400
@@ -176,6 +176,8 @@
bool random; /* Sort by random hash of key. */
bool general_numeric;/* Flag for general, numeric comparison.
Handle numbers in exponential notation. */
+ bool human_numeric; /* Flag for sorting by size specified
+ data */
bool month; /* Flag for comparison by month name. */
bool reverse;/* Reverse the sense of comparison. */
bool version;/* sort by version number */
@@ -426,7 +428,7 @@
SORT_OPTION
};
-static char const short_options[] = -bcCdfgik:mMno:rRsS:t:T:uVy:z;
+static char const short_options[] = -bcCdfghik:mMno:rRsS:t:T:uVy:z;
static struct option const long_options[] =
{
@@ -442,6 +444,7 @@
{merge, no_argument, NULL, 'm'},
{month-sort, no_argument, NULL, 'M'},
{numeric-sort, no_argument, NULL, 'n'},
+ {human-sort, no_argument, NULL, 'h'},
{version-sort, no_argument, NULL, 'V'},
{random-sort, no_argument, NULL, 'R'},
{random-source, required_argument, NULL, RANDOM_SOURCE_OPTION},
@@ -1673,6 +1676,57 @@
return strnumcmp (a, b, decimal_point, thousands_sep);
}
+/* assumes UCHAR_MAX of 255 */
+/* Y/y:8 - K/k:1 , otherwise ( including b ) : 0 */
+const char weights [] =
+ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 6, 0, 3, 0, 0, 0, 1, 0, 2, 0, 0,
+5, 0, 0, 0, 4, 0, 0, 0, 0, 8, 7, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 6, 0, 3, 0, 0, 0, 1, 0, 2, 0, 0,
+5, 0, 0, 0, 4, 0, 0, 0, 0, 8, 7, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } ;
+
+static int
+human_compare(const char *a, const char *b)
+{
+ /* this tests numeric entities ending in human readable size specifiers
+ b K M G T P E Z Y
+ we (rudely I admit) assume that numbers are properly abbreviated.
+ for example, you will never see 500,000,000b, instead of 5M
+ */
+
+ const char * ar, * br ; /* riders */
+ int aw, bw ;
+
+ while(blanks[to_uchar (*a)])
+a++;
+ while(blanks[to_uchar (*b)])
+b++;
+
+ ar = a ;
+ br = b ;
+
+ while( ISDIGIT(*ar) || (*ar) == decimal_point || (*ar) == thousands_sep )
+ar++ ;
+ while( ISDIGIT(*br) || (*br) == decimal_point || (*br) == thousands_sep )
+br++ ;
+
+ aw = weights[to_uchar (*ar)] ;
+ bw = weights[to_uchar (*br)] ;
+
+ return aw bw ? 1 : aw bw ? -1 : strnumcmp( a , b ,
decimal_point , thousands_sep) ;
+}
+
static int
general_numcompare (const char *sa, const char *sb)
{
@@ -1917,6 +1971,10 @@
if (key-random)
diff = compare_random (texta, lena, textb, lenb);
+ else if (key-human_numeric)
+{
+ diff = human_compare(texta, textb);
+}
else if (key-numeric | key-general_numeric)
{
char savea = *lima, saveb = *limb;
@@ -2887,7 +2945,7 @@
for (key = keylist; key; key = key-next)
if ((1 (key-random + key-numeric + key-general_numeric + key-month
- + key-version + !!key-ignore))
+ + key-version + (!!key-ignore) + key-human_numeric))
|| (key-random key-translate))
{
/* The following is too big, but guaranteed to
[PATCH] tests: avoid unusual (~1-in-20) failure of a new test
It was not easy to reproduce this one.
From b726914a4c1ea8f943359d9ad19a09d3ee606694 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 24 Apr 2009 21:34:59 +0200
Subject: [PATCH] tests: avoid unusual (~1-in-20) failure of a new test
* tests/misc/sort: Remove one of the generated tests.
363 remain in this file alone.
---
tests/misc/sort |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/tests/misc/sort b/tests/misc/sort
index a27f47a..c5a2d74 100755
--- a/tests/misc/sort
+++ b/tests/misc/sort
@@ -369,6 +369,14 @@ foreach my $t (@Tests)
@Tests = triple_test \...@tests;
+# Remember that triple_test creates from each test with exactly one IN
+# file two more tests (.p and .r suffix on name) corresponding to reading
+# input from a file and from a pipe. The pipe-reading test would fail
+# due to a race condition about 1 in 20 times.
+# Remove the IN_PIPE version of the output-is-input test above.
+# The others aren't susceptible because they have three inputs each.
+...@tests = grep {$_-[0] ne 'output-is-input.p'} @Tests;
+
my $save_temps = $ENV{DEBUG};
my $verbose = $ENV{VERBOSE};
--
1.6.3.rc1.223.g2f326
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 7.2 on Solaris 10 with Zones
On Thu, Apr 23, 2009 at 10:09:51PM +0200, Jim Meyering wrote: Albert Chin wrote: Just built 7.2 on Solaris 10/SPARC and src/df doesn't seem to like zones: $ src/df ... src/df: `/var/zones/poog/root/.SUNWnative/lib': Permission denied src/df: `/var/zones/poog/root/.SUNWnative/platform': Permission denied src/df: `/var/zones/poog/root/.SUNWnative/usr': Permission denied src/df: `/var/zones/poog/root/dev': Permission denied Hi Albert, Thanks for the report. A good place to start would be to compare truss output for GNU df and the system-supplied df for just one of those partitions. I.e., make Sun's df give some useful info for a single partition, and show that GNU df fails to do the same. Then compare the output of their respect truss runs. Hi, We had a quick look. By default sun's df does not list mounts in other zones, but df -Z does, and gives similar error messages. Looking at the opensolaris sources, df uses undocumented api to find the list of zones and check if mounts are in other zones (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/fs.d/df.c the functions are zone_list, zone_getattr in http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/fs.d/fslib.c). Although those functions appear in zone.h they come after this comment: * Applications using these interfaces may fail to run on future releases. Filesystems mounted in other zones do appear to have a zone=name mount option, but I can not find documentation on this either. That being said, getting the current zone name and checking hasmntopt(zone=) and ! hasmntopt(zone=currentzone) would simply return us to the current situation if the zone= options do disappear from the mount options... but then what if we *want* to list these mounts a.la df -Z? I'm not sure that there is a good answer to this. Peter -- Peter O'Gorman po...@thewrittenword.com ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 7.2 on Solaris 10 with Zones
On Fri, Apr 24, 2009 at 04:23:06PM -0500, Peter O'Gorman wrote: Filesystems mounted in other zones do appear to have a zone=name mount option, but I can not find documentation on this either. That being said, getting the current zone name and checking hasmntopt(zone=) and ! hasmntopt(zone=currentzone) would simply return us to the current situation if the zone= options do disappear from the mount options... but then what if we *want* to list these mounts a.la df -Z? Turns out this only works for nfs mounts, still get errors for lofs/special mounts in other zones. Oh Well. Peter -- Peter O'Gorman po...@thewrittenword.com ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Human readable sort
Michael Speer wrote:
I wrote the following patch to the 7.2 branch of coreutils to allow
`sort` to sort by human readable byte sizes. I looked around a bit to
see what the status of previous attempts to integrate this
functionality were, but didn't see any very recent activity. This is
my first interaction with coreutils, so if I missed something obvious,
please point me towards it.
Is the last potential patch (
http://www.mail-archive.com/bug-coreutils@gnu.org/msg14080.html )
moving through? If not, if I cleaned this up ( tabs, documentation,
and test cases ) and applied it to the current HEAD on savannah is
there a chance of getting this functionality into sort?
Thanks for reviving this again.
There was a more recent attempt that petered out unfortunately:
http://www.mail-archive.com/bug-coreutils@gnu.org/msg14080.html
Patch assumptions :
* that numbers will use the best representation ( never uses 1024b
instead of 1k, etc )
* that the sizes will be specified via suffixes of b, K, M, G, T, P,
E, Z, Y or their alternately cased variants
The first assumption results in checking only the suffix when they differ.
This enables it to match the output of `du -h / du --si`, but possibly
not other tools that do not conform to these assumptions.
The consensus was that these assumptions are appropriate and useful.
We assume C99 support now for coreutils so I tweaked your patch,
the main change being to greatly shrink the lookup table initialisation.
Note I commented out the lower case letters (except 'k') as I don't
think any coreutils generate those and they could preclude supporting
other suffixes in future. I'm not sure about doing that but I think it's
better to err on the side of too few suffixes than too many?
Something else to consider is to flag when
a mixture of SI and IEC units are used, as
this not being supported might not be obvious
to users and could cause difficult to debug issues for users.
I.E. flag an error if the following input is presented.
999MB
998MiB
I added a very quick hack for that to the patch for illustration.
I also noticed that you didn't terminate the fields before
processing as was done for the other numeric sorts?
So I changed that also in the attached patch but didn't
analyze it TBH.
cheers,
Pádraig.
p.s. obviously docs and help and tests need to be written,
but we can do that after we get the implementation done.
diff --git a/src/sort.c b/src/sort.c
index f48d727..a2ed015 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -176,6 +176,7 @@ struct keyfield
bool random; /* Sort by random hash of key. */
bool general_numeric; /* Flag for general, numeric comparison.
Handle numbers in exponential notation. */
+ bool human_numeric; /* Flag for sorting by common suffixes. */
bool month; /* Flag for comparison by month name. */
bool reverse; /* Reverse the sense of comparison. */
bool version; /* sort by version number */
@@ -426,7 +427,7 @@ enum
SORT_OPTION
};
-static char const short_options[] = -bcCdfgik:mMno:rRsS:t:T:uVy:z;
+static char const short_options[] = -bcCdfghik:mMno:rRsS:t:T:uVy:z;
static struct option const long_options[] =
{
@@ -442,6 +443,7 @@ static struct option const long_options[] =
{merge, no_argument, NULL, 'm'},
{month-sort, no_argument, NULL, 'M'},
{numeric-sort, no_argument, NULL, 'n'},
+ {human-sort, no_argument, NULL, 'h'},
{version-sort, no_argument, NULL, 'V'},
{random-sort, no_argument, NULL, 'R'},
{random-source, required_argument, NULL, RANDOM_SOURCE_OPTION},
@@ -1673,6 +1675,54 @@ numcompare (const char *a, const char *b)
return strnumcmp (a, b, decimal_point, thousands_sep);
}
+/* error if a mixture of SI and IEC units used. */
+static void
+check_mixed_SI_IEC (char suffix)
+{
+ static int seen_si = -1;
+ bool si_present = suffix == 'i';
+ if (seen_si != -1 seen_si != si_present)
+error (SORT_FAILURE, 0, _(Both SI and IEC suffixes present));
+ seen_si = si_present;
+}
+
+/* Compare numeric entities ending in human readable size specifiers
+ b K M G T P E Z Y
+ We assume that numbers are properly abbreviated.
+ For example, you will never see 500,000,000b, instead of 5M. */
+
+static int
+human_compare(const char *a, const char *b)
+{
+ static const char weights [] = {
+['K']=1, ['M']=2, ['G']=3, ['T']=4, ['P']=5, ['E']=6, ['Z']=7, ['Y']=8,
+['k']=1, /*['m']=2, ['g']=3, ['t']=4, ['p']=5, ['e']=6, ['z']=7, ['y']=8,*/
+ };
+
+ while (blanks[to_uchar (*a)])
+a++;
+ while (blanks[to_uchar (*b)])
+b++;
+
+ const char *ar = a;
+ const char *br = b;
+
+ while( ISDIGIT (*ar) || (*ar) == decimal_point || (*ar) == thousands_sep )
+ar++;
+ while( ISDIGIT (*br) || (*br) == decimal_point || (*br) == thousands_sep )
+br++;
+
+ check_mixed_SI_IEC (*(ar+1));
+ check_mixed_SI_IEC (*(br+1));
+
+ int aw = weights[to_uchar (*ar)];
+ int bw = weights[to_uchar (*br)];
+
+ return (aw bw ? 1
+
Re: maint.mk questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 4/24/2009 3:22 PM: Yes, it sounds like that would be worthwhile -- at least to you. How about this patch? From: Eric Blake e...@byu.net Date: Fri, 24 Apr 2009 14:58:02 -0600 Subject: [PATCH] vc-list-files: ignore git symlinks * build-aux/vc-list-files (.git): Use ls-tree and a filter, rather than ls-files, to ignore git symlinks. Looks fine. You're welcome to push it. Both the vc-list-files and maint.mk patches are pushed. I also pushed this to coreutils: - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknycsYACgkQ84KuGfSFAYCnWgCg2PKgA3y1BvNXxHx2613K7ZfA 8/sAoJtPsNBU73mlIKxkennOz8Q5nMhA =hYo8 -END PGP SIGNATURE- From c86509d86e3e65c9e3342400b343c13bad0ff2f2 Mon Sep 17 00:00:00 2001 From: Eric Blake e...@byu.net Date: Fri, 24 Apr 2009 20:16:27 -0600 Subject: [PATCH] cfg.mk: update to latest gnulib change * cfg.mk (bootstrap-tools): Override maint.mk default to include bison. * gnulib: Update to latest gnulib. --- cfg.mk |6 +- gnulib |2 +- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/cfg.mk b/cfg.mk index 3012a27..e4f608e 100644 --- a/cfg.mk +++ b/cfg.mk @@ -34,9 +34,13 @@ gpg_key_ID = B9AB9A16 local-checks-to-skip = strftime-check # The local directory containing the checked-out copy of gnulib used in this -# release. Used solely to get gnulib's SHA1 for the announcement target. +# release. Used to get gnulib's SHA1 for the announcement target and +# for signing release tags. gnulib_dir = gnulib +# Tools used to bootstrap this package, used for announcement. +bootstrap-tools = autoconf,automake,gnulib,bison + # Now that we have better tests, make this the default. export VERBOSE = yes diff --git a/gnulib b/gnulib index f937d16..b540166 16 --- a/gnulib +++ b/gnulib @@ -1 +1 @@ -Subproject commit f937d166906633801966f9cf3e0efe6767ed586f +Subproject commit b54016675fd7e8e6b36444cde8ac85ff6302c7ff -- 1.6.1.2 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] build: use automake's new $(AM_V_GEN) and $(AM_V_at) variables
Hi Jim, Jim Meyering writes: --- a/src/Makefile.am +++ b/src/Makefile.am @@ -290,26 +290,29 @@ editpl = sed -e 's,@''PERL''@,$(PERL),g' BUILT_SOURCES += dircolors.h dircolors.h: dcgen dircolors.hin - @rm -f $@ $...@-t - $(PERL) -w -- $(srcdir)/dcgen $(srcdir)/dircolors.hin $...@-t - @chmod a-w $...@-t - mv $...@-t $@ + $(AM_V_GEN) + $(AM_V_at)rm -f $@ $...@-t + $(AM_V_at)$(PERL) -w -- $(srcdir)/dcgen $(srcdir)/dircolors.hin $...@-t + $(AM_V_at)chmod a-w $...@-t + $(AM_V_at)mv $...@-t $@ Thanks for using these. Note the $(AM_V_GEN) will expand to the empty string with V=1 or --disable-silent-rules. I am actually not sure whether any make implementation fails hard upon empty rule commands, but a couple of them will output a warning, such as FreeBSD: $(AM_V_GEN) expands to empty string and AIX: make: 1254-053 Command $(AM_V_GEN) expands to empty string. You might want to just prepend the $(AM_V_GEN) to the next command, without anything in-between. We might want to document this better in automake.texi. Thanks! Ralf ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Fix check-AUTHORS skip logic.
* src/Makefile.am (check-AUTHORS): When this test is skipped, be
sure to avoid all commands in the recipe, not just those passed
to the first shell.
---
Hello,
without this patch, I'm getting the following 'make check' failure:
check-AUTHORS: skipping this check
diff: authors-actual: No such file or directory
make[2]: *** [check-AUTHORS] Error 2
Cheers,
Ralf
src/Makefile.am |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index d8641d7..f7a26a7 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -405,9 +405,9 @@ check-AUTHORS: $(all_programs)
| perl -0 -pi -e 's/,\n/, /gm' \
| sed -n -e '/Written by /{ s//'$$i': /;' \
-e 's/,* and /, /; s/\.$$//; p; }'; \
- done $(au_actual)
- @sed -n '/^[^ ][^ ]*:/p' $(top_srcdir)/AUTHORS $(au_dotdot)
- @diff $(au_actual) $(au_dotdot) rm -f $(au_actual) $(au_dotdot)
+ done $(au_actual) \
+ sed -n '/^[^ ][^ ]*:/p' $(top_srcdir)/AUTHORS $(au_dotdot) \
+ diff $(au_actual) $(au_dotdot) rm -f $(au_actual) $(au_dotdot)
# The following rule is not designed to be portable,
# and relies on tools that not everyone has.
--
1.6.1.505.gba743
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
