I made a search test in Zorin - using the default Nautilus file manager.
It seems to only search through file names, and not content - as Windows does so easily.
I did some research, and found Nemo file manager - which does search content as well, so I installed Nemo though Terminal: sudo apt install nemo
However, after installing, I cannot find Nemo anywhere in the system.
Where on earth is it? This sort of Linux wackiness is a bit disorientating.
I think you might be confused because Nemo and Nautilus would show the same icon and name, but searching for Nemo under the application menu should bring it up:
You can also use generic names like "explorer" or "files".
The reason it appears as the same app is because Nemo is a fork of Nautilus, so they are very similar. Please see this thread to know how you can change this:
Nautilus does search the content as well. Just start typing right in the "address bar" and it should return results even if the files are not in the same folder that Nautilus is on:
The name which Nemo runs under is not important to me.
Being able to find words within files by typing in the search field
is what I actually need. I have tested it repeatedly by typing words I know exist in particular files -- and it failed to find them every time, therefore Nemo, or Nautilus failed to find them. So clearly there is no possibility of searching for content in ZorinOS Core (as it stands now).
If it were possible - there would have been a result.
If I cannot find content by keywords - the operating system is not much use for everyday work. Unfortunately.
If content searching in Nemo or Nautilus works only for some users
(Developer Gnomes et al..), or only works during specific lunar cycles..
then this is even greater cause for concern.
In XP I can find any word, or even part of a word, in any file, on Any Drive -- whether it's a local C drive, external drive, USB stick, or SD card.
Strangely, Windows 7 and later only search the local C drive.
So now I am stuck having to use XP as a search tool.
I know this may not be a solution as you see fit, but you could always use grep in the terminal to find content within a file. I'll include a link here to show some examples of how to use it: Find all files containing a specific text (string) on Linux? - Stack Overflow
I find it very fast the few times I have to use it. But most of the time I don't have a need for it except for rare circumstances. I actually haven't tried via a file manager, I'll have to check later to see if any support it by default.
so grep can be used in Terminal by typing; find / -type f -exec grep -H 'text-to-find-here' {} \; ?
If grep can find content in files -- then I will be quite pleased.
I'm not bothered if it's not the 'normal way' of searching..
I just want the results:
We've obviously had very different experiences with XP; I was so glad when Vista came out and had an actually useful search functionality (probably the one thing that can be praised for).
You can use either file manager you like, both will work. It's also possible to configure them to search for files in the same drive, attached storage or network shares. By default, only the "current computer" (that's the name of the setting) will be used to avoid slow queries that may be unnecessary.
Maybe the issue is indeed the file extension, as Aravisian suggests. I'm not aware of what limitations there are in that front. In my screenshot above, I used a .odt (LibreOffice Writer) file as well as .txt to prove that this works on text, even in binary formats. .wrt is a format that exists for a Windows-specific application, so that might explain the reason why it doesn't find anything.
In the off-chance that you actually want to go through the terminal approach, this would work albeit at the cost of being horribly inefficient. Please do not use this. This will search the entire drive and run a command for each and every file in it... did AI suggest to use this?
The better approach:
grep -iR /home 'text-to-find'
This will search only your home directory, where your own file exists. It also avoid making N+1 system calls to grep so that alone will see performance gains by orders of magnitude.