Re: PATCH: df -mP alignment fix and -c --total option added to df
Dennis Smit [EMAIL PROTECTED] wrote: I had a glance at the TODO list and saw that df -mP had an alignment bug so i fixed that. Also i saw that an --total option was requested so did that as well. Thanks for the patches. Fixing the -mP alignment problem is not so simple. With your patch, `df -P' output is then misaligned. $ ./df -P Filesystem 1024-blocks Used Available Capacity Mounted on /dev/hda6 4128320 3516756401828 90% / If you propose a new patch for that problem, please send it separately from any other changes. I hope i did it alright, if not please make me know so that i can improve my work. Also i would like to do some more work on df or possibly other things. ChangeLog: * src/df.c (print_header): fixt alignment for `df -mP'. (main): added support for -c --total. (show_grand_total): added function to show the grand total. (show_information): added function splitted this from show_dev so the grand_total can use the same entry displaying function. (convert_blocksize): added function that converts the blocksize for the grandtotal so that only the same blocksize amounts are added to each other. Is this function right ? (took from human_readable). (show_dev): splitted out the show_information part and added support for grand total option. Shouldn't the totals be represented internally as byte counts? Your patch converts intermediate results to output units, which would suffer unnecessary errors. Also, please don't make unnecessary changes like this: -disk = -; /* unknown */ +disk = -; /* unknown */ ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: du, wc --files-from roundup
Dennis Smit [EMAIL PROTECTED] wrote: previous week we were discussing the du, wc --files-from options which didn't lead to much result. However I've got the FSF license post on it's way so i would love to put some work in this. I'am still in favor for Pauls idea to have a --files-from=NAME and a --null option were --files-from reads newline terminated and --null added makes it read NULL terminated, however if for some reason --files-from=NAME that reads NULL terminated without the --null option is prefered it's naturally ok with me. And I'm still reluctant to allow --files-from without --null. It's too easy for people to forget that a single file with a name containing a newline can cause that not to work. Note that this option is *not* intended or even necessary for most cases where people would be saving a list of inputs to a file and reading or editing it. If you have such a list that is so long that you can't put the names on a single `du' command line, then (assuming no file name contains a newline) just pipe the list through e.g., cat YOUR_LIST | tr '\n' '\0' | du --null --files-from - There is also the question of what to name the option that selects NUL-terminated *output* lines. Suggestions welcome. Also, Jim did you have a look at my df -c --total patch ? is it alright and can it be included when i signed the FSF papers ? I've just replied. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: du, wc --files-from roundup
Jim Meyering [EMAIL PROTECTED] wrote: And I'm still reluctant to allow --files-from without --null. What about --files-from0, or some such, so that the difference between it and --files-from in other tools is apparent? paul ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
hard link to directories
Hi, the man page of the ln command (ln (coreutils) 5.0March 2003 LN(1)) says: -d, -F, --directory hard link directories (super-user only) I tried to do this: # mkdir a # ln -F a b ln: creating hard link `b' to `a': Operation not permitted I tried this in /dev/shm, on ext2 and on reiserfs3.6. It never was possible. Is this a theoretical feature or a real one? I tested it with SuSE8.2 (kernel 2.4.20) and SuSE9.0 (kernel 2.4.21). I'm really interested in this feature, because I've write a backup tool (see below) which is based on recognising the *contents* of files. Every content is only one time in the whole backup; making the files appear at the appropriate place is done via hard links. If I could link directories, I would be able to improve this by making only a hard link to a (sub-)directory if nothing has changed in it. Best regards, -- Heinz-Josef Claes [EMAIL PROTECTED] project: http://sourceforge.net/projects/storebackup - snapshot-like backup to another disk ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: du, wc --files-from roundup
[EMAIL PROTECTED] (Paul Jarc) wrote: What about --files-from0, or some such, so that the difference between it and --files-from in other tools is apparent? I like that. Thanks. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
RE: 'csplit' core dumps in 'make check'
Hello, again -- Once I commented out csplit from the list of TESTS in tests/misc/Makefile, the make check progressed further, only to encounter another error, this time in tests/rm/: out exp differ: char 26, line 1 1c1 rm: cannot remove `a/b': Permission denied --- rm: cannot remove `a/b': Operation not permitted FAIL: fail-2eperm I commented out rm from the list of SUBDIRS in tests/Makefile, and ran make check again, this time hitting a series of Memory fault (coredump) errors in /tac/. I've attached the output (tac.txt), produced with VERBOSE=yes. Continuing from that point, I only ran into one more failure, this time in /tail-2/, where the 'dd' command -- neither the default HP-UX /usr/bin/dd nor /opt/gnu/bin/dd, version 3.16 from GNU fileutils -- couldn't handle the large 4gb parameter. I don't know if this falls into one of those framework errors mentioned in the README, but I was running as root, so I don't think any kind of setuid/setgid change would have made any difference. No further make check failures after that point. See ya! -- Mark Conty Cargill, Inc. Corporate I/T Services No suffix list. make check-TESTS No suffix list. testing program: ../../src/tac tac (coreutils) 5.0 Written by Jay Lepreau and David MacKenzie. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. passed basic-0(F) passed basic-0(|) passed basic-0() passed basic-b(F) passed basic-b(|) passed basic-b() passed basic-c(F) passed basic-c(|) passed basic-c() passed basic-e(F) passed basic-e(|) passed basic-e() passed basic-f(F) passed basic-f(|) passed basic-f() passed basic-g(F) passed basic-g(|) passed basic-g() passed basic-h(F) passed basic-h(|) passed basic-h() passed basic-i(F) passed basic-i(|) passed basic-i() passed basic-j(F) passed basic-j(|) passed basic-j() passed basic-k(F) passed basic-k(|) passed basic-k() passed opt-b(F) passed opt-b(|) passed opt-b() passed opt-s(F) passed opt-s(|) passed opt-s() passed opt-sb(F) passed opt-sb(|) passed opt-sb() ./tac-tests[723]: 7422 Memory fault(coredump) Test opt-r(F) failed: ../../src/tac return code 139 differs from expected value 0 ./tac-tests[741]: 7426 Memory fault(coredump) Test opt-r(|) failed: ../../src/tac return code 139 differs from expected value 0 ./tac-tests[759]: 7429 Memory fault(coredump) Test opt-r() failed: ../../src/tac return code 139 differs from expected value 0 ./tac-tests[777]: 7432 Memory fault(coredump) Test opt-r2(F) failed: ../../src/tac return code 139 differs from expected value 0 ./tac-tests[795]: 7436 Memory fault(coredump) Test opt-r2(|) failed: ../../src/tac return code 139 differs from expected value 0 ./tac-tests[813]: 7442 Memory fault(coredump) Test opt-r2() failed: ../../src/tac return code 139 differs from expected value 0 ./tac-tests[831]: 7445 Memory fault(coredump) Test opt-br(F) failed: ../../src/tac return code 139 differs from expected value 0 ./tac-tests[849]: 7449 Memory fault(coredump) Test opt-br(|) failed: ../../src/tac return code 139 differs from expected value 0 ./tac-tests[867]: 7452 Memory fault(coredump) Test opt-br() failed: ../../src/tac return code 139 differs from expected value 0 ./tac-tests[885]: 7455 Memory fault(coredump) Test opt-br2(F) failed: ../../src/tac return code 139 differs from expected value 0 ./tac-tests[903]: 7459 Memory fault(coredump) Test opt-br2(|) failed: ../../src/tac return code 139 differs from expected value 0 ./tac-tests[921]: 7462 Memory fault(coredump) Test opt-br2() failed: ../../src/tac return code 139 differs from expected value 0 Failed 12 tests. FAIL: tac-tests == 1 of 1 tests failed Please report to [EMAIL PROTECTED] == *** Error exit code 1 Stop. *** Error exit code 1 Stop. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
RE: 'csplit' core dumps in 'make check'
Continuing from that point, I only ran into one more failure, this time in /tail-2/, where the 'dd' command -- neither the default HP-UX /usr/bin/dd nor /opt/gnu/bin/dd, version 3.16 from GNU fileutils -- couldn't handle the large 4gb parameter. I also ran make check once more, this time using the dd binary built in /coreutils-5.0/, but that one complained about the over-large parameter, too: Making check in tail-2 No suffix list. make check-TESTS No suffix list. /src/gnu/coreutils-5.0/src/dd: advancing past 4294967288 bytes in output file `big': Invalid argument ./big-4gb: failure in testing framework FAIL: big-4gb See ya... -- Mark ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
