Hi!
One of my scripts (JS button script) uses the RENAME command in a .RunCommand() call.
It takes the full paths of selected files "p" and renames them to a new name "n".
var cmd = "RENAME FROM \""+ p + "\" TO \"" + n + "\" IGNOREEXT";
ClickData.func.command.RunCommand(cmd);
The above creates commands looking like this: RENAME FROM "C:\\test name.txt" TO "test" IGNOREEXT
which is working fine in most cases.
Today, however, I tried renaming files that contained brackets ([, ]), and the command was ineffective.
It feels like DOpus might think this is a pattern to be matched, so I tried escaping the brackets by replacing them with themselves, preceded by an apostrophe ', as per the documentation: RENAME FROM "C:\\'[test'] name.txt" TO "test" IGNOREEXT
This did not work.
I tried different things, such as:
Using different escape chars (\, `)
Escaping the whole string like a RegExp string (Prepending special characters with a backslash via str.replace(/[\-\[\]\/\{\}\(\)\*\+\?\.\\\^\$\|]/g, "\\$&");
Only escaping the opening brackets (in case that disqualifies the pair as a pattern sequence, and the second apostrophe is already interpreted as a literal apostrophe - because they are valid characters for Windows files and folders, too)
How do I do this?
I wish there was a way to just let DOpus know that it shouldn't try to interpret the FROM argument as a pattern to be parsed but a literal filename.
I don't think it's brackets causing the problem. You're specifying a name with a file extension, and no PATTERN argument (so the filename is used as the pattern), and you're also specifying IGNOREEXT.
It would then try to rename the file [test] name.txt, ignoring its extension, [test] name, using the pattern [test] name.txt, which doesn't match [test] name and skips the file.
This works OK:
function OnClick(clickData)
{
var p = "C:\\[test] name.txt";
var n = "new name.txt";
var cmd = "RENAME FROM=\""+ p + "\" TO=\"" + n + "\"";
clickData.func.command.RunCommand(cmd);
}
Thank you, Leo!
Coming through quick and helpful, like I'm beginning to feel you always do
It is strange that the presence of IGNOREEXT messes up the replacement command.
Indeed it works without it, but since I feel like using it is so much neater than getting and appending any extensions myself, I'd like to keep using it.
By pointing out that the search for a pattern falls through to the FROM file name, you made me realize I could supply a dummy PATTERN argument, which I did like so: "C:\\[test] name.txt" TO "new name" IGNOREEXT PATTERN *
This does feel a little strange. Would you agree that the REPLACE command could benefit from a LITERAL or PATTERNLESS or FILENAME or FULLPATH argument that would cut out all the pattern stuff where it isn't needed?
Might be something to think about for a future update. Should I post a feature-request for this?
also, because my script is working with the clipboard and I'd just cut " IGNOREEXT" from the end of my command string, I happened to try renaming a file to " IGNOREEXT" (because for these tests, I don't care much about what I rename the file to and I was too lazy to alter the part of the script that sets the new name to the content of the clipboard) "C:\\test.txt" TO " IGNOREEXT"
, which effectively turned into "C:\\test.txt" TO "" IGNOREEXT, which is effectively "C:\\test.txt" IGNOREEXT
, acting like I had supplied no new name at all and opened the Rename dialog.
I feel like that shouldn't happen; I would argue that the file should be renamed to " IGNOREEXT", not ignoring the extension. (Leading spaces are another issue, but it seems to behave fine. The above also goes for "IGNOREEXT" without the leading space)
Maybe anything within quotes should not be parsed for these arguments?
Sorry, had to read up on what account linking does to find out that without it, only simple things are typically answered.
What was that that/it you were referring to?
Ooh, I'm sorry, I didn't see that you pointed that out above! That takes care of that!
Sure, it isn't needed per se, we can supply a dummy pattern as I did above. I just felt like that was a bit ugly, especially considering there is no need at all to do any wildcard pattern matching.
Or am I missing a better way to make it work?
But the issue wasn't that [ and ] were being interpreted as wildcard characters. So a PATTERNLESS argument would not have helped.
And if you want to use something like the combination of IGNOREEXT and PATTERN arguments to rename a particular file without worrying about the extension, then PATTERN=* is easier than specifying the filename (minus extension) a second time.
It wasn't?
Why else won't the RENAMEIGNOREEXT command work when the FROM path contains brackets?
I really don't want to use PATTERN at all, it's just that the command won't work without it.
I feel like I might be misunderstanding what IGNOREEXT does to arrive at the desired (or not) result.
It sounds like you're saying it's responsible for interpreting the filename as a pattern, making it necessary to specify a dummy pattern in this case.
If that is the case, it might need to be mentioned in the documentation, if the behavior is to remain as is.
It doesn't feel intuitive to be able to simply supply full paths without having to worry about pattern interpretations for FROM, but suddenly having to worry about it as soon as IGNOREEXT is present.
If you're saying "it's fine, nobody is going to have a problem with that except for you", then I'll be quiet about it, but if you feel like this is something that might be worth improving, I would like to see that happen (and post a feature request?)
Hmm, maybe you're right, actually. Although I'm surprised that worked at all, even for files without brackets, since the filename should not match the pattern in IGNOREEXT mode.
Maybe we're being more clever behind the scenes and removing the extension when building the implicit PATTERN argument when IGNOREEXT is specified. I need to check the code to see what it's doing.
But you should be using PATTERN=* for this anyway, I think.
