About regular expressions, is there a way to make them case sensitive?
For example, when using them in Go EXPANDBRANCH=collapse,regexp PATH "^(TEMP|Temp)$"
, I would like them to only match TEMP or Temp but not temp.
About regular expressions, is there a way to make them case sensitive?
For example, when using them in Go EXPANDBRANCH=collapse,regexp PATH "^(TEMP|Temp)$"
, I would like them to only match TEMP or Temp but not temp.
There is with the scripting regex stuff, but I don't think you can do it with most commands, since they're geared for matching files which are case-insensitive on Windows.
In 13.3.1 you'll be able to do this with Go EXPANDBRANCH=regexp,case
.
Many thanks!
A bit breaking the rule of one question per topic (although it is highly related), sorry about that.
In the case of wanting to differentiate 2 folders that have the same name, for this command, it would not be possible right?
I was thinking, maybe, via scripting, to be able to use instead the files loaded in cmd.files
and implementing a new argument, e.g. Go EXPANDBRANCH=script
?
I'd expect that to work already (without the =script
being needed).
Thanks Leo. I meant 2 folders with the same name, in different locations. In that case it still might not be possible to distinguish them, since PATH
only takes into account the name and not the fullpath. Is case
new argument going to change that too?
They should still be distinct paths to the command object. (Else you couldn't do other things like copy two files out of a collection with the same names but different paths.)
(Let us know if it doesn't work, of course.)
Exclusively talking about PATH
in conjunction with Go EXPANDBRANCH
According to the manual, PATH
can take as value only one path. And when you want to use it with several folders programmatically, it would mean to execute a command for each one of them. And when combined with Go EXPANDBRANCH=wild
or regexp
, PATH
only takes into account names, not fullpaths. Hence my suggestion about the script
argument and using the folders loaded in cmd.files
.
Don't use the PATH
argument at all. Go EXPANDBRANCH
works on the selected folders if no path is specified. When run from a script, the selected folders are the ones set on the Command object.
Exactly, it’s when you want to use other folders that were not previously selected (by setting files on command) that it becomes a bit difficult.
You can give the command object the full path to a file/folder to add it to the command's selection.
Easiest thing to do is test it. What's the scenario where you're going to be using this? Folders under a library or collection?
File system folders. My goal is to expand the selected folders, to their maximum depth, programmatically. To do this, I set each new level of folders to the Command object, select them using SELECT FROMSCRIPT
, and then be able to use GO EXPANDBRACH
. I can't directly use that command without first selecting the target folders, as GO EXPANDBRACH
applies to the selected folders, not to those loaded into the command object.
Oh, that's not what I expected. We can take a look at that.
Thanks @Leo. I thought that was how it was designed.
So to clarify, GO EXPANDBRACH
should take into account the folders loaded in cmd.files
?
For example, this small test script shows that it currently does not.
function OnClick(clickData) {
var cmd = clickData.func.command;
cmd.ClearFiles(); //clear files, so Go EXPANDBRANCH should expand all the folders
//cmd.SetFiles(clickData.func.sourcetab.dirs); //this one doesn't work either
cmd.RunCommand("Go EXPANDBRANCH"); //expand selected/focused items
//cmd.RunCommand("Go EXPANDBRANCH=script"); //Perhaps something like this to use cmd.files
}
EXPANDBRANCH test.dcf (877 Bytes)
(sorry for changing the thread topic. You can change it to a new one if you think it's more appropriate)
We'll add Go EXPANDBRANCH=script
in 13.3.2.
100% working. Many thanks!