UNIX file name can generally consist of octets (8-bit bytes), except for 0x00 (NULL) and 0x2F (/). Every other octet is valid. This includes such nice things as 0x0A (newline).
Your find example will handle file names with weird characters such as newline correctly.
Your find | grep example will give odd and incorrect results when faced with such a thing (it'll see one file called "line 1\nline 2" as two files).
You can use find -print0 | grep -z (if you're using GNU versions, e.g., on Linux); that'll preserve correctness. It'll use a little more memory. Note that you can tell find to use extended regular expressions (for example) using the -regextype option.
If you want to do some really complicated matching, you may like the find2perl script, which will convert a find command line in to a short perl program you can then edit to add in the complexity.
Finding with ls: first things first, ls | grep cisco is a bit verbose, since cisco isn't a regular expression. Try:
ls *cisco*
Using find: along the same lines, -regex is overkill with a simple, static pattern. How about:
find -name '*cisco*'
The quotes are required so the glob is interpreted by find, not the shell. Also, -print is required for many versions of find, but is optional (and the default predicate) for others (e.g. GNU find). Feel free to add it if you need it.
If you need to search for ‘cisco’ in the full pathname, you could try this:
find -path '*cisco*'
which is equivalent to find | fgrep cisco.
Using find with regular expressions: let's do that anyway, since this is what you want. Shamelessly copying from the GNU find manpage:
-regex pattern
File name matches regular expression pattern. This is a match
on the whole path, not a search. For example, to match a file named
`./fubar3', you can use the regular expression `.*bar.' or `.*b.*3',
but not `f.*r3'.
What this means is that your regular expression is wrapped in an invisible ^...$, so it must match every character in the full pathname of the file. So, as nwildner and otokan said in the comments, you should use something like:
find -regex '.*cisco.*'
And you don't even need the -regextype for something this simple.
Best Answer
Looking at Dolphin with Baloo specifically, it seems to look up the metadata of every file in its search domain, even if you're doing a simple file name search. When I trace the
file.soprocess, I see calls tolstat,getxattrandgetxattragain for every file, and even for..entries. These system calls retrieve metadata about the file which is stored in a different location from the file name (the file name is stored in the directory contents, but the metadata are in the inode). Querying the metadata of a file multiple times is cheap since the data would be in the disk cache, but there can be a significant difference between querying the metadata and not querying the metadata.findis much more clever. It tries to avoid unnecessary system calls. It won't callgetxattrbecause it doesn't search based on extended attributes. When it's traversing a directory, it may need to calllstaton non-matching file names because that may be a subdirectory to search recursively (lstatis the system call that returns file metadata including the file type such as regular/directory/symlink/…). Howeverfindhas an optimization: it knows how many subdirectories a directory has from its link count, and it stops callinglstatonce it knows that it's traversed all the subdirectories. In particular, in a leaf directory (a directory with no subdirectories),findonly checks the names, not the metadata. Furthermore some filesystems keep a copy of the file type in the directory entry so thatfinddoesn't even need to calllstatif that's the only information it needs.If you run
findwith options that require checking the metadata, it'll make morelstatcalls, but it still won't make anlstatcall on a file if it doesn't need the information (for example because the file is excluded by a previous condition matching on the name).I suspect that other GUI search tools that reinvent the
findwheel are similarly less clever than the command line utility which has undergone decades of optimization. Dolphin, at least, is clever enough to use the locate database if you search “everywhere” (with the limitation which isn't clear in the UI that the results may be out of date).