I have a job using get ftp files, i am using this wildcard to fetch all the xml.zip files
.*.zip
Works ok, but downloads all the files. I tried a wildcard to download only files with this pattern: .outsideXXXXXX.xml.zip (with no success).
.outside\*.zip
What i am doing wrong?
Finally i found the solution:
.outside.*\.zip
FYI: pentaho pdi regexp are based on java.util.regex package. The exact syntax for creating regular expressions is defined in the java.util.regex.Pattern javadoc.
https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html
Notice a difference between outside*\\.zip (correct) and .outside\\*.zip (incorrect)?
You need to escape ".", NOT the "*"
Related
I have a few lines of configurations that I need in my rsyslgog.
if $programname == 'project' then /var/log/file.log
When added to the end of the main rsyslog configuration file, /etc/rsyslog.conf, this configuration appears to be valid and functional.
However, when using the rsyslog.d directory I get a syntax error.
error during parsing file /etc/rsyslog.d/project.conf, on or before line 2: syntax error on token '==' [v8.32.0 try http://www.rsyslog.com/e/2207 ]
Is there anything in the main config that has to be parsed in advance, or is this a bug that should be reported to Fedora 27 developers?
As rsyslog author, I would assume that there is some include right in front of it that somehow renders your (valid) construct invalid. Red Hat unfortunately tends to stick to obsolete legacy format, and things like these can easily happen when this is used (after all, this was why we obsoleted it).
To hunt this down, I would check the config include that is included immediately in front of your own. If included via wildcards, the include order is sorted by filename.
Sorry, it was my bad. The configuration for my rsyslog config file was rewritten by my installer bash script, and that interpreted the $ sign as variable within the string. I should have double-checked the correctness of my config file.
am trying to extract to use all my box file to extract characters and when i try this line
unicharset_extractor *.box
it gives me an error that it cannot find *.box instead of loading all box files.
That specific program does not support such syntax. You have to chain the names of all the box files and feed to it, such as:
unicharset_extractor lang.fontname.exp0.box lang.fontname.exp1.box ...
You can write a script (e.g., train.ps1) to automate the process.
http://code.google.com/p/tesseract-ocr/wiki/TrainingTesseract3
I finally made my own tool for that .
[link]http://code.google.com/p/serak-tesseract-trainer/
In Ruby, how can I check if a file exists using a wildcard?
Apparently this does not seem to work:
File.exists?("/folderOfFile/Filename*.ext")
Your wildcard would refer to a set of files, not a single file. You could use Dir::glob for this:
!Dir.glob('/folderOfFile/Filename*.ext').empty?
I have added a include directory in my home directory. I can run "ls -l ~/include" from the build directory.
I have added that directory in both "Header Seach Path" and in "User Header Search Path". In both places I have tried with both non-recursive and recursive.
But xcode 4.5.1 can not in any situation find the first stated header file.
It is stated in source code calls.m as:
#include <directory/file.h>
I get a "Lexical or Preprocessor issue 'directory/file.h' file not found."
But when running xcodebuild from cli it has no problems what so ever to build the source.
I have tried many of the suggestions found on internet
Putting a include in /usr/ om my drive
Adding a index to the project, adding files with no copy and no "Add to target" marked.
Restart xcode.
Specifying all specific paths.
But still no go.
What is the problem. Bug´s in xcode?
I just had a similar issue, and it was because there were spaces in the path which I defined for the Header Search Path. For example, I was defining the following as a search path:
$(SRCROOT)/Frameworks/Headers
which was being expanded out to the following:
/Users/skoota/Documents/Xcode Projects/My App/Frameworks/Headers
as you can see, there are spaces within the path (which are not immediately evident, as you are using the $(SRCROOT) variable) and the compiler doesn't particularly appreciate the spaces. I solved this problem by changing the search path to this:
"$(SRCROOT)"/Frameworks/Headers
(note the quote marks around $(SRCROOT) which escapes the spaces). This now expanded out to:
"/Users/skoota/Documents/Xcode Projects/My App"/Frameworks/Headers
which works perfectly, although looks a bit odd with the embedded " marks. This took me a while to figure out, so hopefully it helps!
This usually happens if there are spaces in your directory's path. To overcome this problem, use double quotes around the path.
Suppose you want to use your project directory, then you should use: $PROJECT_DIR. Enable recursive if you want to search within the folders as well. Alternatively, you can use $(SRCROOT)
Okay guys, you're my only help :)
I have GVim v. 7.3, Exuberant CTags 5.8, omnicppcomplete (0.41) - all latest, to be exact.
I'm trying to generate tags to use in VIM, but it seems to totally ignore data in tags file.
I've used ctags to generate tags file for bada framework - the file seems to be okay, class definitions present etc. I also tried to apply the same command to STL from Visual Studio.
ctags -R --c++-kinds=+p --fields=+iaS --extra=+q --language -force=C++ "c:\bada\1.0.0\Include\"
Also, I've mapped generating tags via hotkey.
map <C-F12> :!ctags -R --c++-kinds=+p --fields=+iaS --extra=+q .
Trying to use any of files generated by these commands did not succeed.
The command :tags shows empty tag list, but doesn't give any error, and I have no clue how to fix this.
Yes, seems that vim actually handles spaces in a weird way (Windows only?), however there are workarounds: either use dos 8.3 short names or use a wildcard instead of a space (?), like
set tags=c:\program?files?(x86)\vim\tags
PS: which tag files was successfully loaded could be checked with the
:echo tagfiles()
command
The problem was with path to tags file: c:\Program Files\Vim\bada. The VIM didn't want to parse string with spaces no matter what the slashes/backslashes used.
Reinstalling VIM to c:\VIM solved the problem.