The maximum file size is – depending on the command you gave or the menuitem you selected – about 10 million lines or 1 GB. These limits should in practice never apply to.
Waiting is necessary not with hundreds, but with (ten-) thousands of files (record: over 170,000 files!) (especially when copying, I came to around 1.5 - 2 minutes. per GB on my computer).
Nearly all tables can be sorted (exception: the MyCommands-table) by a simple click on the header of the column by which the table should be sorted. This function you should only use as long as there are less than about 10,000 lines in the table. If you chose to sort a table with about 10,000 lines, the program will seem to hang just a few minutes. But response time will go up sharply afterwards: Better not try! (I tried to sort a table with about 40,000 lines – the system seemed to do nothing for about 40 minutes!) Tables with just a few hundreds of lines will be sorted instantly.
Besides, it seems that after a program's revision no more (significant) problems related to the response time of certain commands exist. In the worst case you will wait minutes (exception: see below!)! This applies to only some very special commands. In most cases even with a lot of data you will have to wait at the very most several dozens of seconds. Sometimes the program is so fast that it looks like nothing has been made!
But searching a large directory tree can take some minutes!
The backup of a directory tree with tens of GB can of course still last more than one or even two hours!
Windoze has problems with empty filenames. If you enter e.g. "classpath" as extension, files with the full name ".classpath" are not found.
You select "All Files" after you have chosen „MyFileEntry-List“→„Load“, then submenu „searchcondition is NOT true“ under „Additionally mark lines, if“ under „MyFileEntry-List“. Enter „classpath“ as search condition and „Search in“ (apply to) „Extension (old)“.
Then „Remove marked lines“.
When entering e.g. „classpath“ and „Extension (old)“ after selecting „Additionally mark lines, if searchcondition is NOT true“, all files, which have another extension as „classpath“ are selected and so removed.
That leaves all files with the extension „classpath“, and therefore only the „.classpath“ files. You do correspondingly for „.profile“, „.project“ etc.
The date format is „month (three letter abbreviation) day, year (four letters!) hour:minutes:second AM or PM“,e.g. „May 6, 2010 10:42:27 AM“! Time, including second and AM resp. PM, cannot be omitted!
Dec 1, 2009 11:59:59 pm
or
Jan 1, 2000 0:0:0 am (beware of the blanks behind the comma and elsewhere!)
or
Jan 1, 08 0:0:0 am (Beware! Is interpreted as Jan 1, 1908 00:00:00 AM!)
or
Jan 1, 08 0: 0: 0 AM (Beware! Is interpreted as Jan 1, 1908 00:00:00 AM!)
Spaces are allowed to some degree.
Table cells are partly editable . The cursor is positioned in a table cell by a double click.
The appending of strings goes via „Replace on marked files“. You simply replace all („(?s)\A.*\Z“ = „Flag dotall - beginning – any character – end of the input but for the final terminator, if any“) by all plus the new text („$0new_text“). The dotall-flag („(?s)“) naturally is only necessary for multi-line texts, i.e. e.g. not for directory names or extensions. (It doesn't harm anyhow.) Important: „\A“ and „\Z“ shouldn't be omitted, otherwise there will be strange effects. The new text can (like the old one, i.e. the input) of course be multi-line, particularly begin with a line feed (then the new text will start on a separate line).
Replace:
(?s)\A(.*)\Z
by:
$0
variable=value
results in:
old_text
variable=value
Probably – before appending new text – you will want
to replace possible empty lines at the end of the original text by no
or exactly one new line. You can do so by replacing the (search-)
string „[\r\n]+\z“ by an empty „Replace by“
or one which contains the desired number of new lines. The
searchstring „[\r\n]+\z“ naturally does only match texts
which at least contain one new line at the end.
Files which
completely lack new lines at the end, you may select by „Additionally
mark lines, if→searchcondition is true“ with the
searchcondition „[^\r\n]\z“. Then you may append the
missing new line by replacing „(?s)\A(.*)\z“ by a
(multi-line) text consisting of „$1“ plus a new line.
(This way only files will be affected where the new line is really
missing.)
In column „Replace by ...“ of the „MyCommands table“ may be possibly required a multiline input. The reason is that for some reason in Java® the regexp (regular expressions) are not handled 100 % correctly. In theory, e.g. „\n“ should be interpreted as a (UNIX-) line terminator (not only within the search string, but also in the „Replace by ...“; it works within the search string!). But the only special sign is the backslash („\“); it must be escaped by prefixing it by a second („\\“). „\n“ comes out simply like „n“.
A workaround is implemented: if you go to a field of this column and enter CTRL-I („Input assistance“), appears an (entry-) help-mask, with just a multi-line textarea (and some menuitems). The data for this is read from the array, which backs the table (and this is the point, not from the table cell in which the cursor is positioned, and where there might have been made inputs, causing everything to be converted to single-line). So: multiline input immediately requires CTRL-I after double-clicking on the table cell!
When removing Command-Lines the cursor shouldn't reside on one of the first two columns (of the MyCommands-table).
Always when Copying Command-Lines only one line is copied; if more then one is selected, the first is taken.
When Copying Commands: The copies will be placed into a Stack (Lifo-storage, last copied will be inserted first)! Thus multiple copys and then multiple inserts are possible.
runs well so far, there are created (consecutively) numbered Zip-Files (with sizes slightly below 4 GB, the maximum size of a single Zip-file).
Sole drawback:
The Zip-functions of Java® up 'til now are not (completely) compatible with WinZip, 7Zip, and Windoze XP or the like. There will be problems, if there are Zip-entries with characters, which do not belong to American standard Ascii (like German umlauts or French vowels with accents; e.g. ä, ö, ü, é, è ê etc.) in the Zip-entry-name (thats to say a full path-name as it was saved when the Zip-entry was created, i.e. the file was compressed). The files can be saved without any problem either with a Java®-program, or WinZip etc., however you can hardly recognize the filenames when you open e.g. a Zip-file created with a Java®-program with WinZip, and what's more: they don't let themselves be extracted.
That's the reason why there is a utility for (viewing and)
extracting Zip-files created with the program (see „Zip“-menu).
When you create a Zip-file “normally “ (with WinZip,
7Zip, and Windoze XP or the like), use a non-Java®-tool for
viewing and extracting (unless it contains real
pure Ascii)
The Backup always runs on all files (which are currently displayed, not only the selected)!
The help-texts are packed (like all other files) with the Jar-file. To locate the Jar-file (and thus the help-texts) from the running program, the name of the Jar-file had to be hard coded (at least partially) – cause the name of the Jar-file can't be obtained elsewhere. The method for achieving the task is, to locate the first (four) letters of the program's name in the whole path (directories included). Thus the filename can be chosen freely, if the directoryname contains „repl“ (the first 4 letters of „Replace_WinBatch“). On the other hand, the directoryname doesn't count, if the filename contains „repl“. (E.g. the name of the original Jar-file is „Replace_WinBatch.jar“, so it can be copied anywhere without any problems, even with the help-texts). If other paths contain „repl“ that seems not to cause any problems.
With the Windows-operating system there are (by pure chance ;-) )
some problems with links („.lnk“-files).
Example:
If
there is a link to a directory, this link won't be treated as a
directory (hence won't be expanded), but will be treated as a normal
non-text-file and thus can (only) be copied.
But when displaying
the filechooser while selecting files for “loading” you
can open a link to a directory by double clicking. You can then
select any file from the referenced directory, especially “all”
using Ctrl-A. If this directory again is a link to (another)
directory (etc.), it becomes a little complex. You must follow all
links to other directories (recursively) and load the contents of the
referenced directories (as far, as you want to!).
I'm sorry, but I
couldn't find a workaround with my programming.
Under
Windoze you will best not
work with links at all!