IPTOCOUNTRY.HEX is a 116402-line file that looks like this. Code: v:\> head v:\IpToCountry.hex 00000000,00FFFFFF,ZZ 01000000,010000FF,AU 01000100,010001FF,CN 01000200,010003FF,CN 01000400,010007FF,AU 01000800,01000FFF,CN 01001000,01001FFF,JP 01002000,01003FFF,CN 01004000,01007FFF,JP 01008000,0100FFFF,TH I tried reversing it with Code: tpipe /input=iptocountry.hex /sort=0,1,0,1,8 15 minutes later, it was still running, using all of one processor ("sort /r IpToCountry.hex" takes a couple seconds). When I tried to interrupt it with Ctrl-C, I got "tpipe.EXE has stopped working ...". I told Windows to "Close the program" ... --------------------------- Error --------------------------- Runtime error 217 at 00010524 --------------------------- OK ---------------------------
Will TPIPE.EXE be linked to an internal TPIPE (like SHRALIAS.EXE) so it doesn't have to be in the path?
There is something *very* strange about that file. TPIPE is actually sorting it, albeit very slowly (it took about 20 minutes on my system). I created a similar file that was about 3.5 Mb with 300,000 lines that sorts in 2.1 seconds, so I know it's not an issue with the file size or number of lines. I'll send the file to the textpipeengine.dll developers to test.
Did you look at the file's contents? It's hardly "strange". I made that file with TCC. The original (iptocountry.csv, link below) has the same number of lines, but with the IPs in non-dotted decimal numeric form. TPIPE /SORT chokes on it similarly. FYI: Code: copy "http://software77.net/geo-ip/?DL=2 -O /path/IpToCountry.csv.zip"
The crash when interrupting with Ctrl-C happens with all files (that give you a change to do so). Did you fix that?
I did look (extensively) at the file's contents. The "strange" thing is that it chokes the sort routine, while a similar (larger) file does not.
These: Code: v:\> tpipe /? TPIPE: The system cannot find the file specified. "CON:" v:\> tpipe TPIPE: The system cannot find the file specified. "CON:" 1. cause \aemail\datamystic.log to be created and written to 2. should produce a more useful result
WAD. I put it back in for the duration of the beta. Code: help tpipe produces a useful result. "tpipe /?" producing several pages of output (that you couldn't use anyway without referring to the help) would not be a useful result.
I agree; you're not going to get any useful TPIPE help in the console. But "TPIPE" and "TPIPE /?" producing an error message is equally useless. Users are going to do that. Let them give the brief message "try HELP TPIPE" or even take you directly to the help.
I can do that, provided you don't mind TPIPE loading significantly slower (because it has to load Internet Explorer as well).
Well you know how I feel about speed. Must it load IE just to output the message "Try HELP TPIPE" and quit?
