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)
Related
I am using Mac and
\usepackage{natbib}
It seems that the space in the path caused problems, i.e. Box Sync.
\bibliography{/Users/c082213/Box Sync/AA_My_Papers/MyStats.bib}
I have tried to put them in double "", and it doesn't work on Mac. Is there anyway that we can fix this?
Many thanks!
one solution is to use a relative path.
If the .bib and the .tex file are in the same folder you can just write:
\bibliography{MyStats}
On the other hand, there are many other possible solutions to handle the problem with with spaces in the path. My suggestion is: avoid it to name folders or files with spaces. It will produce problems for some reasons.
I had the same issue with Box and it's default usage of spaces, so I created a soft link having no spaces:
ln -s "Box Sync" Boxsync
then I can use the bibliography command as usual.
I'm trying to install a grunt template on my computer but I'm having issues. I realized that perhaps something different is happening because of the path given by the Grunt docs, which is
%USERPROFILE%\.grunt-init\
What does that . mean before grunt-init?
I've tried to do the whole import manually but it also isn't working
git clone https://github.com/gruntjs/grunt-init-gruntfile.git "C:\Users\Imray\AppData\Roaming\npm\gru
nt-init\"
I get a message:
fatal: could not create work tree dir 'C:\Users\Imray\AppData\Roaming\npm\.grunt-init"'.: Invalid argument
Does it have to do with this /.? What does it mean?
The \ (that's a backslash, not a slash) is a directory delimiter. The . is simply part of the directory name.
.grunt-init and grunt-init are two distinct names, both perfectly valid.
On Unix-like systems, file and directory names starting with . are hidden by default, which is why you'll often see such names for things like configuration files.
The . is part of a directory name. Filenames can contain . . The \ is a separator between directory names.
Typically, files or directories starting with . are considered "hidden" and/or used for storing metadata. In particular, shell wildcard expansion skips over files that start with ..
For example if you wrote ls -d * then it would not show any files or directories beginning with . (including . and .., the current and parent directories).
Linux hides files and directories whose names begin with dot, unless you use the a (for "all") option when listing directory contents. If this convention is not followed on Windows, your example is probably just a carryover.
It may well be something behind the scenes (later) expects that name to match exactly. While I like things, installers, for example, to just do what I said, I realize that keeping default value is the most tested path.
Directories starting with a dot are invisible by default on xNIX systems. Typically used for configurations files and similar in a users home directory.
\ before " has a special meaning on windows, the error is because windows won't let you create a file containing " as part of its name.
A Day with Winrar
All I wanted to do was exclude folders and their contents using wildcards, and even after reading the docs, it turned into a guessing game...
So my test bed looks like:
C:\!tmp1\f1
C:\!tmp1\f1\f1.txt
C:\!tmp1\f1\a
C:\!tmp1\f1\a\a.txt
C:\!tmp1\f2
C:\!tmp1\f2\f2.txt
C:\!tmp1\f2\a
C:\!tmp1\f2\a\a.txt
And I am executing:
C:\>"c:\program files\winrar\winrar.exe" a -r !tmp1.rar !tmp1
which gives me a rar with !tmp1 as the root (sole top level folder).
The exclude switch is -x<filepathpattern> and may be included multiple times.
So, given that we want to exclude f2, and all its subcontents...
-x*\f2\*
removes the contents, but leaves f2
-xf2
does nothing - includes all
-x\f2
does nothing - includes all
-x*\f2
does nothing - includes all (now I'm mad), so surely it must be..
-x\f2\
nope, does nothing - includes all. So it has GOT to be...
-x*\f2\
hell no, does nothing - includes all. and I already know that
-x*\f2\*
removes the contents, but leaves f2. Onward we go...
-x*f2\
does nothing - includes all. Grrrr. Aha! how about...
-x!tmp1\f2\
nope, does nothing - includes all. WTF. Alright, So it has GOT to be...
-x!tmp1\f2
Holy moly, it worked! Hmmm, then how come....
-x*\f2
does not work? This was the little demon that sent me down this crazed path to begin with and should have worked!
Given all that, do I dare try to go after */a/* directories, removing contents and the dirs?
-x*\a
does not work, of course, does nothing.
-x*\*\a
does not work, of course, does nothing.
-x!tmp1\*\a
nope. But...
-x*\a\*
removes contents of both dirs, but leaves the folders. So, in desperation I can use the -ed switch which will not store empty folders, but this is a broad hack, I want to eliminate the folders specified not all empty folders.
With my animosity growing toward winrar, I am passing the baton of information forward with an eye to that glorious day when we will know how to specifically exclude a folder and its contents using wildcards and not using the -ed switch.
(Quite old question but still may be relevant)
Maybe what you simply needed was this :
-x*\f2 -x*\f2\*
two exclude switches, should remove directory f2 and all its contents.
An even older question by now, but came across this question so I reproduced your folder structure and, at least nowadays (Winrar 5.11, not the latest but quite new), this works:
-x*\f2
So the whole command line is:
"C:\Program Files\WinRAR\Rar.exe" a -m5 -s !tmp1.rar !tmp1 -x*\f2
And this is what is stored in the .rar file:
!tmp1\f1\a\a.txt
!tmp1\f1\f1.txt
!tmp1\f1\a
!tmp1\f1
!tmp1
Similarly, if you use -x*\a, all a folders are excluded, storing this:
!tmp1\f1\f1.txt
!tmp1\f2\f2.txt
!tmp1\f1
!tmp1\f2
!tmp1
Finally, combining both parameters (-x*\f2 -x*\a), you get this:
!tmp1\f1\f1.txt
!tmp1\f1
!tmp1
To manage large list of files to be excluded, you can create text fie and write all excluded files/folders relative to the source folder:
1) create file list.txt, write the name of excluded files/folders
note: * refer to the source, all files/folders are relative to the source folder
*\f2
*\f3
2) Run the command
rar a -r -x#list.txt target.rar source-folder
I am trying to copy the contents of a log file to another log file using this command:
type \\server\f$\Test path\Test.log >> \\server2\f$\Logs\Testpath\Test.log
This has always worked in the path, but recently I have changed the location (path) to Test.log. The path is slightly longer. I now get an error:
The system could not find the file specified
I have googled this statement and the common responses are: 1) check the filename exists, 2) check the filename is not corrupt 3) Check the server is online.
I have done all of this. Is there a restriction on the number of characters a path can have? If there is then is there a workaround?
UPDATE 12/07/2012 09:49 GMT
Adding quotes around the path seems to resolve the problem. Why does adding quotes resolve the problem?
The problem was that the source path had a space in it. Adding quotes around the path resolved the problem.
Type is to examine a file, not to copy.
Also, if server is an actual server and not a folder, then you should be using two slashes (\server\share)
Example:
copy \\server\f$\Sourcepath\Test.log \\server2\f$\Logs\Destpath\Test.log /y
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds.mspx?mfr=true
How can I make Textmate always ignore the /log folder in the "Find in Project" search?
Add the log folder to the excludeInFolderSearch option in your ~/.tm_properties file, e.g.:
excludeInFolderSearch = "{$excludeInFolderSearch,$extraExcludes,log}"
I found a easier way to do it.
Go to Settings > Advanced > Folder References
And add |log| to the pattern.
valid for TextMate 1
Other answers did not work for me on TextMate 2.0-beta.12. After many frustrating attempts, this line was able to exclude the log, vendor, tmp and .git directories from fuzzy searching.
excludeInFileChooser = "{$excludeInFileChooser,log,vendor,tmp,.git}"
I added this line to a .tm_properties file in my project directory. I verified that this also works if you decide to put the .tm_properties in the home directory.
Edit:
Use excludeInFileChooser for modifying search paths in Textmate's "Go To File" navigation feature, which is activated by ⌘T.
Use excludeInFolderSearch for modifying paths when searching for text within the files of a directory, which is activated by either ⌘F or ⌘↑F
None of these worked for me. What worked was adding the following in a .tm_properties file (project root)
excludeDirectories = "{node_modules,}"
No $exclude variable. Add trailing comma.
For Textmate 2:
Click on the top menu Textmate, then Preferences.
Navigate to the second tab, called Projects.
On the "Exclude files matching" just add 'log' to the end of the list, for example:
{*.{o,pyc},Icon\r,CVS,_darcs,_MTN,\{arch\},blib,*\~.nib,tmp,log}
This should do it, the log folder should no longer be searched, or used as match when opening a file.
Use AckMate, https://github.com/protocool/AckMate and read hot to change the normal Find in Project Shift+Cmd+F here github.com/protocool/AckMate/wiki/Usage
Alternatively you could explicitly tell Mate to look at a specific subset of folders.
~/project/mate app db models
Project find will be restricted to those folders.
Or to just remove the log dir you could add an alias to ~/.profile:
alias m="ls | grep -v 'log' | xargs mate"
Just remove reference to log folder from project tree.
Also you may right click on *.log files and mark then as binary (they will not be searched).
http://wiki.macromates.com/Troubleshooting/FindInProject
For TextMate2 it should be: excludeDirectories = "{$excludeDirectories,log}"