William Brendling <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
