bug#14025: Configure problem in coreutils 8.13
Configure problem in coreutils 8.13 To: 1 Background The release used was NOT the latest, so it is quite likely that these matters have been previously addressed. On the other hand, it is possible that installation has not been attempted for this actual Unix version. Running Mac OS X: System Version: Mac OS X 10.5.8 (9L30) Kernel Version: Darwin 9.8.0 >uname -mpv Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386 The reason for installing 8.13 was that version 8.21 from the ftp area (ftp://ftp.gnu.org/gnu/coreutils/) was an xz version and there seemed to be no support for that format on this machine. The latest gz was 8.13 from Sep 2011, so also downloaded version 8.13, and proceeded to install this. This problem was formerly included in bug#13912, but has now been split off from other topics covered there. 2 Failure When `make' was run, many errors were reported, concerning expr.c The first error is expr.c:54:18: error: gmp.h: No such file or directory Noted that config.status has D["HAVE_GMP"]=" 1" and the expr.c source tests this. It seems that configure has incorrectly decided that gmp is available, and expr.c fails to find the header, and all other errors arise from this. Since the expr.c source allowed for the test failing, it seemed possible to proceed without gmp. So config.status was modified so that D["HAVE_GMP"]=" 0" then make reran OK. This seems to confirm that the problem is in configure. 3 Extra Information It was only later that it was realised that configure --help included: From --help --without-gmp do not use the GNU MP library for arbitrary precision calculation (default: use it if available) End from --help The optional nature of gmp and this option ought to be included in the README. However, the decision made by configure "use it if available" still seems incorrect. Although gmp was not installed at the time, there was a source download in a nearby directory. The download of gcc-4.7.2 was being prepared for building. It had previously been established that gmp was a Prerequisite, so it was placed ready to be installed along with the gcc sources. Directories: /Gnu/coreutils/coreutils-8.13 Being used to build coreutils. /Gnu/gcc/src/gcc-4.7.2/ Sources preparing for installation /Gnu/gcc/obj/ Area for building /Gnu/gmp/gmp-5.1.0 Sources preparing for installation The gcc directory includes a link for gmp /Gnu/gcc/src/gcc-4.7.2/gmp -> /Gnu/gmp/gmp-5.1.0 (As suggested in the gcc downloading information: "Likewise the GMP, MPFR and MPC libraries can be automatically built together with GCC. Unpack the GMP, MPFR and/or MPC source distributions in the directory containing the GCC sources and rename their directories to gmp, mpfr and mpc, respectively (or use symbolic links with the same name)." It is possible that one of these gmp directories was identified by configure. 4 Conclusion The config.log file is available (5.3MB), plus config.status (96kB). There is also a file from redirecting standard output during the run of configure (60kB). If extra information about the matters reported above would be of value please contact: extralevelinsoftw...@ntlworld.com Ellis N. Thomas/21-Mar-2013
bug#13912: Feedback on coreutils 8.13
Bob, Thanks for your reply. Actually I don't think details of MacOS itself matter very much. In this case I am using it at the Unix level, using xterm. The Mac windows interface runs on top of the Darwin Unix kernel. At xterm level, much of the available set of commands seems to be Gnu derived anyway, such as bash --version GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0) gcc --version i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465) As included in my original message, the use of "make check" reported an error, that might be new for this Darwin release, "FAIL: install/install-C". In addition, failures that were already described in the README from coreutils 8.13 for Darwin 9.1 were not reported for Darwin 9.8.0. As I said before: "The different effect for this Mac version might or might not be of relevance to Gnu developers!". If it would help, I am prepared to make separate bug reports for these matters. On the other hand perhaps there is no point in following up problems in this old version of coreutils. (What I wanted is working OK.) Thanks Ellis On 16 Mar 2013, at 04:24, Bob Proulx wrote: It was a comment that Alan had already spoken what he knew and didn't know more about MacOS to say any more than that. And I am in the same position. I don't use MacOS and so know nothing about it. I can only suggest that someone else who knows about MacOS would need to jump in and help. ... The bug-coreutils@gnu.org address is used for bug tracking. As you can see from the email every message there creates a bug ticket in the bug tracking system. Which is great for tracking individual bugs so that they do not get lost. (Please submit one bug per bug report.
bug#14024: Test failure in coreutils 8.13
Test failure in coreutils 8.13 To: 1 Background The release used was NOT the latest, so it is quite likely that these matters have been previously addressed. On the other hand, it is possible that installation has not been attempted for this actual Unix version. Running Mac OS X: System Version: Mac OS X 10.5.8 (9L30) Kernel Version: Darwin 9.8.0 >uname -mpv Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386 The reason for installing 8.13 was that version 8.21 from the ftp area (ftp://ftp.gnu.org/gnu/coreutils/) was an xz version and there seemed to be no support for that format on this machine. The latest gz was 8.13 from Sep 2011, so also downloaded version 8.13, and proceeded to install this. This problem was formerly included in bug#13912, but has now been split off from other topics covered there. 2 An error reported by make check. Tried `make check'. Ran to completion, recording one failure FAIL: install/install-C There was also a log in tests/test-suite.log, but it seemed to be removed later by make clean. The `make installcheck' has not been done. If it is of help to you, then this can be done, or partially done, to identify the exact failure. 3 Test failure reported in README There is a test failure in 'make check' reported in README concerning Mac OS X 10.5.1 (Darwin 9.1). This concerns ACL support, and suggests using --disable-acl. This machine has Mac OS X 10.5.8 (Darwin 9.8.0). The 'make check' was performed without having done --disable-acl, but the "numerous failures" stated did not arise, although there was one error (see previous section). The tests were done as a normal user (not root), but having the privilege to use sudo (not used at this point). It is not clear whether or not the FAIL above was one of those with Darwin 9.1. The different effect for this Mac version might or might not be of relevance to Gnu developers! 4 Conclusion The config.log file is available (5.3MB), plus config.status (96kB). There is also a file from redirecting standard output during the run of configure (60kB). If extra information about the matters reported above would be of value please contact: extralevelinsoftw...@ntlworld.com Ellis N. Thomas/21-Mar-2013
bug#14020: tail: unrecognized file system type 0x24051905
Not sure if this is an already known issue but I was asked to report this error: tail: unrecognized file system type 0x24051905 for '/var/log/asterisk/messages'. please report this to bug-coreutils@gnu.org. reverting to polling This file that is being tail'ed locates on a UBIFS NAND partition. --Joe
bug#14023: dirname/basename unexpected results when run by xargs -I
Reproduce example;
$ echo "testdir/testfile" | xargs -I '{}' echo '{}', dir: $(echo
dirname '{}') = $(dirname '{}')
Expected output;
testdir/testfile, dir: dirname testdir/testfile = testdir
Actual output;
testdir/testfile, dir: dirname testdir/testfile = .
This behavior seems to be limited to the xargs -I replace-str usage
pattern, any other way I can think of running dirname works fine.
Basename has similarly wonky behavior, it prints the full string
instead of doing any stripping.
Not sure if there's a bug involved (or if it's on the findutils or
coreutils side). Could also just be something silly I'm overlooking.
I've tested this with findutils 4.4.2 and coreutils 8.5 & 8.13 with
identical results.
--
Juho-Pekka Kuitunen
bug#14023: dirname/basename unexpected results when run by xargs -I
Juho-Pekka Kuitunen wrote:
> Reproduce example;
> $ echo "testdir/testfile" | xargs -I '{}' echo '{}', dir: $(echo dirname
> '{}') = $(dirname '{}')
Thank you for the report and the very nice test case. It made
debugging this problem so very much simpler.
> Expected output;
> testdir/testfile, dir: dirname testdir/testfile = testdir
>
> Actual output;
> testdir/testfile, dir: dirname testdir/testfile = .
Ah... But you have missed a critical point! :-) The $(...) is
expanded by the current shell and not by the xargs. Use echo to see
what you are asking.
$ echo xargs -I '{}' echo '{}', dir: $(echo dirname '{}') = $(dirname '{}')
xargs -I {} echo {}, dir: dirname {} = .
> This behavior seems to be limited to the xargs -I replace-str usage
> pattern, any other way I can think of running dirname works fine.
The problem is the $(...) which is running the dirname during the
earlier shell command line parsing pass and passing the result off to
the xargs command.
> Basename has similarly wonky behavior, it prints the full string
> instead of doing any stripping.
Also using $(...)? :-)
> Not sure if there's a bug involved (or if it's on the findutils or
> coreutils side). Could also just be something silly I'm overlooking.
> I've tested this with findutils 4.4.2 and coreutils 8.5 & 8.13 with
> identical results.
So... Not a bug. Agreed? (I am having a good chuckle. I hope you
will too.) We will close the bug then.
Bob
bug#14023: dirname/basename unexpected results when run by xargs -I
On Fri, Mar 22, 2013 at 3:05 AM, Bob Proulx wrote:
> Juho-Pekka Kuitunen wrote:
>> Reproduce example;
>> $ echo "testdir/testfile" | xargs -I '{}' echo '{}', dir: $(echo dirname
>> '{}') = $(dirname '{}')
>
> Thank you for the report and the very nice test case. It made
> debugging this problem so very much simpler.
>
>> Expected output;
>> testdir/testfile, dir: dirname testdir/testfile = testdir
>>
>> Actual output;
>> testdir/testfile, dir: dirname testdir/testfile = .
>
> Ah... But you have missed a critical point! :-) The $(...) is
> expanded by the current shell and not by the xargs. Use echo to see
> what you are asking.
>
> $ echo xargs -I '{}' echo '{}', dir: $(echo dirname '{}') = $(dirname '{}')
> xargs -I {} echo {}, dir: dirname {} = .
>
>> This behavior seems to be limited to the xargs -I replace-str usage
>> pattern, any other way I can think of running dirname works fine.
>
> The problem is the $(...) which is running the dirname during the
> earlier shell command line parsing pass and passing the result off to
> the xargs command.
So if I understand correctly, subshell replacements gets executed
before xargs fills in the replacements? I tried to rule out this
wonkyness with the "$(echo '{}')" bit and it seemed to work in the
correct order. The echo should produce an empty string if the subshell
was evaluated too soon?
>
>> Basename has similarly wonky behavior, it prints the full string
>> instead of doing any stripping.
>
> Also using $(...)? :-)
>
>> Not sure if there's a bug involved (or if it's on the findutils or
>> coreutils side). Could also just be something silly I'm overlooking.
>> I've tested this with findutils 4.4.2 and coreutils 8.5 & 8.13 with
>> identical results.
>
> So... Not a bug. Agreed? (I am having a good chuckle. I hope you
> will too.) We will close the bug then.
>
Very much possibly not a bug but I'm not 100% convinced yet. I've been
chuckling at this all evening, love a good brain teaser even if it
turns out to be something I overlooked instead of a bug. :-)
> Bob
--
Juho-Pekka Kuitunen
bug#14023: dirname/basename unexpected results when run by xargs -I
On 03/21/2013 08:52 PM, Juho-Pekka Kuitunen wrote:
> On Fri, Mar 22, 2013 at 3:05 AM, Bob Proulx wrote:
>> Juho-Pekka Kuitunen wrote:
>>> Reproduce example;
>>> $ echo "testdir/testfile" | xargs -I '{}' echo '{}', dir: $(echo dirname
>>> '{}') = $(dirname '{}')
>> The problem is the $(...) which is running the dirname during the
>> earlier shell command line parsing pass and passing the result off to
>> the xargs command.
>
> So if I understand correctly, subshell replacements gets executed
> before xargs fills in the replacements? I tried to rule out this
> wonkyness with the "$(echo '{}')" bit and it seemed to work in the
> correct order. The echo should produce an empty string if the subshell
> was evaluated too soon?
If you want to see when the shell is evaluating $(), use 'set -vx':
$ set -vx
$ echo testdir/testfile | xargs -I '{}' echo '{}', dir: $(echo dirname
'{}') = $(dirname '{}')
echo testdir/testfile | xargs -I '{}' echo '{}', dir: $(echo dirname
'{}') = $(dirname '{}')
+ echo testdir/testfile
echo dirname '{}')
dirname '{}')
echo dirname '{}')
echo dirname '{}'
++ echo dirname '{}'
dirname '{}')
dirname '{}'
++ dirname '{}'
+ xargs -I '{}' echo '{},' dir: dirname '{}' = .
testdir/testfile, dir: dirname testdir/testfile = .
$ set -
set -
+ set -
What you seem to want to do is invoke a shell instance on each file
name; that would be done as follows:
$ echo testdir/testfile | xargs -I {} sh -c \
'echo "$1", dir: $(echo dirname "$1") = $(dirname "$1")' sh {}
testdir/testfile, dir: dirname testdir/testfile = testdir
Or again with shell tracing (note there are two levels of shells - the
shell that spawns xargs, and the shell that xargs spawns, so I'm posting
two different traces):
$ set -vx
$ echo testdir/testfile | xargs -I {} sh -c 'echo "$1", dir: $(echo
dirname "$1") = $(dirname "$1")' sh {}
echo testdir/testfile | xargs -I {} sh -c 'echo "$1", dir: $(echo
dirname "$1") = $(dirname "$1")' sh {}
+ xargs -I '{}' sh -c 'echo "$1", dir: $(echo dirname "$1") = $(dirname
"$1")' sh '{}'
+ echo testdir/testfile
testdir/testfile, dir: dirname testdir/testfile = testdir
$ set -
set -
+ set -
$ echo testdir/testfile | xargs -I {} sh -cvx 'echo "$1", dir: $(echo
dirname "$1") = $(dirname "$1")' sh {}
echo "$1", dir: $(echo dirname "$1") = $(dirname "$1")
echo dirname "$1")
echo dirname "$1"
++ echo dirname testdir/testfile
dirname "$1")
dirname "$1"
++ dirname testdir/testfile
+ echo testdir/testfile, dir: dirname testdir/testfile = testdir
testdir/testfile, dir: dirname testdir/testfile = testdir
By the way, your question is mostly related to shell, and a bit with
xargs, and practically nothing to do with dirname. Your confusion on
WHEN $() is expanded would apply no matter what executable you plug in
instead of dirname. But since neither sh nor xargs belongs to
coreutils, you might get better answers by asking on a general forum on
shell programming subtleties.
>
> Very much possibly not a bug but I'm not 100% convinced yet. I've been
> chuckling at this all evening, love a good brain teaser even if it
> turns out to be something I overlooked instead of a bug. :-)
Hopefully shell tracing has managed to convince you.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
