INFO: due to the new "Create Topic" function used by Sourceforge,
all new topics went to the wrong forum, so I had to reorganize.
Forum "03 DView Discussion" had to be deleted, and this is a repost
of the SFK articles placed therein.
=== Question about replace -bylist ===
First, just found this today and looks like a great tool... :)
I am sure I am missing something, but if I run this command:
replace -spat -bylist commands.sfk -dir .
with these contents in commands.sfk:
This gives me the following errors:
error: incomplete replacement pattern: "|href=\qhttp://www.domain.org/|href=\q/|"
note : patterns must look like src_dst or "/from/ to /"
note : if ""|href=\qhttp://www.domain.org/|href=\q/|"" is a single filename, spec
ify it as first parameter.
note : surround your expression by two double quotes "
note : escape inner quotes as \" or \q (with -spat option)
note : say -dir ... -file ... to specify multiple target files.
1 errors occurred.
But then if I take those text patterns exactly and run this command it doesn't give me any errors:
sfk replace -quiet -spat "|href=\qhttp://www.domain.org/|href=\q/|" "|href=\qhttp://domain.org/|href=\q/|" -dir .
What am I doing wrong?
Remove all double quotes " within the commands.sfk file.
SFK thinks that " is the pattern separator instead of |
I may have to improve the error message or help text in that case.
===== Any way to reuse variable text found in filter replace? =====
Is there any way to reuse the (variable) text found vith a wildchar?
Sometimes is needed to find a string using a pattern and then using this same
string again in the second part of the command. Suppose you want to change the /
by - in a string containing dates. It would be necessary to have something like this:
sfk filter file.txt -srep "??/??/????-??-??_"
Simply changing the "/" with "-" is out of the question because the "/" occur in may
other places, and only these between dates can be changed.
Some other tools allow to refer to the found characters with some variable.
Assuming that the variables would take the names &1, &2 and &3 for each of the
32 occurrences, then the command would be something like:
sfk filter file.txt -srep "??/??/??&1-&2-&3_"
If that would be possible, you can refer to them and even change the order.
For example, imagine you want to exchange the positions of date and month:
from dd/mm/yy to mm/dd/yy
It would be nice to be able to do it this way:
sfk filter file.txt -srep "??/??/??&2-&1-&3_"
A replace can be limited to specific lines or text within a line,
sfk filter in.txt -where "??/??/????" -rep "_/_-_"
-> replace all / by - but only in lines containing
the pattern ??/??/????
sfk filter in.txt -within "??/??/????" -rep "_/_-_"
-> replace all / by - but only in phrases looking
like the pattern ??/??/????
but beyond that, there is indeed no way in sfk to reuse
a found text in the 2nd part of a replace parameter.
> sfk filter file.txt -srep "_??/??/????_&1-&2-&3_"
Thanks for the suggestion, but if someone wants
to reformat a phrase "20130309" to "09.03.2013",
then we would need a more complex syntax.
Furthermore, "&" is a special character (used in Windows
to chain commands, used by Linux to run a process in background),
so I don't like to use it.
Right now, I can only recommend to use the "sed" command
under Linux for such replacements (or search for a sed Tool
under Windows), as it provides regular expressions.
===== SFK HTTPSERV =====
Just realized, this HTTPSERV is a great little feature that fills a huge gap for me.
With the proliferation of phones and pad computers, with different OSs, there is
frequently no easy way to get my devices to share files without going to the cloud,
like DropBox, or (yuck) iTunes. But the HTTPSERV function of SFK gives a very quick
way to share without leaving the LAN. One minor obstacle that I have, is that
file-names with spaces do not work well over the HTTP. It is likely more work
than it is worth to add a file-name translation process to remove the spaces,
but since spaces in filenames are so common in the Windows world, it would be
a useful upgrade.
OK, there is a bug indeed. Transfer of filenames with blanks (or other special
characters) will be fixed in the next update.