Re: chroot manpage not in section 8
Jan Engelhardt [EMAIL PROTECTED] wrote: I noticed that my coreutils's chroot manpage is not in section 8, though the chroot operation is generally only available to the superuser (at least on Linux). coreutils version 6.11. The problem (which may not be one) is also present in the latest git snapshot. Thanks for the info. Is having it in section 1 causing some specific problem? If not, I'd just as soon continue to install all coreutils man pages into section 1. This is sort of like the /sbin, /bin, /usr/bin question of where to install the tools themselves. Distributions do a fine job of adapting. Note that Solaris' chroot man page is in the 1m section, perhaps because there, a non-root process may have the PRIV_PROC_CHROOT privilege. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Threaded versions of cp, mv, ls for high latency / parallel filesystems?
On Saturday 08 November 2008 20:05:25 Jim Meyering wrote: Andrew McGill [EMAIL PROTECTED] wrote: Greetings coreutils folks, There are a number of interesting filesystems (glusterfs, lustre? ... NFS) which could benefit from userspace utilities doing certain operatings in parallel. (I have a very slow glusterfs installation that makes me think that some things can be done better.) For example, copying a number of files is currently done in series ... cp a b c d e f g h dest/ but, on certain filesystems, it would be roughly twice as efficient if implemented in two parallel threads, something like: cp a c e g dest/ cp b d f h dest/ since the source and destination files can be stored on multiple physical volumes. How about parallelizing it via xargs, e.g., $ echo a b c d e f g h | xargs -t -n4 --no-run-if-empty \ --max-procs=2 -- cp --target-directory=dest cp --target-directory=dest a b c d cp --target-directory=dest e f g h Obviously the above is tailored (-L4) to your 8-input example. In practice, you'd use a larger number, unless latency is so high as to dwarf the cost of extra fork/exec syscalls, in which case even -L1 might make sense. I did the command above with md5sum as the command, and got missing lines in the output. I optimistically hoped that would not happen! mv and ln also accept the --target-directory=dest option. Simlarly, ls -l . will readdir(), and then stat() each file in the directory. On a filesystem with high latency, it would be faster to issue the stat() calls asynchronously, and in parallel, and then collect the results for If you can demonstrate a large performance gain on systems that many people use, then maybe... There is more than a little value in keeping programs like those in the coreutils package relatively simple, but if the cost(maintenance+portability burden)/benefit ratio is low enough, then anything is possible. For example, a well-encapsulated, optionally-threaded stat_all_dir_entries API might be useful in some situations. So a relatively small change for parallel stat() in ls could fly. If getting any eventual patch into upstream coreutils is important to you, be sure there is some consensus on this list before doing a lot of work on it. Any ideas on how to do a parallel cp / mv in a way that is not Considered Harmful? Maybe prefetch_files(max_bytes,file1,...,NULL) ... aargh. display. (This could improve performance for NFS, in proportion to the latency and the number of threads.) Question: Is there already a set of improved utilities that implement this kind of technique? Not that I know of. If not, would this kind of performance enhancements be considered useful? It's impossible to say without knowing more. On the (de?)merits of xargs for parallel processing: What would you expect this to do --: find -type f -print0 | xargs -0 -n 8 --max-procs=16 md5sum ~/md5sums sort -k2 md5sums md5sums.sorted Compared to this? find -type f -print0 | xargs -0 md5sum ~/md5sums sort -k2 md5sums md5sums.sorted I was a little surprised that on my system running in parallel (the first version) loses around 1 line of output per thousand (md5sum of 22Gb in mostly small files). Is there a correct way to do md5sums in parallel without having a shared output buffer which eats output (I presume) -- or is losing output when haphazardly combining output streams actually strange and unusual? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
configure syntax issue
While patching autoconf to output fewer blank lines, I noticed this suspicious construct. One of my potential autoconf changes is making AC_DEFINE no longer start with a blank line. But that means that coreutils' use of a variable assignment on the same line as the AC_DEFINE results in the assignment being temporary to the AC_DEFINE command, rather than persistent to subsequent commands. OK to apply? Also, when you removed coreutils/ChangeLog from git, you did not also remove coreutils/m4/ChangeLog. This is a bit confusing; are you planning on renaming and/or merging m4/ChangeLog into the main generated top-level ChangeLog? From: Eric Blake [EMAIL PROTECTED] Date: Tue, 11 Nov 2008 10:44:59 -0700 Subject: [PATCH] jm-macros.m4: avoid syntax issue with newer autoconf * jm-macros.m4 (coreutils_MACROS): Make LIB_CAP assignment persistent. Signed-off-by: Eric Blake [EMAIL PROTECTED] --- m4/jm-macros.m4 |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4 index a691d95..8fa1740 100644 --- a/m4/jm-macros.m4 +++ b/m4/jm-macros.m4 @@ -88,8 +88,9 @@ AC_DEFUN([coreutils_MACROS], AC_MSG_WARN([libcap support disabled by user]), [AC_CHECK_LIB([cap], [cap_get_file], [AC_CHECK_HEADER([sys/capability.h], -[LIB_CAP=-lcap AC_DEFINE([HAVE_CAP], 1, [libcap usability])], -[AC_MSG_WARN([header sys/capability.h was not found, support for libcap will not be built])] + [LIB_CAP=-lcap +AC_DEFINE([HAVE_CAP], 1, [libcap usability])], + [AC_MSG_WARN([header sys/capability.h was not found, support for libcap will not be built])] )], [AC_MSG_WARN([libcap library was not found or not usable, support for libcap will not be built])]) ]) -- 1.6.0.2 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
glibc's snprintf bug causes printf(1) failure with MALLOC_PERTURB_ != 0
Using printf from GNU coreutils newer than 6.9, I get this
on rawhide (glibc-2.8.90-16) which looks wrong, but isn't serious:
(it shouldn't allocate a 30MB buffer just to fill it with '0's and
print it)
$ (ulimit -v 2; env MALLOC_PERTURB_=1 printf '%.3000f' 0)
printf: write error
But, on Debian unstable (libc6 2.7-16) there's a bigger problem:
$ (ulimit -v 2; env MALLOC_PERTURB_=1 printf '%.3000f' 0)
zsh: segmentation fault
$ dmesg|tail -1
[75236.189009] printf[26494]: segfault at 0 ip 7f9e90598520 sp \
7fff98a87c28 error 6 in libc-2.7.so[7f9e9051c000+14a000]
The latter failure is due to a glibc snprintf bug discussed in:
http://bugs.debian.org/481543
http://bugzilla.redhat.com/470831 (RHEL5)
If you're into development and can deal with occasional
tool/infrastructure misbehavior, I strongly recommend that you
set the MALLOC_PERTURB_ envvar -- if you do, use a value in 1..255.
I use the following:
# http://udrepper.livejournal.com/11429.html
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
It would be good for gnulib to detect the bug and to use
the replacement snprintf on losing systems.
=
For reference, here's a C-only reproducer based on what
I wrote in the bug reports:
cat EOF k.c
#include stdio.h
#include stdlib.h
int
main(int argc, char **argv)
{
char buf[200];
char *fmt = argv[1];
if (argc 2)
abort ();
int n = snprintf (buf, sizeof buf, fmt, 1);
return 0*n;
}
EOF
I chose to eliminate the shared-libraries:
gcc -static -W -Wall k.c
Then run it like this:
env -i -- zsh -f -c \
'ulimit -v 5000; MALLOC_PERTURB_=9 ./a.out %$[5*2**20]d' || dmesg|tail -1
This example also demonstrates a problem with glibc
(whether it's a standards violation or merely a QoI issue is debatable)
IMHO, such a use of snprintf should not fail with ENOMEM, given
any but the most pathological floating point input arguments.
And with a format directives like s d i u o, etc., it should *never* fail.
Of course, if you want to use %$[5*2**20]s on the command
line, you'll have to change the `1' argument above to a string, e.g., `1'.
FYI, the libc in freebsd 6.1 and newer has no problem with the above
snprintf usage. And coreutils' printf command prints the 30 million 0's
without allocating an inordinate amount of storage.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] cp/mv: xattr support
Kamil Dudka [EMAIL PROTECTED] wrote: Hello Jim, after your agreement last week I am sending the patch for cp/mv xattr support. Any feedback is wellcome... Please modernize xattr.m4. E.g., use AS_HELP_STRING, fix the underquoting errors, a few of which are noted below. There is more than a little duplication in the set-up for the two added tests. Please consider combining them into a single file. In the tests, use grep -F, not fgrep. Please use char const *, not const char *, and with other types. Change this both in the commit log 1-line summary and in NEWS: s/xattr support/add xattr support/ In the commit log, attribute Andreas. Also, give a URL for his unmodified patch, if you can. @@ -7372,6 +7372,9 @@ Preserve in the destination files any links between corresponding source files. @c Give examples illustrating how hard links are preserved. @c Also, show how soft links map to hard links with -L and -H. [EMAIL PROTECTED] xattr +Preserve extended (xattr) attributes if coreutils are compiled with xattr s/are/is/ +support. ... +AC_DEFUN([gl_FUNC_XATTR], +[ ... +AC_CHECK_HEADERS(attr/error_context.h attr/libattr.h) AC_CHECK_HEADERS([attr/error_context.h attr/libattr.h]) +if test $ac_cv_header_attr_libattr_h = yes \ +test $ac_cv_header_attr_error_context_h = yes; then Drop the unnecessary double quotes above: if test $ac_cv_header_attr_libattr_h = yes \ test $ac_cv_header_attr_error_context_h = yes; then + use_xattr=1 +else + use_xattr=0 +fi +AC_DEFINE_UNQUOTED(USE_XATTR, $use_xattr, Fix quoting: AC_DEFINE_UNQUOTED([USE_XATTR], [$use_xattr], etc. (likewise below) +[Define if you want extended attribute support.]) +xattr_saved_LIBS=$LIBS +AC_SEARCH_LIBS(attr_copy_file, attr, +[test $ac_cv_search_attr_copy_file = none required || LIB_XATTR=$ac_cv_search_attr_copy_file]) +AC_SUBST(LIB_XATTR) +AC_CHECK_FUNCS(attr_copy_file) +LIBS=$xattr_saved_LIBS + fi +]) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] cp/mv: xattr support
Kamil Dudka wrote: Hello Jim, after your agreement last week I am sending the patch for cp/mv xattr support. Any feedback is wellcome... looks good. Is the \n required in this hunk as this suggests otherwise: cp --help | grep additional | wc -c - additional attributes: context, links, all\n\ + additional attributes: context, links, xattr,\n\ + all\n\ cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Bug eepc think virus
Hey there, I have some folders on my eeepc, which I cannot modify (wanted to delete them) Think it is a Virus. am not able to run the usual Llinux Desktop. Instead there is a black screen with the Taskbar underneath. Not able to shut down the eeepc. Not able to click the SOS Button or the EEPC Tips Here the Console Window I ran to modify. I am quiet new to this whole Eeepc and Linux stuff. Maybe it is not serious and I am just not able to do the RIGHT things. Smile to you Marianne chmod: missing operand Try `chmod --help' for more information. /.rw/_497dadb6-47d6-4a30-8c0c-a0360140c548_ chmod --help Usage: chmod [OPTION]... MODE[,MODE]... FILE... or: chmod [OPTION]... OCTAL-MODE FILE... or: chmod [OPTION]... --reference=RFILE FILE... Change the mode of each FILE to MODE. -c, --changes like verbose but report only when a change is made --no-preserve-root do not treat `/' specially (the default) --preserve-root fail to operate recursively on `/' -f, --silent, --quiet suppress most error messages -v, --verbose output a diagnostic for every file processed --reference=RFILE use RFILE's mode instead of MODE values -R, --recursive change files and directories recursively --help display this help and exit --version output version information and exit Each MODE is of the form `[ugoa]*([-+=]([rwxXst]*|[ugo]))+'. Report bugs to bug-coreutils@gnu.org. /.rw/_497dadb6-47d6-4a30-8c0c-a0360140c548_ /.rw/_497dadb6-47d6-4a30-8c0c-a0360140c548_ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: configure syntax issue
Eric Blake [EMAIL PROTECTED] wrote: While patching autoconf to output fewer blank lines, I noticed this suspicious construct. One of my potential autoconf changes is making AC_DEFINE no longer start with a blank line. But that means that coreutils' use of a variable assignment on the same line as the AC_DEFINE results in the assignment being temporary to the AC_DEFINE command, rather than persistent to subsequent commands. OK to apply? Sure. That's obviously the right change. Also, when you removed coreutils/ChangeLog from git, you did not also remove coreutils/m4/ChangeLog. This is a bit confusing; are you planning on renaming and/or merging m4/ChangeLog into the main generated top-level ChangeLog? I've been annoyed by that, too. And the other */ChangeLog files. I'm thinking of renaming each of them to */ChangeLog.2007. A nicer approach would be to move (and adjust each file name to have the appropriate dir prefix) all of the entries from these files: build-aux/ChangeLog doc/ChangeLog lib/ChangeLog m4/ChangeLog po/ChangeLog into these top-level ones: ChangeLog-2005 ChangeLog-2006 ChangeLog-2007 ChangeLog-2008 Anyone know of a good ChangeLog-merging/sorting tool? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
chroot manpage not in section 8
Hi, I noticed that my coreutils's chroot manpage is not in section 8, though the chroot operation is generally only available to the superuser (at least on Linux). coreutils version 6.11. The problem (which may not be one) is also present in the latest git snapshot. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dircolors utility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Anna Barnes on 11/11/2008 5:02 AM: Running dircolors on Fedora Core 6 Linux Dell server. I have placed the following in my .bash_profile. eval 'dircolors $HOME/.dir_colors' That should be: eval `dircolors $HOME/.dir_colors` Note the back-ticks, not single quotes. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -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 iEYEARECAAYFAkkZgNAACgkQ84KuGfSFAYDU1ACgujWgFyVForgnMJlLE2S2IHE+ g8oAn0s/5NOFZLA+PuG6nnuUywyBK5Zq =Ltlk -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chroot manpage not in section 8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 11/11/2008 6:25 AM: Note that Solaris' chroot man page is in the 1m section, perhaps because there, a non-root process may have the PRIV_PROC_CHROOT privilege. Cygwin can also perform chroot(1) as a non-privileged user (although cygwin's chroot is more of an emulation than a security feature, since the user can access paths outside the chroot by using native Windows calls). As long as the default 'make install' doesn't put chroot in /sbin, then I'm in favor of keeping chroot.1 rather than changing to chroot.8. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -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 iEYEARECAAYFAkkZih4ACgkQ84KuGfSFAYDonQCgmtC4gsq1gJONhCepoKaSmyyE MmoAoNMRl1hCrSCX9r9TWSgDEER5jJ6O =6jU9 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
dircolors utility
Running dircolors on Fedora Core 6 Linux Dell server. I have placed the following in my .bash_profile. eval 'dircolors $HOME/.dir_colors' But how do I suppress the output of dircolors when I login so that I don't get. LS_COLORS='no=00:fi=00:di=01;36:ln=01;45:pi=40;33:so=01;35:bd=40;33;01:c d=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;33:*.cmd=01;32:*.exe=01;3 2:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31 :*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:* .Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio =01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png =01;35:*.tif=01;35:'; export LS_COLORS kindest regards Anna -- Anna Barnes, PhD Research Associate (+441223 764678) Brain Mapping Unit (Sir William Hardy Bldg.) Dept. of Psychiatry. c/o Experimental Psychology University of Cambridge. Downing Site, Downing St. Cambridge, CB2 3EB ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: glibc's snprintf bug causes printf(1) failure with MALLOC_PERTURB_ != 0
Jim Meyering wrote: It would be good for gnulib to detect the bug and to use the replacement snprintf on losing systems. Does the checking whether printf survives out-of-memory conditions test from gnulib (part of any of the *print-posix modules) print yes or no on the two machines you used? I chose to eliminate the shared-libraries: gcc -static -W -Wall k.c Is it necessary? Won't it crash also with dynamic linking? Then run it like this: env -i -- zsh -f -c \ 'ulimit -v 5000; MALLOC_PERTURB_=9 ./a.out %$[5*2**20]d' || dmesg|tail -1 Is the MALLOC_PERTURB_ essential for the failure or not? FYI, the libc in freebsd 6.1 and newer has no problem with the above snprintf usage. But it fails the gl_PRINTF_ENOMEM check that is already in m4/printf.m4. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug eepc think virus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: Hey there, I have some folders on my eeepc, which I cannot modify (wanted to delete them) Think it is a Virus. am not able to run the usual Llinux Desktop. Instead there is a black screen with the Taskbar underneath. Not able to shut down the eeepc. Not able to click the SOS Button or the EEPC Tips Here the Console Window I ran to modify. I am quiet new to this whole Eeepc and Linux stuff. Maybe it is not serious and I am just not able to do the RIGHT things. Smile to you Marianne Sounds like you should seek support from the EEEPC folks. That's not this group. But rest assured, the odds of it being a virus are quite low. chmod: missing operand Try `chmod --help' for more information. /.rw/_497dadb6-47d6-4a30-8c0c-a0360140c548_ chmod --help Usage: chmod [OPTION]... MODE[,MODE]... FILE... or: chmod [OPTION]... OCTAL-MODE FILE... or: chmod [OPTION]... --reference=RFILE FILE... snip Report bugs to bug-coreutils@gnu.org. /.rw/_497dadb6-47d6-4a30-8c0c-a0360140c548_ /.rw/_497dadb6-47d6-4a30-8c0c-a0360140c548_ This _is_ the group for reporting bugs on chmod. However, nothing you've shown so far indicates a problem with the chmod command-line program. It's not even clear what you were trying to do with chmod, so we can't know how to help you to do it. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkaTV0ACgkQ7M8hyUobTrFBoACggufzpo0wRsVFXfpPGmz2joTh 5ewAn35hHt/oiVBrZWgkLlKUK+iOmQL4 =v3cM -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
