I'm trying to get "base directory" from TM_DIRECTORY variable (which gives full path) to be transformed to PascalCase (which is in snake_case).
So, for /this/is/path/to/base_dir, I want to get BaseDir
This is what I've got so far:
${TM_DIRECTORY/(^.+\\/(.*)$)/${2:/capitalize}/g} from this
which gives me:
Base_dir for /this/is/path/to/base_dir
I feel like I have to somehow incorporate ${TM_DIRECTORY/((^[a-z])|_([a-z]))/${2:/upcase}${3:/upcase}/g} but don't know how.
Use this:
"${TM_DIRECTORY/(^.+\\/(.*)$)/${2:/pascalcase}/}",
the pascalcase option is unfortunately not documented.
If that option wasn't available I would suggest this:
"${TM_DIRECTORY/.*\\/(.*)_(.*)$/${1:/capitalize}${2:/capitalize}/}",
the idea being to get the last directory in two capture groups, capitalize each and ignore the underscore separator (i.e., it doesn't appear in the transform part).
To generalize that, if you had other name separators in your directory name besides the underscore you could use this [_-] in that middle part - just include other possible separators.
Related
I want to create a task in .vscode/tasks.json where one of the args should be the name of the directory that contains the current file. For example, if I have the file folder1/folder2/myFile.txt open, I want to get the string folder2. As far as I can tell, none of the predefined variables gives me this. The closest is probably ${relativeFileDirname}, but that gives you the full directory path from the workspace folder , so it does not work for files deeper than one level in the file hierarchy.
If VSCode supported something like shell parameter expansion I could do with it, but since it does not I thought maybe I could use either a command variable or an input variable with "type": "command" in order to run a terminal command that gives me this (for example, in PowerShell it could be something like (Get-Item ${fileDirname}).Name). But I don't know how to do this, or if this is possible at all. Seems like something minor enough that should be possible to do without extensions, but maybe it's not.
I don't believe you can modify the built-in variables in a task, only use them as is or part of a string. But you can get other similar path variables through an extension called Command Variable that has many custom variables of the type you are looking for.
You indicated that extension.commandvariable.file.fileDirBasename will work for you.
I would like to exclude a few directories form error prone. I was trying to use a XepExcludedPaths flag but it seems that it works only for the one path which is a regular expresion of excluded location.
options.errorprone.errorproneArgs.add("-XepExcludedPaths:.*/legacy/model/.*")
works
options.errorprone.errorproneArgs.add("-XepExcludedPaths:.*/new/model/.*,.*/build/.*")
doesn't
Is it possible? I used wrong separator?
It's a single regular expression (literally compiled using Pattern.compile), so use a pipe instead of a comma:
options.errorprone.errorproneArgs.add("-XepExcludedPaths:(.*/new/model/.*|.*/build/.*)")
or
options.errorprone.errorproneArgs.add("-XepExcludedPaths:.*/(new/model|build)/.*")
I have an executable in a directory that is versioned, so the directory changes when the tool is updated.
The current command I run is the following:
.\packages\Chutzpah.4.1.0\tools\chutzpah.console.exe .\Tests\chutzpah.json
I want to do something like the following:
.\packages\Chutzpah**\tools\chutzpah.console.exe .\Tests\chutzpah.json
Windows command line doesn't like to expand wildcards but I'm hoping this is possible with powershell.
Simple answer here could be to use resolve-path which
Resolves the wildcard characters in a path, and displays the path contents.
So in practice you should be able to do something like this.
$path = Resolve-Path ".\packages\Chutzpah**\tools\chutzpah.console.exe" -Relative
& $path ".\Tests\chutzpah.json"
Note that Resolve-Path has the potential to match more that one thing.
Actually, Windows will expand the wild cards, but if the non-wildcard portion is not unique, you'll get the (I think) FIRST match.
So I think that really your problem is
"How do I tell which version I should be executing"
Which, if you have project files, etc., you might be able to extract from there.
In fact, you might well be wanting to extract something from the solution packages.config file, assuming that the .\packages\ prefix is there because you are wanting to run tests against files that are in a NuGet package.
Can you supply some more details?
EDIT:
OK, so you probably need to do something like System.IO.Directory.GetDirectories(path, pattern)
https://msdn.microsoft.com/en-us/library/6ff71z1w(v=vs.110).aspx
And depending on what you'd done with "Chutzpah" you'll get one or more matches that you could use to select the correct path.
I am using the xmlpoke task in nant and am looking for a way to use a wildcard when addressing the xml file. Right now I have a file path like project\appFiles\project{versionNumber}\fileToUpdate.xml, I would like to use a wildcard so its something like project\appFiles\project*\fileToUpdate.xml so I don't have to update the version number every time.
How do you get it to respect wildcards?
Looking all over the web, it doesn't look like this is possible, and by design. Like copy command (todir), the file path must point to a single file so no wildcards allowed (Found info on copy command, assuming same applies for XMLPoke, but could confirm exactly).
I ended up changing some design stuff so now the version number is easily calculated by the program calling the script, so passing in not an issue anymore.
I am quite stuck; I need to compress the content of a folder, where I have multiple files (extension .dat). I went for shell scripting.
So far I told myself that is not that hard: I just need to recursively read the content of the dir, get the name of the file and zip it, using the name of the file itself.
This is what I wrote:
for i in *.dat; do zip $i".zip" $i; done
Now when I try it I get a weird behavior: each file is called like "12/23/2012 data102 test1.dat"; and when I run this sequence of commands; I see that zip instead of recognizing the whole file name, see each part of the string as single entity, causing the whole operation to fail.
I told myself that I was doing something wrong, and that the i variable was wrong; so I have replaced echo, instead than the zip command (to see which one was the output of the i variable); and the $i output is the full name of the file, not part of it.
I am totally clueless at this point about what is going on...if the variable i is read by zip it reads each single piece of the string, instead of the whole thing, while if I use echo to see the content of that variable it gets the correct output.
Do I have to pass the value of the filename to zip in a different way? Since it is the content of a variable passed as parameter I was assuming that it won't matter if the string is one or has spaces in it, and I can't find in the man page the answer (if there is any in there).
Anyone knows why do I get this behavior and how to fix it? Thanks!
You need to quote anything with spaces in it.
zip "$i.zip" "$i"
Generally speaking, any variable interpolation should have double quotes unless you specifically require the shell to split it into multiple tokens. The internal field separator $IFS defaults to space and tab, but you can change it to make the shell do word splitting on arbitrary separators. See any decent beginners' shell tutorial for a detailed account of the shell's quoting mechanisms.