Everything -rename, is essentially stand-alone?

[therube]

Everything.exe -rename, is essentially [a] stand-alone [renamer] (?) except that it can (potentially) read (read-only) an Everything.ini file.

Is that basically correct?


Likewise, it cannot be used with, take its' input from, a -filelist (so something like; Everything.exe -filelist dumy.efu -rename).
(Similarly, no undo is afforded with -rename.)

[void]

Yes, correct.

You can use either:
-rename file1.txt file2.txt file3.txt ...
-or-
-rename-list filenames.txt

where filenames.txt is a text/plain file containing a list of filenames, one per line.

Do I need to support EFU file lists with -rename-list?

Both will create a new Everything.exe process.
The rename process does not interfere with your existing Everything processes.
The instances are separated, even if you use the same instance name.

Both will read your Everything.ini to position the renamer and load previous rename history.
However, neither will save any changes back to your Everything.ini.



The only other command line option that is supported with -rename and -rename-list is -instance

For example, calling the following:
Everything.exe -rename file1.txt
Everything.exe -rename file2.txt

will add both file1.txt and file2.txt to the same rename dialog.



For example, calling the following:
Everything.exe -rename file1.txt -instance 1
Everything.exe -rename file2.txt -instance 2

will create two rename dialogs, with one dialog containing file1.txt and the other containing file2.txt

-instance
-rename
-rename-list

[therube]

Do I need to support EFU file lists with -rename-list?

I would think not.

Never knew -rename-list existed.

My thought was a way to bypass (Windows) "variable" (or other) size limits.
So I thought if you -rename could load a -filelist, that would likely work.

And as a -filelist is essentially a text file, & as (I now know that) -rename-list exists, & is a text file at that, that should be *fine.

[therube]

*fine

Heh.

So I attempted to load "filenames.txt" .
189K lines (so "names"), 18 MB.
And while it did load - something, what it loaded looks to be (ascii) memory contents (so some sort of "overrun" is going on, I'm assuming [& that was far less then 189K "items"]).

A more svelte "filenames.txt", 9000 lines (so "names"), 770 KB, loaded (expected file names) without issue.

(Everything x86.
I'm not concerned about the above.
I didn't actually rename, but I'll assume it would have worked in the latter case. The substitutions, New Format: were OK.


Maybe there's a taker who might find it interesting to test a larger filenames.txt with x64 .)



(The "inline" Edit Post is kind of cool. Hadn't seen that before.)

[void]

Could you please send the "filenames.txt" compressed to support@voidtools.com

Everything will try to read the txt file as UTF-8 if no BOM is present.
If there's an invalid UTF-8 sequence the txt file is treated as ANSI.

[therube]

Whatever I might have had open at the time, I simply Ctrl+A + F2, so there was nothing specific.

Trying it again, searching /cache2/, also happened to be 189K items, 17 MB, but they loaded as expected.

I'll keep an eye out...

[therube]

Trying it again, searching /cache2/, also happened to be 189K items, 17 MB, but they loaded as expected.

Actually, it didn't.
The list was truncated, with the final character being unexpected,

05BCBC4鴨

.
That was part of the 123,628th line (of 189,991 lines, or file names).
(If it "quit" due to a memory issue, & in using x86, not a concern in that regard.)
[dumy9.7z, emailed.]

what it loaded looks to be (ascii) memory contents

Don't hold me to that, but don't discount it either.
I wasn't particularly paying attention at the time, & while what may have looked like an ascii memory dump, may in fact have been simply odd named files (which I'm apt to have), but then it could have been...

[therube]

(found it)

Don't hold me to that

Not an ascii dump.
Simply names that resemble an ascii dump.

Though severely truncated.
The file (renamelist2) was simply a "text" file (no BOM or such).
I'm assuming it was truncated at this point:

C:\TMP\SEA\FF\89-PROFILE\cache2\‚“Š¡.FOLDER

[renamelist2.7z, emailed.]

[void]

Thanks for the filenames.txt therube,

There's an invalid UTF-8 sequence in this list:

Code: Select all

éôèüí.FOLDER

This list was exported as ANSI text.



Everything is currently not treating this file as ANSI when it should be...
I'll have this fixed in the next alpha update.

For now, please make sure you save your lists as UTF-8.
(or save as UTF-16 with a BOM)

[void]

Everything 1.5.0.1357a adds support for filelists with -rename-list.

Invalid UTF-8 on each line in file lists is now treated as ANSI.

TXT files are now treated as TAB separated values files (TSV)
The first column defines the list of filenames.

This new change shouldn't cause any difference with reading TXT files as TAB is not a valid filename character.

Please let me know if you have trouble loading filenames from a TXT file.



Supported file lists can be either CSV or EFU files with a filename column.
If the filename column is missing, then no header is used and the first column is treated as the filenames.

All other file types are treated as TXT.