.inf files and HTO import/export

Olly Betts olly@survex.com
Tue, 11 Sep 2001 21:54:09 +0100


Right, I'm back from expedition in Austria.  Mark and I both got quite a lot
of work done on Survex in between caving trips.  Hopefully there will be a
prerelease of 0.99 later this week.


As you may have noticed, in 0.98 cavern has a new --log command line option
to send output to a log file instead of to the screen.  So:

cavern --log example.svx

creates example.log containing the output from cavern.

This effectively makes the example.inf file produced obsolete since the .log
file contains all the information in the .inf file, plus any warnings and
errors.  In fact running:

cavern --quiet --log example.svx

Produces a .log file identical to the .inf file except for a version number
and any warning/error messages.

The ".inf" extension is used by MS Windows for driver information files
which means we can't add file associations for it.  It's also a bit cryptic
whereas ".log" is fairly self-explanatory.

Any thoughts?


I've been reworking and updating the documentation, which has lead me to
look at the HTO import/export utilities - svx2hto and hto2svx.  Both were
written a long time ago and haven't been kept in step with changes in the
survex command set.

One symptom is that svx2hto just won't understand any modern .svx file - it
really needs to use the same .svx file parser as cavern.  This is a lot of
work, so my thought is to remove svx2hto and postpone HTO export until spud.

Now hto2svx at least creates .svx files which cavern can read (though it
uses the deprecated *prefix command rather than *begin/*end).  But looking
at the HTO 1.4 specification, few of the tags are interpreted, and I suspect
it wouldn't correctly handle any real world example data (it fails to output
a usable .svx file for any of the 3 examples included in the HTO 1.4 spec).

Updating hto2svx should be fairly easy, but it worries me that at least one
of the example .HTO files included with the 1.4 specification doesn't seem
to match the spec (e.g. CTS.HTO uses CTB and CTE which aren't defined
anywhere I can find).  So of the 3 files I can test it on, one appears
incorrect...

So given that hto2svx has probably not been usable for some time and nobody
has complained, my inclination is to remove this too, and to redo it
properly in spud as an input filter.

Again, any thoughts?

Cheers,
Olly