bug#10281: [1003.1(2008)/Issue 7 0000527]: du and files found via multiple command line arguments

[Eric Blake]

[cc'ing the coreutils bug id]

On 12/16/2011 09:33 PM, Don Cragun wrote:
> On Dec 16, 2011, at 8:15 PM, Austin Group Bug Tracker wrote:
>> The following issue has been SUBMITTED. 
>> ====================================================================== 
>> http://austingroupbugs.net/view.php?id=527 
>  ... ... ...
>> In all likelihood, the intent of the standard was to codify traditional
>> behavior where the hash for duplicate files is reset each time du
>> starts processing the next command line argument, and GNU du was
>> wrong for trying to take the standard too literally.  However, it was
>> pointed out that the GNU behavior of remembering duplicates across
>> multiple command line arguments does have a use not possible in the
>> traditional implementation: if a user has multiple directories, all
>> of which share some hard links, then only the GNU semantics make it
>> possible to see how much disk space will be reclaimed by removing
>> the one directory, by invoking 'du -s' with the directory to be
>> removed as the last argument.  Therefore, I'm presenting two options
>> for solving the conflict in the standard, although my preference
>> would be for option 1 (the GNU implementation is willing to change
>> its behavior to comply with option 1 by adding an extension option
>> to provide its current behavior of remembering links across
>> multiple command line arguments, and all other implementations
>> already comply with option 1).
> 
> If we go with option 1, what option would the GNU implementation
> use to specify the current GNU behavior?  Should option 1 be
> extended to include the new option?

I assume that GNU would initially prefer to go with extensions only
through a long option, so as not to prematurely burn a short option on
an unpopular feature and so as not to risk collisions with short option
extensions chosen by other implementations.  One of the thoughts in the
initial bug report against GNU would be converting the existing 'du
--count-links' long option into taking an optional argument, as in:

du --count-links         => short-hand for du --count-links=always
du --count-links=always  => no elision of multiples
du --count-links=once    => current default GNU behavior, elide links
across args
du --count-links=per-arg => traditional behavior, elide links, but only
within each argument

Right now, GNU has 'du -l' as a synonym for 'du --count-links', but if
--count-links gains an optional qualifier, -l would NOT have an optional
qualifier, but would only match --count-links=always.  Obviously, POSIX
won't standardize a long option.  But if POSIX deems the
--count-links=once behavior useful enough to standardize a new short
option for it, even if GNU is the only implementation currently
implementing that behavior, we have no problem assigning that short
option as a synonym for the proposed --count-links=once behavior.  Would
'-o' conflict with any existing implementation, as a mnemonic for 'once
across all arguments'?  Or would some other short option letter be a
better mnemonic?

I'm not sure whether coreutils will immediately switch to having 'du'
without --count-links always default to the POSIX behavior, or whether,
in GNU fashion, the existence of $POSIXLY_CORRECT in the environment
will affect the choice of defaulting between the compliant vs. the GNU
behavior, but that's an implementation choice for GNU that should not
affect the decision on the resolution of the POSIX bug.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature