Hello Wilfred,

On 14 Feb 15 17:30, Wilfred van Velzen wrote to Nicholas Boel:

 WV> If both the filename, and the .tic file contained the comma, it's not
 WV> a htick issue.

It didn't. The filename was correct, with a period. The comma was only in
the "replaces" line in the .TIC.

 WV> It's a bit odd, but a comma is a valid character in a filename both on
 WV> windows and linux. So if both the .tic and the filename contained the
 WV> comma, what htick did was the only thing it should do...

That is not the case, but at least you're trying to clarify specifics. :)

 NB>> What I would like to know is if there is a "normal"
way to handle
 NB>> this? Does htick skip the typo, which in turn would *not* use
 NB>> that "replaces" command, and continue processing it
successfully
 NB>> and pass it on to downlinks with the same typo in the .tic? This
 NB>> seems to be what occurred, and that doesn't seem like a good
 NB>> idea, IMO.

 WV> This depends on my remark above...

Why not just answer it assuming either way instead of stopping on one
assumption, which wasn't the correct one anyways?

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910