Re: Suggested enhancement to du command - show last modified date.

[Jim Meyering]

William Brendling <address@hidden> wrote:
> I use the "du" command to identify directories for potential
> archiving. Candidate directories are those that are taking a lot of
> space, and which are not currently being worked on. The "du" command
> conveniently identified the first. To find out the latter requires
> walking the directory tree, and performing a stat on each file (to
> obtain the last modified date). "du" already does most of this.
> Walking a large directory tree twice, once to collect the file sizes,
> and a second time to collect the last modified date can be time
> consuming. I therefore suggest that "du" should have an option to
> collect the latest last modified date for the files in a directory.

I like the idea.
It might be nice to have an option that makes it look
at atime rather than mtime.

> I have hacked together a version of "du" that does this, taking the
> date formatting code from the "date" utility. If my modified program
> is run as (for example) "du --last-modified", it produces output such
> as the following:
>
> 368   2004/03/12.19:18        ./config
> 1004  2005/06/02.13:53        ./m4
...
> I chose this default date format so that the "sort" utility will
> regard it as one field, and so that alphabetical sorting is the same
> as date sorting.

Doesn't the standard ISO-8601 date format accomplish that, too?

...
> If you think my suggestion worthwhile, I would be happy to contribute
> my modified code back to the GNU project, but I am very much a GNU
> newbie. I don't know how to generate patch files. Also I have not made

First, get a copy of the latest sources from CVS by following
the instructions here:

  http://savannah.gnu.org/cvs/?group=coreutils

That creates a `coreutils/' directory.
Apply your changes there, then run e.g.,

  cvs diff -u src/du.c > DIFF

and mail the contents of DIFF to the mailing list.

Of course, there's a little more to it than that.
Writing ChangeLog entries describing your changes is helpful.
Here are some guidelines:

  http://www.gnu.org/prep/standards/standards.html#Change-Logs

It's good to update the --help output and even better to update
the primary documentation in the file doc/coreutils.texi.

You might find useful info in the FAQ:

  http://www.gnu.org/software/coreutils/faq/coreutils-faq.html

> any attempt to update the man files or other documentation. Please let

Don't worry about updating the `man' pages.
They're generated automatically from the --help output.

> me know if you would like me to submit the code, and if so, how I
> should do so ?

Contributions are welcome, but when they are not small, they
must be accompanied by paperwork assigning copyright to the FSF.
You may also need to obtain a disclaimer from your employer.
If you're still interested, let me know and I'll send you the forms.