db(1) show size of key and/or value (with patch)

Any thoughts on this db(1) -s addition:

$ db -S b -T w -s hash /var/db/services.db | head -5
37      (3)     gopher4070/tcp40nicname40 (23)
M-~pop3s       (7)     197     (4)
286     (4)     afs3-resserver407010/udp40icq40  
(29)
M^?87/tcp      (8)     43      (3)
38      (3)     gopher4070/udp40nicname40 (23)

Another example:

$ db -s btree /var/db/pkg/pkgdb.byfile.db | head -3
/usr/pkg//bin/ccmakedep (24)    xorg-imake-6.9.0nb1    
(20)
/usr/pkg//bin/cleanlinks        (25)    xorg-imake-6.9.0nb1 
   (20)
/usr/pkg//bin/gccmakedep        (25)    xorg-imake-6.9.0nb1 
   (20)

Is it okay that the size is one larger? For example:

$ db -w hash abc.db key value                        
Added key `key'
$ db -s hash abc.db
key     (4)     value   (6)

Would you prefer different output format?

Here is the patch:

Index: usr.bin/db/db.1
============================================================
=======
RCS file: /cvsroot/src/usr.bin/db/db.1,v
retrieving revision 1.17
diff -u -r1.17 db.1
--- usr.bin/db/db.1	20 Jun 2005 02:53:38 -0000	1.17
+++ usr.bin/db/db.1	30 Aug 2007 10:53:11 -0000
 -231,6
+231,9 
 Defaults to a single tab
 .Pq Sq et .
 .
+.It Fl s
+Display size of key and/or data in parentheses.
+.
 .It Fl S Ar visitem
 Specify items to
 .Xr strvis 3
Index: usr.bin/db/db.c
============================================================
=======
RCS file: /cvsroot/src/usr.bin/db/db.c,v
retrieving revision 1.15
diff -u -r1.15 db.c
--- usr.bin/db/db.c	3 Apr 2007 04:52:32 -0000	1.15
+++ usr.bin/db/db.c	30 Aug 2007 10:53:11 -0000
 -59,6
+59,7 
 	F_DELETE	= 1<<1,
 	F_SHOW_KEY	= 1<<2,
 	F_SHOW_VALUE	= 1<<3,
+	F_SHOW_SIZE	= 1<<4,
 	F_QUIET		= 1<<10,
 	F_IGNORECASE	= 1<<11,
 	F_ENDIAN_BIG	= 1<<12,
 -120,7
+121,7 
 
 				/* parse arguments */
 	while ( (ch = getopt(argc, argv,
-			     "CDdE:F:f:iKm:NO:qRS:T:U:VwX:")) != -1)
{
+			     "CDdE:F:f:iKm:NO:qRsS:T:U:VwX:")) != -1)
{
 		switch (ch) {
 
 		case 'C':
 -202,6
+203,10 
 				    optarg);
 			break;
 
+		case 's':
+			flags |= F_SHOW_SIZE;
+			break;
+
 		case 'T':
 			encflags = parse_encode_option(&optarg);
 			if (! encflags)
 -370,6
+375,10 
 			data = (char *)key->data;
 		}
 		printf("%.*s", len, data);
+		if (flags & F_SHOW_SIZE) {
+			printf("%s", outputsep);
+			printf("(%zd)", key->size);
+		}
 	}
 	if ((flags & F_SHOW_KEY) && (flags &
F_SHOW_VALUE))
 		printf("%s", outputsep);
 -382,6
+391,10 
 			data = (char *)val->data;
 		}
 		printf("%.*s", len, data);
+		if (flags & F_SHOW_SIZE) {
+			printf("%s", outputsep);
+			printf("(%zd)", val->size);
+		}
 	}
 	printf("n");
 }

  Jeremy C. Reed

On Thu, Aug 30, 2007 at 06:01:38AM -0500, Jeremy C. Reed
wrote:
  | Any thoughts on this db(1) -s addition:
  | 
  | $ db -S b -T w -s hash /var/db/services.db | head -5
  | 37      (3)     gopher4070/tcp40nicname40 (23)
  | M-~pop3s       (7)     197     (4)
  | 286     (4)     afs3-resserver407010/udp40icq40  
(29)
  | M^?87/tcp      (8)     43      (3)
  | 38      (3)     gopher4070/udp40nicname40 (23)

I'm curious; what did you need this for that a
post-processor
program (hi awk(1)  couldn't
do?


  | Another example:
  | 
  | $ db -s btree /var/db/pkg/pkgdb.byfile.db | head -3
  | /usr/pkg//bin/ccmakedep (24)    xorg-imake-6.9.0nb1    
(20)
  | /usr/pkg//bin/cleanlinks        (25)   
xorg-imake-6.9.0nb1     (20)
  | /usr/pkg//bin/gccmakedep        (25)   
xorg-imake-6.9.0nb1     (20)
  | 
  | Is it okay that the size is one larger? For example:
  | 
  | $ db -w hash abc.db key value                        
  | Added key `key'
  | $ db -s hash abc.db
  | key     (4)     value   (6)

The size is including the trailing NUL.
Does it return the correct length when using -N ?


  | Would you prefer different output format?

If we implemented this, I'd remove the surrounding
parenthesis
to make the number easy to parse.


cheers,
Luke.

On Fri, 31 Aug 2007, Luke Mewburn wrote:

> On Thu, Aug 30, 2007 at 06:01:38AM -0500, Jeremy C.
Reed wrote:
>   | Any thoughts on this db(1) -s addition:
>   | 
>   | $ db -S b -T w -s hash /var/db/services.db | head
-5
>   | 37      (3)     gopher4070/tcp40nicname40
(23)
>   | M-~pop3s       (7)     197     (4)
>   | 286     (4)    
afs3-resserver407010/udp40icq40   (29)
>   | M^?87/tcp      (8)     43      (3)
>   | 38      (3)     gopher4070/udp40nicname40
(23)
> 
> I'm curious; what did you need this for that a
post-processor
> program (hi awk(1)  couldn't
do?

I guess I could, but then I couldn't easily use the vis(3)
feature and 
would need to pipe through vis(1) at end.

$ db hash /home/reed/tmp/abc.db | awk '{ print $1,
length($1), $2, length($2); }'

key 3 value 5
key2 4  0

(My key2 was made with an "" empty value.)

Now here is pipe through vis:

 length($2); }' | vis -w                                    
               
$  db hash /home/reed/tmp/abc.db | 
   awk '{ print $1, length($1), $2, length($2); }' | vis -w
key40340value40512key24044040012glacier:/usr
/src/usr.bin/db$

Notice my prompt above and default tab delimiter became
literal "40".

It just seemed easier in db(1) versus doing more awk
scripting to get it 
right.

>   | Is it okay that the size is one larger? For
example:
>   | 
>   | $ db -w hash abc.db key value                      
 
>   | Added key `key'
>   | $ db -s hash abc.db
>   | key     (4)     value   (6)
> 
> The size is including the trailing NUL.
> Does it return the correct length when using -N ?

No.

So I did printf("%zd", key->size - 1);

>   | Would you prefer different output format?
> 
> If we implemented this, I'd remove the surrounding
parenthesis
> to make the number easy to parse.

Okay:

$ /usr/src/usr.bin/db/obj/db -S b -T w -s hash
/var/db/services.db | head -5
37      2       gopher4070/tcp40nicname40 22
M-~pop3s       6       197     3
286     3       afs3-resserver407010/udp40icq40   28
M^?87/tcp      7       43      2
38      2       gopher4070/udp40nicname40 22


Thanks for your feedback. (It is nice to receive feedback
from the 
AUTHOR  db(1) sure
is useful -- is your db(1) included with any other 
operating systems?

  Jeremy C. Reed

On Fri, Aug 31, 2007 at 08:35:50AM -0500, Jeremy C. Reed
wrote:
  | On Fri, 31 Aug 2007, Luke Mewburn wrote:
  | 
  | > On Thu, Aug 30, 2007 at 06:01:38AM -0500, Jeremy C.
Reed wrote:
  | >   | Any thoughts on this db(1) -s addition:
  | > 
  | > I'm curious; what did you need this for that a
post-processor
  | > program (hi awk(1)  couldn't
do?
  | 
  | It just seemed easier in db(1) versus doing more awk
scripting to get it 
  | right.

Fair enough.


  | >   | Is it okay that the size is one larger? For
example:
  | >   | 
  | >   | $ db -w hash abc.db key value                  
     
  | >   | Added key `key'
  | >   | $ db -s hash abc.db
  | >   | key     (4)     value   (6)
  | > 
  | > The size is including the trailing NUL.
  | > Does it return the correct length when using -N ?
  | 
  | No.
  | 
  | So I did printf("%zd", key->size - 1);

Does that work correctly when -N is in use?
You may want to look at the hackery that is the MINUSNUL()
macro.



  | 
  | >   | Would you prefer different output format?
  | > 
  | > If we implemented this, I'd remove the surrounding
parenthesis
  | > to make the number easy to parse.
  | 
  | Okay:
  | 
  | $ /usr/src/usr.bin/db/obj/db -S b -T w -s hash
/var/db/services.db | head -5
  | 37      2       gopher4070/tcp40nicname40 22
  | M-~pop3s       6       197     3
  | 286     3       afs3-resserver407010/udp40icq40  
28
  | M^?87/tcp      7       43      2
  | 38      2       gopher4070/udp40nicname40 22

On consideration, I wonder if it's worth putting the length
before the
string, rather than after?


  | 
  | 
  | Thanks for your feedback. (It is nice to receive
feedback from the 
  | AUTHOR  db(1) sure
is useful -- is your db(1) included with any other 
  | operating systems?

I don't think so.  Maybe FreeBSD picked it up?


cheers,
Luke.