Re: patching dd
Olivier Delhomme <[EMAIL PROTECTED]> wrote:
>
[25 lines of unnecessary context removed -- please trim context of
quoted messages]
> Thank you for replying so quickly,
> sorry for that mistake, i'm so confused. Here is the patch
> against today's cvs sources :
Thank you for the patch.
Have you read the GNU Coding Standards document?
Run `info standards' on a Linux system. There are
some minor syntactic problems below. Most would be eliminated
if you used GNU indent output as a model. If you use emacs,
using cc-mode helps for indentation.
This change is large enough that you'll have to send
a copyright assignment to the FSF. Here are the instructions:
It's a two-step process. First, you send some info to the FSF, then
we mail you the actual paperwork to sign. Assignments have to be done
on physical paper to satisfy the requirements of copyright law. When you
fill out the form, the answer to the "employer" question depends on
whether you intend to use any of the old code.
Please email the following information to [EMAIL PROTECTED], and we
will send you the assignment form for your past and future changes.
Please use your full legal name (in ASCII characters) as the subject
line of the message.
--
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES
[What is the name of the program or package you're contributing to?]
[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]
[Do you have an employer who might have a basis to claim to own
your changes? Do you attend a school which might make such a claim?]
[For the copyright registration, what country are you a citizen of?]
[What year were you born?]
[Please write your email address here.]
[Please write your postal address here.]
[Which files have you changed so far, and which new files have you written
so far?]
Following are a lot of comments.
I've included most of those suggested changes in an alternative patch, below.
Note that I would like `display=human' to work like --human
on other tools (without requiring that dbs=N be specified),
so I added a little code. This makes it so dbs=N specified
before `display=human' is *ignored*. But that is at least consistent
with du: The -B1 is ignored here:
$ du -B1 -h -s dd.c
40K dd.c
but honored here:
$ du -h -B1 -s dd.c
40960 dd.c
Jim
> --- coreutils/src/dd.c2003-11-05 23:11:31.0 +0100
> +++ coreutils-m/src/dd.c 2003-11-08 21:26:53.0 +0100
> @@ -35,6 +35,7 @@
> #include "quote.h"
> #include "safe-read.h"
> #include "xstrtol.h"
Our convention is to alphabetize these #include lines.
...
> -print_stats (void)
> +print_human_stats(void)
There should be a space before the `('.
> {
> - char buf[2][INT_BUFSIZE_BOUND (uintmax_t)];
> + char display_buf[5][MAX (LONGEST_HUMAN_READABLE + 1, INT_BUFSIZE_BOUND
> (uintmax_t))];
No line should be longer than 80 bytes.
> +
>fprintf (stderr, _("%s+%s records in\n"),
Isn't this printing the number of *bytes*, now,
rather than records?
> -umaxtostr (r_full, buf[0]), umaxtostr (r_partial, buf[1]));
> +human_readable (r_full, display_buf[0], human_output_opts, input_blocksize,
> display_block_size),
Likewise.
> +human_readable (r_partial, display_buf[1], human_output_opts,
> input_blocksize, display_block_size));
> +
>fprintf (stderr, _("%s+%s records out\n"),
> -umaxtostr (w_full, buf[0]), umaxtostr (w_partial, buf[1]));
> +human_readable (w_full, display_buf[2], human_output_opts,
> output_blocksize , display_block_size),
> +human_readable (w_partial, display_buf[3], human_output_opts,
> output_blocksize, display_block_size));
> +
>if (r_truncate > 0)
> {
>fprintf (stderr, "%s %s\n",
> -umaxtostr (r_truncate, buf[0]),
> -(r_truncate == 1
> - ? _("truncated record")
> +human_readable (r_truncate, display_buf[5], human_output_opts,
> output_blocksize, display_block_size),
Whoops! The above [5] should be [4].
> +(r_truncate == 1
> ? _("truncated record")
Yow. That's a very long line.
...
> +static void
> +print_stats (void)
> +{
> + char buf[2][INT_BUFSIZE_BOUND (uintmax_t)];
The above declaration can be moved `down' into the scope where it's used.
> +
> + if (STREQ (display,"human"))
always include a space after `,'.
> +{ /* human readable format */
> + print_human_stats();
> +}
> + else if (!STREQ (display,"quiet"))
Likewise.
> + { /* in case dd should not be quiet */ <<<
Personally, I require that there be no trailing blanks.
> + fprintf (stderr, _("%s+%s records in\n"),
> + umaxtostr (r_full, buf[0]), umaxtostr (r_partial, buf[1]));
>
Re: Question about an TODO item.
Dennis Smit <[EMAIL PROTECTED]> wrote: > I would like to implement the following todo item: > > du and wc: add an option to make them read NUL-delimited > file name arguments from a file. > > I there anything i should know i start, how would you prefer > the option to be called? You should file copyright assignment papers with the FSF, if you haven't already. Here are instructions: It's a two-step process. First, you send some info to the FSF, then we mail you the actual paperwork to sign. Assignments have to be done on physical paper to satisfy the requirements of copyright law. When you fill out the form, the answer to the "employer" question depends on whether you intend to use any of the old code. Please email the following information to [EMAIL PROTECTED], and we will send you the assignment form for your past and future changes. Please use your full legal name (in ASCII characters) as the subject line of the message. -- REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES [What is the name of the program or package you're contributing to?] [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.] [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?] [For the copyright registration, what country are you a citizen of?] [What year were you born?] [Please write your email address here.] [Please write your postal address here.] [Which files have you changed so far, and which new files have you written so far?] Maybe `--files-from', since GNU tar uses that, but those names aren't separated with NUL bytes. Other ideas? > I also saw that the todo lists from fileutils, sh-utils and text utils > aren't merged yet, would you like me to do this and check which are > already done ? Thanks, but that's something I should do. Some of those entries are way too cryptic and probably won't mean anything to most people. When I first wrote many of them, they were not meant to be read by others. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: rm -f and unexecutable directories
On Sat, 8 Nov 2003, Bob Proulx wrote: [rm and unexecutable directories] >>the other way is to chmod every file before doing anything with >>it. >But the directory containing the file would need the chmod, not the >file itself. Sorry - I meant to say chmod every directory before doing anything with it, and by 'doing anything' I meant either removing it or preparing to remove it. -- Ed Avis <[EMAIL PROTECTED]> ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: rm -f and unexecutable directories
On Sat, 8 Nov 2003, Bob Proulx wrote: % mkdir -p fred/jim % chmod a-x fred/jim % rm -rf fred rm: cannot chdir from `fred' to `jim': Permission denied >>> >>>But by the action of your chmod you have specifically requested that >>>you do not want those files removed! >> >>But by specifying the -f option I (thought I had) specifically >>requested that they _should_ be removed after all! > >Not quite. You just pre-answered the questions to be asked as yes. Yup. I expected that -f would 'force' removal, but in fact it doesn't. >Here is what the info page says. > >`-f' >`--force' > Ignore nonexistent files and never prompt the user. Ignore any > previous `--interactive' (`-i') option. I know that rm's behaviour is consistent with the info page and with POSIX. So I am not reporting a bug. Instead I make two observations: that the --force flag is perhaps misnamed, and that an additional option to _really_ force things might be useful. >Also, there really are multiple operations happening with the >directory find'ing, chmod'ing and rm'ing. These are not atomic >operations. True, but then neither is the normal action of rm -r. It's possible to have a race condition where you're removing files from a directory at the same time someone else is creating them, and so the rm -r fails. >Here is what I was originally thinking about. This one has been >debated previously and can't be changed. > > mkdir -p one/two/three > chmod -R a-w one > rm -rf one > rm: cannot remove directory `one/two/three': Permission denied > rm: cannot remove directory `one/two': Permission denied > rm: cannot remove directory `one': Directory not empty Hmm. Again this would be a candidate for a --really-force flag, if one were added. I know that the behaviour of -f cannot be changed. >Of course all of the directories are removed in this case in spite of >the inability to search the directory. That is, the following works. > > mkdir one > chmod a-x one > rmdir one > >So perhaps there is some room for change there. Perhaps rm should >attempt rmdir on the directory even though it can't look into it. Hmm maybe, but not as a change to rm's current behaviour since as you say that would break what people (and POSIX) expect. It would have to be part of some new option. But if you were going to add such an option, merely trying an rmdir() seems too weak to be worth bothering. >>Yes - you could get the same effect by first doing 'chmod -R' and >>then 'rm -rf', but by the same argument the -f flag to cp is >>redundant because it just emulates rm followed by cp. > >Actually, no, not for the non-writable file case. It just turns off >the question. According to cp(1): -f, --force if an existing destination file cannot be opened, remove it and try again This is analogous to what I had in mind for rm: try some additional operation (unlink, chmod, whatever) which will let the command succeed. In the case of cp, the -f flag does *not* simply stop a question being asked. It seems to do that, but also more importantly do an additional step (unlink) if necessary. For example: % touch fred jim % chmod a-w jim % cp fred jim cp: overwrite `jim', overriding mode 0444? y cp: cannot create regular file `jim': Permission denied % cp -f fred jim [succeeds] So the -f flag to cp is clearly not just a means to answer 'yes' to some question. For rm, as you say, it's different and -f is just equivalent to lots of 'y' (plus ignoring files that don't exist). But the example of cp shows that adding a flag to 'do some extra stuff to force the operation to happen' is not such a strange idea. >The -f option does not perform any 'chmod' operations. It just >suppresses the artificially created message. I say artificially >created because the rm command as part of trying to be helpful goes >out of its way to ask the user if they really want to remove the >file solely based upon the clue that it is not writable. I have >always thought that behavior gratuitous. It is trying to create a >different model of the filesystem than the one that actually exists. Agreed. But it's too late to change now. >>FWIW - what prompted me to suggest this feature was not that I had >>chmodded files to deliberately stop them being removed. It was >>just a slightly odd tarball (not generated on a Unix system, I >>expect) which created a directory lacking execute permission. >>Then I tried to use rm to clean up, and was surprised that even >>with the --force option it wasn't able to do the job. > >At least that is not something that happens every day! :-) Nonetheless there should be some program which is able to delete files even in cases like the above, and if not rm then what? -- Ed Avis <[EMAIL PROTECTED]> ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Re: Question about an TODO item.
Heya!, i will look into the papers!, have you already received the -c --total patch for df ? I will think about what kind of option i could use for that file name list option for du and wc. Also i have been looking in the vsclite test, however i will set up an new machine to run the test so i won't bork up my workstation installation! Also the requirement for an empty filesystem isn't there so it has to wait a few weeks, but i would love to look into this stuff, it's new for me but thus the more intresting. Kind regards, Dennis Smit ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Question about an TODO item.
Jim Meyering <[EMAIL PROTECTED]> writes: > Maybe `--files-from', since GNU tar uses that, but those names > aren't separated with NUL bytes. > > Other ideas? tar uses --files-from=NAME (-T NAME) to read files from NAME, and a separate option --null to say that the file names are NUL-terminated rather than newline-terminated. cpio also uses -0 to mean --null. So for consistency with these other tools I'd suggest two options, --files-from and --null, rather than combining them into a single option. I assume that the only reason these options need to be added to du and wc (as opposed to saying "just use xargs") is that these programs print totals and can reasonably be applied to tons of arguments. This should probably be mentioned in the documentation somewhere. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Question about an TODO item.
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: >> Maybe `--files-from', since GNU tar uses that, but those names >> aren't separated with NUL bytes. >> >> Other ideas? > > tar uses --files-from=NAME (-T NAME) to read files from NAME, and a > separate option --null to say that the file names are NUL-terminated > rather than newline-terminated. cpio also uses -0 to mean --null. So > for consistency with these other tools I'd suggest two options, > --files-from and --null, rather than combining them into a single > option. But then, what? Require that --null also be specified whenever --files-from is? Maybe, though it's not pretty. Or accept --files-from without --null and read newline-separated file names. I'd rather not do the latter, because I think many people would end up using that easier-to-use (but not robust) interface. > I assume that the only reason these options need to be added to du and > wc (as opposed to saying "just use xargs") is that these programs > print totals and can reasonably be applied to tons of arguments. Right. > This should probably be mentioned in the documentation somewhere. Yep :-) ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: patching dd
Le Sun, 09 Nov 2003 10:27:45 +0100, Jim Meyering disait : > Thank you for the patch. > > Have you read the GNU Coding Standards document? No, not yet, but this mistake will soon be patched :) > Run `info standards' on a Linux system. There are > some minor syntactic problems below. Most would be eliminated > if you used GNU indent output as a model. If you use emacs, > using cc-mode helps for indentation. A strange thing is that my `info' version does not understand any standards ... anyway I found this documentation on the gnu web site here : http://www.gnu.org/prep/standards_toc.html Now I 'only' have to learn a bit more ... I would like to thank you for the comments you made, showing me where I was wrong. I promise to make a special effort to code and review next patchs. By the Way, I sent a patch for `du', I saw there is some mistakes in it that you already told me ... and I was wondering which option sould be used to display null terminated file names in `du' : Dennis Smit proposed to add options to du and wc in order to read file names from a file in a zero separated way. The option proposed was -0 and --null but if the `du' program has to display results in the same way, which option should be used (to avoid confusing people) ? > This change is large enough that you'll have to send > a copyright assignment to the FSF. Here are the instructions: I didn't knew this ... well the first step is done. -- web site : http://olivier.delhomme.free.fr/ gpg public key : http://olivier.delhomme.free.fr/delhomme.gpg ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Failed tests in 'make check'
Title: Failed tests in 'make check' OS: Solaris 7 (Sun SPARC) The attached file contains the pertinent excerpt of what was reported by 'make check' run as root. --aslam Aslam Karachiwala Online Development, Insurance Thomson Media (Sheshunoff Information Services) One Alewife Center, Suite 460 Cambridge, MA 02140 USA Phone: 617-441-5918 Fax: 617-864-2396 Email: mailto:[EMAIL PROTECTED] Web: http://us.tfinsurance.com "This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution." ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: du, wc --files-from=NAME
I must admit that my preference goes to eggerts method because it also allows newline terminated filenames within the file which is human readable and editable. We'll use --files-from, -T for the option i assume ? and when agreed upon optionaly an --null flag. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
