"Artifial issue": pshbak -c collects hostnames wrong-ish for some cases

[GoogleCodeExporter]

I stumbled across the following issue

echo -e 'n01:\nn2:' | dshbak -c

It get collected as 
n[01-2]
which then would get expanded to
n01,n02
by pdsh.

I'm really not much of a perl hacker, so I don't present any patch for it 
though. ;)

/Mattias

Original issue reported on code.google.com by don.fanucci on 24 Sep 2010 at 8:55

[GoogleCodeExporter]

Ok, I will try to look into this one.

Original comment by mark.gro...@gmail.com on 24 Sep 2010 at 6:04

• Changed state: Accepted

[GoogleCodeExporter]

Mattias,

Thanks for the bug report. I've attached a patch where I undid the exceptionally
obtuse comp() code in dshbak into a more clear loop (with comments!) and added
a check that any zero-padding matches before collapsing numeric ranges.

This patch is quite experimental, since I rewrote the code, but I'd appreciate
it if you could give it a test and let me know of any new bugs that are 
introduced.

Thanks,
mark

Original comment by mark.gro...@gmail.com on 28 Sep 2010 at 3:47

Attachments:

• dshbak.patch

[GoogleCodeExporter]

Hi Mark!

I threw together a shell script which runs a few different inputs through 
dshbak (or any other command) and compares the output with a predefined 
expected output.

It seems that there still is a set of (artificially made up) inputs which 
renders collected host lists which if fed to pdsh would result in a new set of 
hosts (as compared to the original input). Se examples below (and in attached 
file).

To test the attached shell script, edit/alter the array of "COLLECT_COMMANDS".
I used the pshbak-command as a comparison. It is a python "rewrite" of dshbak 
and is part of Kent Engstroms python-hostlist 
(http://www.nsc.liu.se/~kent/python-hostlist/).
Hence, pshbak is not a stand alone script/program, but depends on the 
hostlist-library. The python-hostlist library is really nice though. :)


E.g. 
/home/mattias/misc/pdsh-2.22/scripts/dshbak -c << t10 ...fail for 
/home/mattias/misc/pdsh-2.22/scripts/dshbak -c
==[ Input ]=================
n1:  x
n01:  x
n2:  x
n3:  x
n5:  x
n00:  x
==[ Expected output ]=======
----------------
n[00-01,1-3,5]
----------------
 x
==[ Real output ]============
----------------
n[00-3,5]
----------------
 x
============================

Original comment by don.fanucci on 29 Sep 2010 at 1:26

Attachments:

• run-test.sh

[GoogleCodeExporter]

Thanks for the tests, that is unbelievably helpful! I guess you caught me
not doing very good testing ;-)

I get your point about using hostlist.c code, but I don't want to rewrite
dshbak in either C (or python for that matter) right now ;-) Though I wonder
how difficult it would be to rewrite in C.

For now, I'm sure there is just still some small bugs in dshbak, and I'll
add your tests to the internal dshbak testing (invoked with 'make check')
Thanks again!

Original comment by mark.gro...@gmail.com on 29 Sep 2010 at 3:54

[GoogleCodeExporter]

Ok, the remaining problem was that host suffixes that were numerically
the same but had a different zero-padding interfered with the detection
of ranges since only the numeric value was used as an index lookup.
Also, the zero padding of zero wasn't working.

I've simplified the whole thing by caching the zero-pad along with the numeric
value in the index-lookup hash.

Can you try this patch? It passes the tests you've 

Original comment by mark.gro...@gmail.com on 29 Sep 2010 at 4:45

Attachments:

• 0001-dshbak-Fix-coalesce-of-hosts-with-different-zero-pad.patch

[GoogleCodeExporter]

The patch seems to work fine. :)

/m

Original comment by don.fanucci on 29 Sep 2010 at 9:59

[GoogleCodeExporter]

This issue was closed by revision r1240.

Original comment by mark.gro...@gmail.com on 22 Oct 2010 at 12:11

• Changed state: Fixed