I wish to be able to run a query like the following:
wmic path Win32_Service where "DisplayName like 'FooBarService % (X, Y)'" get *
But, it doesn't work because of the comma inside the like string. The error I get is "Invalid Verb." I tried escaping it with a backslash, and I tried escaping it using brackets as underscores are meant to be escaped, and both resulted in the "Invalid Verb." error.
As a less-than-ideal workaround, I can replace the commas with underscores, and it works, but the underscore will match any single character rather than just the comma, so I'd rather find a way to escape the commas.
Is there a way to escape the comma like in this example?
One way I have found to include a comma in the like clause is to place the entire where expression in parentheses. Unfortunately, I also found that this means I cannot include a close paren in the string at the same time (but an open paren is okay). I experimented with the /trace:on option to see what was going on under the covers a little bit and it helped me find a couple things the program accepts:
Here is an example I got to work with a comma, but it apparently cannot contain a close paren:
C:\> wmic /trace:on path Win32_Service where (Description like '%(%, %') get DisplayName
And here is an example I got to work with both open and close parentheses, but apparently it cannot contain a comma (obviously, this is quite similar to your original example):
C:\> wmic /trace:on path Win32_Service where "Description like '%(TAPI)%'" get DisplayName
It seems like the parser just isn't complex enough to handle these cases, but with tracing on, you can see the WMI Win32 functions that it uses, so maybe you could write your own program that uses the functions directly. I think IWbemServices::ExecQuery is capable of what you're looking to do.
Related
I have a string in the format of "c:\replaceallslashes\directory1\subdirectory1\etc\etc\file.html" in a large number of files. All the backslashes in these strings need be changed to forward slashes so that the path can become a URL. I want to change this via find & replace in a text or regex editor, but don't want to accidentally replace any backslashes outside the string that may occur in the documents.
How should I construct the find and replace command?
Edit: just to be clear, I am looking for regex strings for both the "find" and "replace" fields. The answer below only gives the "find" command.
A very rudimentary Windows path regex would look something like:
[a-z]:\\(?:[a-z0-9_-]+\\?)*
https://regex101.com/r/g1hubs/1
The issue is that Windows filenames are only restricted from using \/:*?"<>| so there's only a small fraction of chars which tell you that something is definitely not a path. So my example assumes that you only have alphanumeric paths which may or may not include underscores and dashes.
I have written a program that searches for 'opens' without matching 'closes' in a target file. It produces an output like this:
open
close
open
open
close
In this example here the second 'open' is not immediately followed by a matching 'close', so I consider that an error. My text-editor (editpad) has a regular-expression search/replace feature, which I would like to use to get rid of all correct pairs, so I can notice easily the incorrect situations. I tried replacing the following
open\r\nclose
I thought that this would match the two words and the line-break between them (I'm using Windows). This did not work.
Does anyone have an idea why it didn't?
If you select the Regex mode, your regex will work, but I also suggest making \r optional by appending ? after it to support LF endings, too:
open\r?\nclose
See the screenshot with settings and proof it works in EditPad:
I'm trying to find all instances of a Twitter handle, and wrap an anchor tag around them.
:%s/\(#[\w]\)/<a href="http://www.twitter.com/\1">\1<\/a>/gc
Which gives me:
E488: Trailing characters
If you have this when replacing within a selected block of text, it may be because you mistakenly typed %s when you should only type s
I had this happen by selecting a block, typing : and at the prompt :'<,'>, typing %s/something/other/ resulting in :'<,'>%s/something/other/ when the proper syntax is :'<,'>s/something/other/ without the percent.
When the separator character (/ in your case) between {pattern} and {string} is contained in one of those, it must be escaped with a \. A trick to avoid that is to use a different separator character, e.g. #:
:%s##\(\w\+\)#\0#gc
PS: If it should do what I think it should do, your pattern is wrong; see my correction.
I had this issue and couldn't make it go away until I found out that the .vimrc file that I had parts that I copied from else where that contained abbreviations, like this for example:
abbrev gc !php artisan generate:controller
That abbreviation would mess up my search and replace commands which usually look like this:
:%s/foo/bar/gc
by expanding that gc into !php artisan generate:controller, except, that it wouldn't do it on the spot/ in real time. The way that I clued in was by looking through the command history (by pressing : and the up arrow) and seeing
:%s/foo/bar/!php artisan generate:controller
So if you're getting trailing character errors no matter what you do I'd look inside
~/.vimrc
and see if you can find the problem there.
I had the same problem.
Only using other delimiters didn't help. So, additionally
I didn't select any row.
And didn't use g for global.
so just
:%s#to_be_replaced#replacement#
did the job. Changed all occurrences of 'to_be_replaced' with 'replacement'.
:%s/\/apps/log_dir/g
where string to replace=/apps
and replaced string=log_dir
as we saw / so we need to use "\/"
This is how I caused my "E488: Trailing characters"
Occasionally the muscle memory in my brain skips a beat as it did today causing me to seek the reason for my E488: Trailing characters.
:%s/searchItem/changeTo/s
The s at the end caused my E488: Trailing characters.
I should have used a g
:%s/searchItem/changeTo/g
Placing the g at the end worked as always.
I need to be able to handle data that can look like:
set setting1 "bind button_x +actionslot1;bind button_y \" bind button_x +stance \" "
bind button_a jump
set setting2 1 1 0 1
toggle setting_3 " \"value 1\" \"value 2\" \"value 3\" "
These are what some of the commands for the console of a game look like, and I'm trying to write an emulator of sorts that will interpret the code the same way the game will.
The first thing that comes to mind is regex, but I'm not sure it's the best option. For example, when matching for the value of a setting, I might trying something like /set [\w_]+ "?(.+)"?/, but the wildcard matches the ending quote because it's not lazy, but if I make it lazy, it matches the quote inside the value. If I make it greedy and stop it from matching the quotes, it won't match the escaped quotes in the values.
Even if there are possible regex solutions, they seem like the wrong option. I had asked before about how programs like Visual Studio and Notepad++ know which parentheses and curly braces matched, and I was told there was something similar to regex in some ways but much more powerful.
The only other thing I can think of is to go through the lines of code character by character and use booleans to determine that state of the current character.
What are my options here? What do game developers use to handle console commands?
edit: Here's another possible command which strongly deters me from using regex:
set setting4 "bind button_a \" bind button_b "\" set setting1 0 \" " \" "
The commands include not just escaped quotes, but quotes of the manner "\" inside escaped quotes.
I would suggest you read about Lexical Analysis
, this is the process of tokenizing your text using a grammar.
I think it will help you with what you are trying to do.
I don't want to keep you on the path of regex -- you are correct that there are non-regex solutions that may be more appropriate (I just don't know what they are). However, here is one possible regex that should fix your quotes issue:
/set [\w_]+ "?((\\"|[^"])+)"?/
I changed .+ to (\\"|[^"])+. Basically it's matching occurrences of \" OR of anything that isn't a quote. In other words, it will will match anything except quotes that aren't escaped.
Again, if someone can suggest a more sophisticated non-regex solution, you should strongly consider it.
Edit: The updated example you've provided breaks this solution, and I think it would break any regex solution.
Edit 2: Here is a C# string version of your regex. It uses # to tell the compiler to treat the string as a verbatim literal, which means it ignores \ as an escape character. The only caveat is that in order to represent " in a verbatim literal you have to type it as "", but it's still better than having slashes everywhere. Given the prevalence of escape sequences in regexes, I recommend using verbatim literals anywhere that you have to type a regex in a string.
string pattern = #"set [\w_]+ ""?((\\""|[^""])+)""?"
I'm trying to use emacs' customize-group packages to tweak some parts of my setup, and I'm stymied. I see things like this in my .emacs file after I make changes with customize:
'(tramp-backup-directory-alist (quote (("\\\\`.*\\\\'" . "~/.emacs.d/autobackups"))))
This was the result of putting the following into the customize text field:
Regexp matching filename: \\`.*\\'
This is a representative sample: I'm actually trying to change several things that want a regexp, and they all show this same problem. How many layers of quoting are there, really? I can't seem to find the magic number of backslashes to get the gosh-dang thing to do what I'm asking it to, even for the simplest regular expressions like .*. Right now, the given customization produces - nothing. It makes no change from emacs' default behavior.
Better yet, where on earth is this documented? It's a little difficult to Google for, but I've been trying quite a few things there as well as in the official documentation and the Emacs wiki. Where is an authoritative source for how many dang backslashes one needs to make a regular expression in customize-mode actually work - or at the very least, to fail with some kind of warning instead of failing silently?
EDIT: As so often happens with questions asked in anger, I was asking the wrong question. Fortunately the answers below, led me to the answer to the question that I needed, which was about quoting rules. I'm going to try to write down what I learned here, because I find the documentation and Googleable resources to be maddeningly obscure about this. So here are the quoting rules I found by trial and error, and I hope that they help someone else, inspire correction, or both.
When an emacs customize-mode buffer asks you for a "Regexp matching filename", it is being, as emacs often is, both terse and idiosyncratic (how often the creator's personality is imparted to the creation!). It means, for one thing, a regexp that will be compared to the whole path of the file in search of a match, not just to the name of the file itself as you might assume from the term "filename". This is the same sense of "filename" used in emacs' buffer-file-name function, for example.
Further, although if you put foo in the field, you'll see "foo" (with double-quotes) written to the actual file, that's not enough quoting and not the right quoting. You need to quote your regexp with the quoting style that, as far as I can tell, only emacs uses: the ``backtick-foo-single-quote'`scheme. And then you need to escape that, making it \`backslash-backtick-foo-backslash-single-quote\' (and if you think that's a headache to input in Markdown, it's more so in emacs).
On top of this, emacs appears to have a rule that the . regexp special character does not match a / at the beginning of filenames, so, as was happening to me above, the classic .* pattern will appear to match nothing: to match "all files", you actually need the regexp /.*, which then you stuff into the quote format of customize-mode to produce \`/.*\', after which customize paints another layer of escaping onto it and writes it to the customization file.
The final result for one of my efforts - a setting such that #autosave# files don't gunk up the directory you're working in, but instead all live in one place:
(custom-set variables
'(auto-save-file-name-transforms (quote (
("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "~/.emacs.d/autobackups/\\2" t)
("\\`/.*/\\(.*?\\)\\'" "~/.emacs.d/autobackups/\\1" t)
))))
Backslashes in elisp are a far greater threat to your sanity than parentheses.
EDIT 2: Time for me to be wrong again. I finally found the relevant documentation (through reading another Stack Overflow question, of course!): Regexp Backslash Constructs. The crucial point of confusion for me: the backtick and single quote are not quoting in this context: they're the equivalent of perl's ^ and $ special characters. The backslash-backtick construct matches an empty string anchored at the beginning of the string being checked for a match, and the backslash-single-quote construct matches the empty string at the end of the string-under-consideration. And by "string under consideration," I mean "buffer, which just happens to contain only a file path in this case, but you need to match the whole dang thing if you want a match at all, since this is elisp's global regexp behavior."
Swear to god, it's like dealing with an alien civilization.
EDIT 3: In order to avoid confusing future readers -
\` is the emacs regex for "the beginning of the buffer." (cf Perl's \A)
\' is the emacs regex for "the end of the buffer." (cf Perl's \Z)
^ is the common-idiom regex for "the beginning of the line." It can be used in emacs.
$ is the common-idiom regex for "the end of the line." It can be used in emacs.
Because regex searches across multi-line bodies of text are more common in emacs than elsewhere (e.g. M-x occur), the backtick and single-quote special characters are used in emacs, and as best as I can tell, they're used in the context of customize-mode because if you are considering generic unknown input to a customize-mode field, it could contain newlines, and therefore you want to use the beginning-of-buffer and end-of-buffer special characters because the beginning and end of the input are not guaranteed to be the beginning and end of a line.
I am not sure whether to regret hijacking my own Stack Overflow question and essentially turning it into a blog post.
In the customize field, you'd enter the regexp according to the syntax described here. When customize writes the regexp into a string, any backslashes or double-quote chars in the regexp will be escaped, as per regular string escaping conventions.
So in short, just enter single backslashes in the regexp field, and they'll get correctly doubled up in the resulting custom-set-variables clause written to your .emacs.
Also: since your regexp is for matching filenames, you might try opening up a directory containing files you'd like to match, and then run M-x re-builder RET. You can then enter the regexp in string-escaped format to confirm that it matches those files. By typing % m in a dired buffer, you can enter a regexp in unescaped format (ie. just like in the customize field), and dired will mark matching filenames.