# skip-blame because this was mechanically rewritten the following script. I
ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t
ones appear to be, and they run without addition failures on both Windows and
Linux.
import argparse
import os
import re
ap = argparse.ArgumentParser()
ap.add_argument('path', nargs='+')
opts = ap.parse_args()
globre = re.compile(r'^(.*) \(glob\)(.*)$')
for p in opts.path:
tmp = p + '.tmp'
with open(p, 'rb') as src, open(tmp, 'wb') as dst:
for line in src:
m = globre.match(line)
if not m or '$LOCALIP' in line or '*' in line:
dst.write(line)
continue
if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'):
dst.write(line)
continue
dst.write(m.group(1) + m.group(2) + '\n')
os.unlink(p)
os.rename(tmp, p)
On Windows, the various bundle hexdumps were being truncated at the first
occurrence of 0x1a. The line endings in the sequence generation then needs to
be standardized on LF so that the file is the same for the tool tests.
I still get the following diff on Windows 7 with NTFS. I'm not sure if it is
expected and we should wildcard the link count, or if something needs to be
fixed.
@@ -58,7 +58,7 @@
$ ln bar baz
$ f bar -n baz -l --hexdump -t --sha1 --lines=9 -B 20
- bar: file, links=2, newer than baz, sha1=612ca68d0305c821750a
+ bar: file, links=0, newer than baz, sha1=612ca68d0305c821750a\r (esc)
0000: 31 0a 32 0a 33 0a 34 0a 35 0a 36 0a 37 0a 38 0a |1.2.3.4.5.6.7.8.|
0010: 39 0a |9.|
This tool is like the collection of tools found in a unix environment but are
cross platform and stable and suitable for our needs in the test suite.
The main reason it is "needed" now is for hexdump of revision branch cache to
keep an eye on how it changes and make sure the format is stable.
It is a very generic tool that can end up being used a lot in tests, so I gave
it very generic name.
