I am currently trying to copy a subset of regex (also known as regular expressions) library and its dependencies so I can bring it to school to work with. I could be using Microsoft's regular expressions from the C++11 standard library, but my school's computers do not support the C++11 library.
Anyways, to make this possible, I have compiled the bcp tool successfully and I have typed
bcp boost/regex.hpp <my destination folder> on my command prompt window.
The problem is that I get the following error:
**** exception(205): std::runtime_error: Found a closing ) with no corresponding openening parenthesis. The error occurred while parsing the regular expression fragment: "?+(([(<].*HERE>>>)?$)?".
Any kind of advice would be appreciated.
Very peculiar. The quoted code has an OPENING ( with no corresponding closing parenthesis. Try escaping the open parenthesis with a slosh \:
"?+(([\(<].*HERE>>>)?$)?"
This would not alter the regular expression, but may help the parser.
Related
I've built bcp on windows with VS14.1 and no matter what I do I keep getting the following error:
std::exception Found a closing ) with no corresponding openening parenthesis. The error occurred while parsing the regular expression fragment: '?+(([(<].*>>>HERE>>>)?$)?'.
I tried escaping slashes via double slashes, absolute path, etc, but none of them seems to work. My boost version is 1.66
./bcp.exe D:/boost/boost_1_66_0_precompiled/boost/shared_ptr.hpp D:/boost/boost_1_66_0_precompiled
./bcp.exe D:\\boost\\boost_1_66_0_precompiled\\boost\\shared_ptr.hpp D:\\boost\\boost_1_66_0_precompiled
./bcp.exe boost/shared_ptr.hpp extract
Funnily enough, when I deliberately add a wrong directory, it shows "Destination path does not exist" instead.
I have Geany 1.27 installed in my Ubuntu 14.04 (Trusty Tahr). But I also have Windows 7 OS with Geany 1.28 installed.
In both these versions of Geany, when I try to find a string into a multiple files or folder with file-type filter of "phtml" or "php", I see that when my search string includes ( or ) (for example, function new() the search fails.
Now I have a slight idea that this could be due to un-escaped bracket in string acting as part of Regex in grep command. Am I right?
How can I overcome the unescaped characters in search string when searching in Geany? In both Ubuntu and Windows Geany if the method could be different.
Ensure you properly escape your braces, as depending on options, you have set the regular expression is used for searching.
Your function search would be something like new\(\). The documentation is more detailed.
I have the following regex that works with the .NET regex engine (FYI, what this does is to parse command line arguments of the form name="value1,value2" name2 = value3 where the quotes are optional)
(?<name>[^=]+)=?((?<quoted>\""?)(?<value>(?(quoted)[^\""]+|[^,]+))\""?,?)
and want to use this in C++ 11. However, I understand that there are no named groups or conditions(? not entirely sure) in C++'s regex syntax.
I'm asking this question here because I haven't found any tools/web pages where I can easily test a regex and have it work in C++ 11 (whereas there are tools for almost all other platforms). A link to an online (or offline) C++ 11 compatible regex tester tool that can show me groups, subgroups and display helpful error messages would also be an acceptable answer.
PS: I understand that command line parsing is an exercise best suited to a parser but I have been using this simple regex long enough without any issues for most of my command-line tools that I am ok with any drawbacks it may have.
The support for regex in C++11 is still sketchy, for example gcc will have good regex support only in version 4.9. You haven't specified what's your environment, but you can find details about what's supported and what's not in this question.
Your best bet is using the boost regex library - you should read Understanding Marked Sub-Expressions and Captures.
To make it a bit easier for you to test and experiment, as you requested, here's a ready environment that adapts the example from the boost article, with the right compilation flags g++-4.8 -O2 -Wall -pedantic -pthread -DBOOST_REGEX_MATCH_EXTRA main.cpp -lboost_regex set up: http://coliru.stacked-crooked.com/a/8950eb9c097b0db1
I'm attempting to build/install/use the Poco C++ Libraries. I'm running Ubututu (Natty). I've compiled the static libraries which are working fine, but when I set the env var PROJECT_BASE to a path containing spaces, I get errors:
make
/bin/sh: Syntax error: Unterminated quoted string
/bin/sh: Syntax error: Unterminated quoted string
/home/username/Documents/poco-1.4.1p1/build/rules/global:62: *** Current working directory not under $PROJECT_BASE. Stop.
I've set PROJECT_BASE to:
/files/Dropbox/Myname\'s\ Work/C++\ Work
which I believe should be escaped correctly? Adding a trailling backspace gives me the alternate error of:
make
/bin/sh: Syntax error: Unterminated quoted string
awk: line 1: runaway string constant "/files/Dro ...
/home/username/Documents/poco-1.4.1p1/build/rules/global:62: *** Current working directory not under $PROJECT_BASE. Stop.
I might be missing something basic, but I've been wrestling for a few days now to get the Poco C++ Library build system set up how I want it to no avail :S I know the README said something about SYMBLINKS screwing up the PROJECT_BASE, but I'm no using any :S /files is an ext4 mount (same hdd, seperate partition) if that's relevant at all.
Thanks for your help!
For anyone else getting the: "* Current working directory not under $PROJECT_BASE. Stop." error, I found a solution that maybe sounds obscure.
Basically, if any of the parent directories are symlinks, it will generate this error.
IMPORTANT: Make sure that the path to the build directory does not
contain symbolic links. Furthermore, on Mac OS X (or other systems
with case insensitive filesystems), make sure that the characters in
the path have the correct case. Otherwise you'll get an error saying
"Current working directory not under $PROJECT_BASE.".
http://pocoproject.org/docs/00200-GettingStarted.html
In my case, I was compiling the library 5 levels deep and the second directory was a symlink. Changing it to a directory resolved the issue.
HTH
It requires great care and deliberate effort to make systems such as makefiles handle pathnames with spaces accurately. It can be done; it is not trivial. It is fairly clear that this package has not been so modified; it is like the majority of such packages.
If you really want to make life hell for yourself, use a pathname such as:
/home/mine/He said, "Don't do it!"/poco-1.4.1
Spaces, single and double quotes -- at least it doesn't include backquotes, dollars, parentheses, newlines, etc.
In the meantime, bow to the inevitable - use a pathname without spaces etc in it.
If your problem is not with symlinks, as in my case, you probably are not specifying a full path, but instead a relative one, as indicated in the following blog post.
http://fatalfeel.blogspot.com/2013/09/poco-with-cocos2d-in-android-and-ios.html
What is a regular expression I can use in Vim to find conflicts in CVS and possibly other version control systems?
Here is a regular expression to find entire conflict sections:
[<]\{7}.*\_.\{-}[=]\{7}\_.\{-}[>]\{7}.*
And to search for that in vim, just press the '/' key and paste that regular-expression string, then press enter.
Usually CVS conflicts look like this:
<<<<<<< file.c
Code from file.c
=======
Code from the repository version 1.2
>>>>>>> 1.2
Vim search-and-replace command to keep local version:
:%s/[<]\{7}.*\n\(\_.\{-}\)[=]\{7}\_.\{-}[>]\{7}.*\n/\1/g
Vim search-and-replace command to keep repository version:
:%s/[<]\{7}.*\_.\{-}[=]\{7}\n\(\_.\{-}\)[>]\{7}.*\n/\1/g
I usually just do /<<< and press 'n' until I find no more matches. It is a much less sophisticated approach than Neil's, but it works for me :)