In building a C++ project with the GNU tool chain, make tells me ~
src/Adapter_FS5HyDE.d:1: *** multiple target patterns. Stop.
Search, search, search, and I found out that make thinks that it has multiple targets because the path to my included headers has spaces in it. If you've got your headers stored in some sane place like C:\Program Files then you can take care of this by using the old DOS paths (e.g. C:\PROGRA~1). However, when you have your headers in a truly insane place like My Documents you can get around the problem with MY DOC~1 because there's still a space.
Any idea how to tell my compiler to look in My Documents for headers without make confusing the path as two objects?
(Note: Feel free to throw tomatoes at me for putting header files in My Documents if you'd like, but there is a little rationale for doing that which I don't feel like explaining. If the solution to this question is easy, I'd rather keep it the way it is.)
You can figure out what the old path is by doing a DIR /X in your command prompt.
Or, most of the time you can fake it with the first 6 characters - spaces + ~1 + extension (8.3 paths won't have spaces).
Or, you can use quotes: "C:\Documents and Settings\Administrator\My Documents".
I don't know about make specficially, but the normal way around this is to put quotes around the path i.e.
cd "C:\Program Files\"
does that work?
Side note: the short name (8.3) for the same folder might not be the same on different OS installations. Thus, you can't be sure that C:\Program Files will always be C:\PROGRA~1.
Short names can't contain spaces in them either, so the usual short name for My Documents is MYDOCU~1, not MY DOC~1.
You can find the exact short name for any folder or file (including My Documents) using dir /x <filename>.
If you are using the GNU toolchain from Windows command line (cmd.exe), you should be able to use quotes (") around the folder/file names to work around this problem.
For some folders, including My Documents, you can specify an alternative location. To do this, right-click the folder, select Properties, select Location tab, and away you go. I use this to put my downloads and music on another drive (D:).
Write a wrapper script (e.g. batchfile) to translate the path names to short form.
I have a script "runwin" that does stuff like this - instead of, e.g. gcc <args> I can call runwin gcc <args>;
runwin will make heuristic guesses as to which arguments are filename paths and translate them, then call gcc on the resulting string of arguments.
Related
I start to work on a huge project with tones of C and C++ files, already wrote by someone else.
Is there any faster/simpler ways to find in what file any macro or function is define other than a grep -r ? It is kind of long.
In some IDE there is this magical thing like right click and "go to definition". But I'm currently using emacs. I don't know if there is any customisation that can do this ?
Each time, I have to copy past the name in my terminal, run a grep and re copy past the file path in my emacs. (And you know, I am lazy...)
CTags. You can try using Ctags with emacs and it will help you to navigate to the function declaration directly. For its usage, please refer to https://www.emacswiki.org/emacs/EmacsTags
You can also explore Cscope, It has a better feature set than ctags which works directly on pattern recognition. But sometimes, you just need to navigate through code and more often than not ctags does the job.
Each time, I have to copy past the name in my terminal, run a grep and re copy past the file path in my emacs.
You can improve on this by using M-x rgrep inside Emacs. It asks for the regular expression, a glob pattern of files to look in, and a directory to start in. It then does a recursive grep, outputs the results in a buffer, and you can jump directly from the hits to the corresponding file.
For the glob pattern, you could type something like *.c, or you could use one of the aliases defined in the variable grep-files-aliases. For example, ch is equivalent to *.[ch] (C source and header files) and cchh is equivalent to *.cc *.[ch]xx *.[ch]pp *.[CHh] *.CC *.HH *.[ch]++ (C++ source and header files).
You might find that this works well enough that you don't need ctags and other tools suggested in the other answers and comments.
For ease of finding function definitions in C, some projects use the convention that the function name in the definition starts in the first column:
/* this is just a declaration */
int main(int argc, char *argv[]);
/* in the definition, the function name starts on its own line */
int
main(int argc, char *argv[])
{
...
That means that you can find the definition, excluding any calls to the function, with the regex ^main.
grep should be really fast if you limit the search to the directories and file types (generally .h and .hpp) that are likely to contain it. For example if you know it is in your application just search there, if you know it's from FreeType (generally FT_*) search there.
More RAM will help the system cache files better, and if your on a HDD best to get an SSD. If your working directly on a VM, especially one with remote disks, if can work locally that will often be faster.
Otherwise many fully functional IDE's (Visual Studio, XCode, Eclipse, etc.) have C++ integration to keep track of these things, and will for example offer a "Go to declaration" and "Go to definition" option as a shortcut or context menu when over a symbol.
How can I list only files, but not directories using list.files (not recursively)? It has an include.dirs argument, but this is ignored when not being used recursively.
I had been thinking something like
list.files(path=myDir, pattern="[^/]$")
but that doesn't seem to work, or a few variations on it. Is there a regex that I can plug in here or a function. I know I can do list.dirs and take a setdiff, but this is already slow enough, I want this to be quicker.
PS: currently on linux, but need something that works cross-platform.
PPS: file.info is really slow, so I think that is also not going to work.
PPPS: It doesn't need to be list.files, that is just the function I had thought should do it.
Consider this regex pattern that matches any file containing letters or numbers and contains the dot extension (to leave out subdirectories but unfortunately files without extensions):
# WITH ANCHORING
files <- list.files(path, pattern=("[a-zA-Z0-9]*[.][a-zA-Z0-9]*$"))
# MATCHING LETTER AND/OR NUMBER FILES WITH EXTENSION
files = list.files(myDir, pattern=("[a-zA-Z0-9]*[.]"))
# WILDCARD FILE MATCHING WITH EXTENSION
files = list.files(myDir, pattern=("*[.]"))
Some other regex variations to catch files with periods (note these also get directories with periods and miss files with no extensions)
list.files(pattern="\\..+$")
list.files(pattern="\\.[[:alnum:]]+$")
And using system2 with ls seems to work pretty well (thanks #42- as well from comments),
system2("ls", args=c("-al", "|", "grep", "^-"))
should get only regular files (including ones without extensions), or
system2("ls", args=c("--classify"))
should return files with directories having a "/" appended so they can be determined.
For an alternative open-source solution, consider the Python solution that allows you to condition if item is a directory and using os.path.join() is agnostic to any OS platform.
import os
files = [f for f in os.listdir(myDir) if os.path.isfile(os.path.join(myDir, f))]
We can search files in windows 7 or higher version using the following tool:
(I don't have image uploading privilage. I mean the top-right area in windows file explorer.)
When I search for MATLAB files using "*.m", it not only returns *.m files, but also returns *.mp3, *.mp4 files. Is there any way to show *.m files exclusively?
Thanks!
I assume you used the quotation marks here to show the text you typed, because ironically the exact way how it should work is to put the search in quotation marks...
so
*.m
finds .mp3 as well as .m but
"*.m"
should only find the .m files. Alternatively you could also write
ext:".m"
which would guarantee that only extensions are searched. (Although I am not sure if this is ever necessary here, because while windows can have a dot in the filename and also can have files without extensions I am not sure if it is possible to have both at the same time.)
using the following
"*.m"
will solve your problem.You can find more information on regex to be used in msdn in the following link .Advanced query syntax
Above that, you can also take advantage of the wildcard character *.
For example, if you want to search for a file with a name ending with 024 or starting with 024 then you can put in the search box like *024.* or 024*.* respectively.
Here the * after . represents files with any extensions, if you want particular then mention extension line 024.png.
Explorer don't have a function of finding with RegEx.
You need to use Power-Shell instead of Win Explorer;
for example: where '(?i)Out' is a regex
Get-ChildItem -Path e:\temp -Recurse -File | Where-Object { $_.Name -match '(?i)Out' }
alternatively you can just simply search for your extension like this:
.extension
eg:
typing .exe will give you all the files with .exe extensions in a folder.
PS: Typing .xml OR .vmcx will give you both type of files. It is useful if you seek to make an archive of different kinds of files stored in different folders or locations.
You can get close to proper regex support from the mostly awesome Cygwin, and as a bonus you get most every linux tool running natively on linux. But it still doesnn't know that .* means "zero or more of anything", ^ means the start of a line (and $ the end), so some things are still weird.
And a startlingly large bunch of weird corner cases that only deranged perl programmers notice fail the test.
So many other things it gets wrong, but it's more workable than anything in any windows OS, plus you get perl, grep, diff, wget, curl, etc. -- the whole GNU lib for free.
If you want a full on bash shell with proper respect for regex, install the super neet-o Bash for Windows 10
Either will do what you want. And they're a billion times faster than that stupid search bar that takes off at 100 mph then crawls to 1 pixel per 10 minutes near the end.
I've tried a bunch of different methods.
1.
*
!.gitignore
!./src/com/AleXander/*
2.
/*
!.gitignore
!src/com/Alexander/*.java
3.
*
!.gitignore
!./*.java
as well as multiple other variations of this. I came across this question that looks like it's using Regex. Is regex needed for this to work? Any ideas?
I also tried these regex patterns but I am not the best at regex.
1.Logic: ignore all files ending with the file extension pattern "java"
*
!.gitignore
!*.[^java$]
2.Logic: ignore all files ending with a "j" followed by an "a" with anything else after that.
*
!.gitignore
!*.j[^a]*
Ignoring * is a bad idea.
This will ignore every file and every directory in every part of your repository.
Especially git will not look at all at ignored directories. Therefore the exceptions you define later will have no effect at all.
There are quite longish include/exclude hacks to make something like this work, but usually the best way is to just explicitly ignore the files you want to ignore and avoid any exceptions whenever possible.
If you feel the need for some more complicated ignore rules this is usually an indicator that your repository layout needs a better structure.
A user input string for a destination path can potentially contain spaces or other invalid characters.
Example: " C:\users\username\ \directoryname\ "
Note that this has whitespace on both sides of the path as well as an invalid folder name of just a space in the middle. Checking to see if it is an absolute path is insufficient because that only really handles the leading whitespace. Removing trailing whitespace is also insufficient because you're still left with the invalid space-for-folder-name in the middle.
How do i prove that the path is valid before I attempt to do anything with it?
The only way to "prove" the path is valid is to open it.
SHLWAPI provides a set of path functions which can be used to canonicalize the path or verify that a path seems to be valid. This can be useful to reject obviously bad paths but you still cannot trust that the path is valid without going through the file system.
With NTFS, I believe the path you give is actually valid (though Explorer may not allow you to create a directory with only a space.)
The Boost Filesystem library provides helpers to manipulate files, paths and so... Take a look at the simple ls example and the exists function.
I use GetFileAttributes for checking for existence. Works for both folders (look for the FILE_ATTRIBUTE_DIRECTORY flag in the returned value) and for files. I've done this for years, never had a problem.
If you don't want to open the file you can also use something like the access() function on POSIX-like platforms or _access() and friends on Windows. However, I like the Boost.Filesystem method Ricardo pointed out.