Subject: Re: less-wide df(1) output
To: NetBSD Miscellaneous Technical Discussion List <tech-misc@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-misc
Date: 10/06/2002 14:01:34
[ On , October 6, 2002 at 18:34:13 (+0200), Klaus Klein wrote: ]
> Subject: Re: less-wide df(1) output
>
> Greg A. Woods writes:
> 
> > [ On , October 6, 2002 at 14:03:50 (+0200), Johan Danielsson wrote: ]
> > 
> > > woods@weird.com (Greg A. Woods) writes:
> > > 
> > > > secondly only a single space is allowed between fields in
> > > > '-P' output.
> > > 
> > > How do you deduce that?
> > 
> > Read the printf format specification string given in the
> > standard, as I quoted from it in my post.
> 
> Your statement is interesting insofar as you've ignored a paragraph
> which Johan quoted from your original message citing the standard,
> which said:
> 
> >  The implementation may adjust the spacing of the header line and
> >  the individual data lines so that the information is presented in
> >  orderly columns.

Yes, but the point should be to keep the implementation using the
simplest direct interpretation of standard.

Such column alignment is only and option in the specification and though
with the above qualification it won't make the implemenation
non-conformant, it does strictly cause unnecessary differences with the
strict interpretation of the specification, and it will cause
unnecessary problems with other POSIX tools that only work with one
field separator character and thus nullifies one of the main reasons for
wanting "portable" output -- which is of course to make such output
easily parsable with standards based tools (well, cut(1) at least,
though naive scripts specifying the field separator explicitly for other
tools will also run into problems).

After all, how many users will type "df -P", esp. on *BSD where the
default output is almost identical to the column-aligned portable form
anyway?  In my experience "df -P" will only be used from other programs.

I would expect most people will be able to figure out the meaning of the
header line captions in the proposed default output, *BSD user
especially so since the order and definition of the columns is identical
in both formats.

I think having nicely lined up columns in the "df -P" output is only
really helpful for end users when the default output is in a completely
different form, such as that produced on SunOS-5 and other SysVr4
derrivatives (though of course in that case it would be at the expense
of programs reading it as input).  Of course on SunOS-5 "df -k" gives
the *BSD-style output (though with very naive column alignment that ends
up looking rather ugly on any larger-capacity system) and so even there
it's probably more desirable for "df -P" to use single-character field
separators too.

What might be more interesting for NetBSD 'df' than column-aligned '-P'
output would be creating output compatible with SysVr4 '-g' style, since
it provides more of the really useful information that's otherwise only
available from 'dumpfs', which of course is unavailable to mere mortals:

# df -g
/                  (/dev/dsk/c0t2d0s0 ):         8192 block size          1024 frag size  
16132282 total blocks   13185748 free blocks 13024426 available         992000 total files
  935788 free files     35651584 filesys id  
     ufs fstype       0x00000004 flag             255 filename length

/proc              (/proc             ):          512 block size           512 frag size  
       0 total blocks          0 free blocks        0 available           7884 total files
    7850 free files     59768832 filesys id  /proc
    proc fstype         00000000 flag              64 filename length

/etc/mnttab        (mnttab            ):          512 block size           512 frag size  
       0 total blocks          0 free blocks        0 available              1 total files
       0 free files     60555264 filesys id  /mnttab
   mntfs fstype         00000000 flag              64 filename length

/dev/fd            (fd                ):         1024 block size          1024 frag size  
       0 total blocks          0 free blocks        0 available            127 total files
       0 free files     60817408 filesys id  /dev/fd
      fd fstype         00000000 flag              10 filename length

/var               (/dev/dsk/c0t2d0s1 ):         8192 block size          1024 frag size  
 3970974 total blocks    3256996 free blocks  3137868 available         495616 total files
  490430 free files     35651585 filesys id  
     ufs fstype       0x00000004 flag             255 filename length

/var/run           (swap              ):         8192 block size          8192 frag size  
 2849152 total blocks    2849088 free blocks  2849088 available          48700 total files
   48690 free files            1 filesys id  /var/run
   tmpfs fstype       0x00000004 flag             255 filename length

/local             (/dev/dsk/c0t2d0s6 ):         8192 block size          1024 frag size  
24254744 total blocks   24179856 free blocks 23937310 available        1491200 total files
 1490240 free files     35651590 filesys id  
     ufs fstype       0x00000004 flag             255 filename length

/tmp               (/dev/dsk/c0t2d0s5 ):         8192 block size          1024 frag size  
 1924734 total blocks    1924678 free blocks  1809194 available         489472 total files
  489458 free files     35651589 filesys id  
     ufs fstype       0x00000004 flag             255 filename length

/export/home       (/dev/dsk/c0t2d0s7 ):         8192 block size          1024 frag size  
28489782 total blocks   27393338 free blocks 27108442 available        1747200 total files
 1738344 free files     35651591 filesys id  
     ufs fstype       0x00000004 flag             255 filename length



-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>