Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Sep 2006 18:04:42 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        "Christian S.J. Peron" <csjp@freebsd.org>
Cc:        freebsd-standards@freebsd.org
Subject:   Re: [Fwd: Re: df -kP != df -Pk]
Message-ID:  <20060920172920.B59572@delplex.bde.org>
In-Reply-To: <45101C0E.4010202@FreeBSD.org>
References:  <45101C0E.4010202@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 19 Sep 2006, Christian S.J. Peron wrote:

> Anyone have any objections to me committing this patch?

% @@ -123,6 +123,7 @@
%  		case 'b':
%  				/* FALLTHROUGH */
%  		case 'P':
% +			Pflag++;

Why not just "if (kflag) break;" here?

%  			putenv("BLOCKSIZE=512");
%  			hflag = 0;
%  			break;
% @@ -171,6 +173,12 @@
%  	argc -= optind;
%  	argv += optind;
% 
% +	/*
% +	 * POSIX specifies that if both -P and -k options are used together a
% +	 * 1k blocksize should be used.
% +	 */
% +	if (Pflag != 0 && kflag != 0)
% +		putenv("BLOCKSIZE=1k");

Then this would not be needed (except for the comment).

POSIX actually requires BLOCKSIZE to be set to 1024, not to 1k, so that the
header says 1024 and not 1k.  df -k causes the wrong output now and the
above preserves this bug.

(BTW, I use BLOCKSIZE=1024 in the environment and recently noticed
that this exposes bugs in systat(1) -- 1024 is wider than 1k, so sloppy
formatting in systat causes line wrap with 1024 but not with 1k.  df(1)'s
formatting is not so sloppy, but line wrap still usually occurs for df -i
and can be reduced by using 1k instead of 1024.)

Another bug here is that 1k == 1000 != 1024.

FreeBSD has non-POSIX -b, -g, -H, -h and -m options.  These currently act
non-surprisingly -- the last one has precedence.  This is quite different
and less surprising than the POSIX behaviour for -kP.  The proposed patches
have different surprising interactions with this, e.g.:
- with the original patch, -Pk[bgm] reduces to -k, since (Pflag && kflag)
   causes BLOCKSIZE to be reset to 1k after -[bgm] sets it to something else.
- with the original patch, -Pk[Hh] resets BLOCKSIZE but doesn't cancel
   hflag, so -Pk[Hh] ends up with a mixture of -k and -[Hh].
- with my change, the last option wins unless it is -P and kflag is already
   set (since I don't cancel kflag, kflag still stops subsequent -P's from
   having an effect although -k is cancelled in all other ways by -[bgmHh].

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060920172920.B59572>