-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Thomas Schwinge on 11/24/2007 4:36 PM:
>> { echo *.hhm | xargs cat; } > scop70_1.72.hhm.tmp
>
> I was looking at these two command lines and wondered why you think that
> ``cat *.hhm'' would produce a longer command line than ``echo *.hhm''
> does.
>
> But I think I just found the answer why this might indeed work: `echo'
> usually (?) is a shell built-in function and thus doesn't have this
> limitation (?). Correct?
Yes indeed. Because echo is a builtin, the shell does not need to
fork/exec, therefore, the kernel exec argument length limit need not apply.
> (Save the discussion about the portability of using the null chararcter
> separator, of course.)
Actually, this whole discussion should think about that issue - my example
is probably no less reliable than the original failed attempt, but also no
more secure in dealing with shell metacharacters. You are correct that a
robust solution must think about these issues.
>
> find ./ -name \*.hhm -print0 | sort -z | xargs -0 cat > ...
Except that it recurses into subdirectories, while the command-line glob
does not. You would also need to use -prune or the non-portable -maxdepth
1 with find to limit results to the current directory.
Another issue in my (untested) solution - I really should have had three
commands, not two, with the first being 'rm -f scop70_1.72.hhm', so that
any pre-existing contents in that file are not duplicated. In that light,
my post should be read along the lines of 'you asked a FAQ, and here's
some guidelines to resolve it' rather than 'here's the solution to your
problem'.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHSLqt84KuGfSFAYARAiKrAJ4rKU2PG3eIw/490iMvJVNe8k0TIwCgliWy
dnl6NVyOgLQM5K1jp9JlEa4=
=+8bF
-----END PGP SIGNATURE-----
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
