"cut" switch deletes content if parameters not found
One hundred command line tools in a small and portable binary.
Brought to you by:
stahlworks
i realized that when the marker for the cut command wasn't found in the specified text-file, then sfk would create an empty document instead of just storing a duplicate of the original file. using this in a batch file breaks it. example:
sfk filt test1.txt>test2.txt -cut "*" to "[Files]"
if [Files] is not found, then test2.txt is just empty, even though logic dictates that nothing should be cut from text1 then.
logically, it is a bug, but it is hard to fix: sfk would have to pre-scan
the whole file if [Files] exists anywhere, so the code must be changed from
a simple 1-pass system into 2-pass. same applies to filter -inc "*" to something.
i'll think about it, but i may only extend the help text to tell about the behaviour.
i think just mentioning the behavior might be enough, even though it would be nice if sfk behaved properly. if you ever implemented a 2-pass scan, may be you can integrate a switch that would allow people to choose between the old scan and the new one. this way, people who deal with fixed documents that always have the required markers can save a lot of time, especially if the document is pretty big in size
fixed with 1.6.1. the case is detected, and depending on the context files are not rewritten or the command is stopped.