WAD TPIPE /SPLIT makes extra 0-byte file

[vefatica]

If you ask TPIPE to split a file at N lines and the number of lines in the file is a multiple of N, you get an extra 0-byte file. Below I asked it to split the 4-line file at 2 lines.

v:\> echo My^r^ndog^r^nhas^r^nfleas. > doggy.txt
 
v:\> dir /k /m doggy*
2013-06-01  00:51              22  doggy.txt
 
v:\> tpipe /input=doggy.txt /split=2,0,0,0,0,2,doggy.txt
 
v:\> dir /k /m doggy*
2013-06-01  00:51              22  doggy.txt
2013-06-01  00:53              9  doggy.txt.000
2013-06-01  00:53              13  doggy.txt.001
2013-06-01  00:53              0  doggy.txt.002

You also get an extra 0-byte file if you ask it to split at size N and the file size is a multiple of N. Below I asked it to split the 22-byte file at 11 bytes.

v:\> del doggy.txt.0*
Deleting V:\doggy.txt.000
Deleting V:\doggy.txt.001
Deleting V:\doggy.txt.002
     3 files deleted
 
v:\> tpipe /input=doggy.txt /split=0,11,.,0,0,2,doggy.txt
 
v:\> dir /k /m doggy*
2013-06-01  00:51              22  doggy.txt
2013-06-01  01:02              11  doggy.txt.000
2013-06-01  01:02              11  doggy.txt.001
2013-06-01  01:02              0  doggy.txt.002

 

[rconn]

WAD - the extra output file is created before the next (empty) line is read from your input file.

 

[vefatica]

WAD - the extra output file is created before the next (empty) line is read from your input file.

And that's OK with you? Regardless of the reason, it's crummy behavior.

 

[Charles G]

I agree with Vince too....

 

[Steve Fabian]

I also agree. Having often coded this kind of behavior, it seems easier to just blindly create the empty file instead of checking every time in the line/character processing loop whether or not it was already created. But a simple test when the loop is completed to delete it if nothing was written would eliminate the problem; also, it would allow counting files to determine the number of splits.

 

[rconn]

And that's OK with you? Regardless of the reason, it's crummy behavior.

I have no problem with it -- I think it's one of your theoretical problems rather than a real issue. And since I can't change it anyway, I'm not going to agonize over it. I passed it on to the developers; they said WAD and unless they change their minds we'll have to deal with it as-is.

 

[vefatica]

I have no problem with it -- I think it's one of your theoretical problems rather than a real issue. And since I can't change it anyway, I'm not going to agonize over it. I passed it on to the developers; they said WAD and unless they change their minds we'll have to deal with it as-is.

You're very tolerant. And it's not theoretical. It *will* happen some (probably small) portion of the time /split is used. I don't think "crummy" was the best choice of words; it's ridiculous behavior. I doubt it would *ever* be desired behavior.

 

[rconn]

You're very tolerant. And it's not theoretical. It *will* happen some (probably small) portion of the time /split is used. I don't think "crummy" was the best choice of words; it's ridiculous behavior. I doubt it would *ever* be desired behavior.

You're certainly not required to use it. If an extra 0-byte file every few hundred (or few thousand) times you run TPIPE i/split s a critical problem for you, you'll undoubtedly be happier creating your own utility.

(I think this thread is following the classic pattern of "the more insignificant the problem, the more passionate the arguments.")

 

[vefatica]

You're certainly not required to use it. If an extra 0-byte file every few hundred (or few thousand) times you run TPIPE i/split s a critical problem for you, you'll undoubtedly be happier creating your own utility.

(I think this thread is following the classic pattern of "the more insignificant the problem, the more passionate the arguments.")

I see it as the more ridiculous the behavior, the more passionate the argument. There's just no reason for it. It looks bad. It's a poor reflection on your product? I don't need to write my own. I have two SPLIT.EXEs (one, Gnu) that don't do it.