find vs ls

[Soviet_Mario]

In which situation(s) are these commands more or less
equivalent ?

In which one(s) is one much more fit than the other or the
reverse ?

A part from synthax, I am not sure about the respective "scopes"

And with regard to "internal" mechanism, do both, none, or
one or the other, relaying on real-time FS scan and/or on
mlocate database ?
Some considerations on man page of FIND seems to refer to
real time scanning (but the command is not slow at all even
munching 10^5-10^6 files at a time)

(generally I tend to use find, but mainly as I am not
confident with ls)



--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[Mike Easter]

Soviet_Mario wrote:
> man page of FIND

The man pages for ls & find are certainly useful, but the wp articles
are a little more comfortable for me:

https://en.wikipedia.org/wiki/Ls
https://en.wikipedia.org/wiki/Find_(Unix)

eg the wp says:
> find is a command-line utility that locates files based on some user-specified criteria and then applies some requested action on each matched object.

whereas:
> ls lists the files in the current working directory. If another directory is specified, then ls will list the files there, and in fact the user may specify any list of files and directories to be listed.


In terms of 'keystrokes' one big diff is that ls is defaulting to the
current working dir, whereas find has an 'open mind'.

--
Mike Easter

[Carlos E.R.]

On 24/09/2020 20.55, Soviet_Mario wrote:
>
> In which situation(s) are these commands more or less equivalent ?
>
> In which one(s) is one much more fit than the other or the reverse ?
>
> A part from synthax, I am not sure about the respective "scopes"
>
> And with regard to "internal" mechanism, do both, none, or one or the
> other, relaying on real-time FS scan and/or on mlocate database ?

Both execute the scan when you run the command.

> Some considerations on man page of FIND seems to refer to real time
> scanning (but the command is not slow at all even munching 10^5-10^6
> files at a time)

Yes, find is indeed much slower than (m)locate.


cer@Telcontar:~> time find /home > /dev/null
...
real 0m10,036s
user 0m0,224s
sys 0m0,647s
cer@Telcontar:~>

cer@Telcontar:~> time locate /home > /dev/null

real 0m1,671s
user 0m1,646s
sys 0m0,020s
cer@Telcontar:~>


Notice that the time needed to print the results is relevant.


find /home | wc -l
497223

cer@Telcontar:~> locate /home | wc -l
1622507
cer@Telcontar:~>

That's probably because of permissions.

>
> (generally I tend to use find, but mainly as I am not confident with ls)

The purpose is quite different.


--
Cheers, Carlos.

[Aragorn]

On 24.09.2020 at 20:55, Soviet_Mario scribbled:

> In which situation(s) are these commands more or less
> equivalent ?
>
> In which one(s) is one much more fit than the other or the
> reverse ?
>
> A part from synthax, I am not sure about the respective "scopes"
>
> And with regard to "internal" mechanism, do both, none, or
> one or the other, relaying on real-time FS scan and/or on
> mlocate database ?
> Some considerations on man page of FIND seems to refer to
> real time scanning (but the command is not slow at all even
> munching 10^5-10^6 files at a time)
>
> (generally I tend to use find, but mainly as I am not
> confident with ls)

"ls" lists files, directories and other filesystem objects in either
the supplied target diectory, or the current working directory if no
directory was supplied on the command line.

"find" scans for files, directories and other filesystem objects, with
the ability to perform one or multiple actions on the results, such as
deletion, permission/ownership changes, or just about anything else you
can think of.

"locate" does not scan the filesystem in and of itself — "updatedb"
does that — but simply looks for matching strings in the list of files
created by "updatedb", and "updatedb" itself is normally run once every
day via cron or a via systemd timer. If the machine is not powered on
when "updatedb" is scheduled to run, then the system's scheduler daemon
— e.g. anacron on sysvinit systems, or systemd in other systems — will
commonly execute the scan within a few minutes after booting up again.

The bottom line is that all three tools are different, both in operation
and in scope. "locate" is the fastest because it's looking for text in
a file. "ls" allows you to VIEW more than just the filenames, and
"find" allows you to DO more than list filenames.



--
With respect,
= Aragorn =

[Chris Elvidge]

If you want to do 'something' to each file in a list, do not use "ls" to
get the file list. Parsing that list may/will produce errors.
See: https://mywiki.wooledge.org/ParsingLs


--

Chris Elvidge, England

[Soviet_Mario]

intresting !

[Peter 'Shaggy' Haywood]

Groovy hepcat Carlos E.R. was jivin' in alt.os.linux on Fri, 25 Sep 2020
06:00 am. It's a cool scene! Dig it.

> Yes, find is indeed much slower than (m)locate.
>
> cer@Telcontar:~> time find /home > /dev/null
> ...
> real 0m10,036s
> user 0m0,224s
> sys 0m0,647s
> cer@Telcontar:~>
>
> cer@Telcontar:~> time locate /home > /dev/null
>
> real 0m1,671s
> user 0m1,646s
> sys 0m0,020s
> cer@Telcontar:~>

Note, however, that these two commands (find /home and locate /home)
do completely different things, produce different output (if not
redirected to /dev/null). The former scans for all files in the
directory /home. The latter scans the locate database for *all*
pathnames containing the string "/home", including, for example, on the
system I'm using to type
this, /mnt/nfs/unicorn/home, /opt/trinity/share/apps/konqsidebartng/entries/home.desktop
and /usr/lib/tmpfiles.d/home.conf, among others that are not within
the /home directory.

--


----- Dig the NEW and IMPROVED news sig!! -----


-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

[Arlen Holder]

Try "locate" when you get a chance.
o <https://man7.org/linux/man-pages/man1/locate.1.html>
--
I've seen many people use locate just once, & never use "find" ever again.
o At least for files that were there last night. :)

[Carlos E.R.]

On 26/09/2020 12.37, Peter 'Shaggy' Haywood wrote:
> Groovy hepcat Carlos E.R. was jivin' in alt.os.linux on Fri, 25 Sep 2020
> 06:00 am. It's a cool scene! Dig it.
>
>> Yes, find is indeed much slower than (m)locate.
>>
>> cer@Telcontar:~> time find /home > /dev/null
>> ...
>> real 0m10,036s
>> user 0m0,224s
>> sys 0m0,647s
>> cer@Telcontar:~>
>>
>> cer@Telcontar:~> time locate /home > /dev/null
>>
>> real 0m1,671s
>> user 0m1,646s
>> sys 0m0,020s
>> cer@Telcontar:~>
>
> Note, however, that these two commands (find /home and locate /home)
> do completely different things, produce different output (if not
> redirected to /dev/null). The former scans for all files in the
> directory /home. The latter scans the locate database for *all*
> pathnames containing the string "/home", including, for example, on the
> system I'm using to type
> this, /mnt/nfs/unicorn/home, /opt/trinity/share/apps/konqsidebartng/entries/home.desktop
> and /usr/lib/tmpfiles.d/home.conf, among others that are not within
> the /home directory.

Sure, but doesn't matter. locate finds 1622507 entries, while find gets
497223, three times less. Yet, locate is faster.


--
Cheers, Carlos.

[Richard Kettlewell]

If we’re allowed to declare that one is faster than the other regardless
of what they’re actually doing then my conclsusion is that find is
substantially faster (and more accurate too):

richard@araminta:~/junk$ time find . -name xyzzy
./xyzzy

real 0m0.018s
user 0m0.009s
sys 0m0.009s
richard@araminta:~/junk$ time locate xyzzy

real 0m0.571s
user 0m0.563s
sys 0m0.008s

--
https://www.greenend.org.uk/rjk/

[Bit Twister]

On Sun, 27 Sep 2020 21:22:59 +0100, Richard Kettlewell wrote:

> If we’re allowed to declare that one is faster than the other regardless
> of what they’re actually doing then my conclsusion is that find is
> substantially faster (and more accurate too):

Your test is a bit skewed.

locate has to scan all its database for the string.
Your find was told to just scan the current directory,
Had you used "find / " instead of "find . " you would have found
a difference. Then there is the problem of cache.

Time the same "find" command two times in row to verify that they are
the same. For example use "find /" to find the locate man page.

[J.O. Aho]

On 27/09/2020 22:22, Richard Kettlewell wrote:

> "Carlos E.R." <robin_...@es.invalid> writes:

>> Sure, but doesn't matter. locate finds 1622507 entries, while find
>> gets 497223, three times less. Yet, locate is faster.
>
> If we’re allowed to declare that one is faster than the other regardless
> of what they’re actually doing then my conclsusion is that find is
> substantially faster (and more accurate too):
>
> richard@araminta:~/junk$ time find . -name xyzzy
> ./xyzzy
>
> real 0m0.018s
> user 0m0.009s
> sys 0m0.009s
> richard@araminta:~/junk$ time locate xyzzy
>
> real 0m0.571s
> user 0m0.563s
> sys 0m0.008s
>

As I don't know how your updatedb config looks like, but I doubt it has
only entries in ~/junk so that comparison is a bit off.
Comparing just the time it takes to execute locate vs find is as
comparing apples and oranges, don't forget that updatedb which must have
been run before locate will be able to find anything at all does take
time and disk space. Also find has a lot of options that locate do not have.

--

//Aho

[J.O. Aho]

On 27/09/2020 18:16, Arlen Holder wrote:
> Try "locate" when you get a chance.

Don't work by itself, needs updatedb run before locate can work, changes
after updatedb has run are unknown for locate.

--

//Aho

[J.O. Aho]

On 27/09/2020 22:45, Bit Twister wrote:
> On Sun, 27 Sep 2020 21:22:59 +0100, Richard Kettlewell wrote:
>
>> If we’re allowed to declare that one is faster than the other regardless
>> of what they’re actually doing then my conclsusion is that find is
>> substantially faster (and more accurate too):
>
>
> Your test is a bit skewed.
>
> locate has to scan all its database for the string.

It will fail to find things added since the last time updatedb was run
and of course everything depends on what is configured in updatedb.conf,
so you may not find all the files as they may not be included in the
database.

All you do is comparing apples and oranges...


--

//Aho

[Carlos E.R.]

On 27/09/2020 22.48, J.O. Aho wrote:
> On 27/09/2020 22:22, Richard Kettlewell wrote:
>> "Carlos E.R." <robin_...@es.invalid> writes:
>
>>> Sure, but doesn't matter.  locate finds 1622507 entries, while find
>>> gets 497223, three times less. Yet, locate is faster.
>>
>> If we’re allowed to declare that one is faster than the other regardless
>> of what they’re actually doing then my conclsusion is that find is
>> substantially faster (and more accurate too):
>>
>>      richard@araminta:~/junk$ time find . -name xyzzy
>>      ./xyzzy
>>
>>      real    0m0.018s
>>      user    0m0.009s
>>      sys     0m0.009s
>>      richard@araminta:~/junk$ time locate xyzzy
>>
>>      real    0m0.571s
>>      user    0m0.563s
>>      sys     0m0.008s
>>
>
> As I don't know how your updatedb config looks like, but I doubt it has
> only entries in ~/junk so that comparison is a bit off.

It scans basically all. It skips other installed linuxes.

> Comparing just the time it takes to execute locate vs find is as
> comparing apples and oranges, don't forget that updatedb which must have
> been run before locate will be able to find anything at all does take
> time and disk space. Also find has a lot of options that locate do not
> have.

Certainly.


All I'm saying, that for finding files in the same basic tree, locate
runs faster. It only has to load a single file, then look for strings
(probably in memory), whereas find has to traverse hundreds of
directories and information located in hundreds of different places all
over the disk. It is bound to take longer, and it does in fact take
longer. If the disk(s) is rotating rust, way longer.

Yes, I'm aware of the caveats and differences between both.

--
Cheers, Carlos.

[Soviet_Mario]

the topic has gone along the tangent, focusing at speed aspect.

I was more intrested in understanding better when the one or
the other was more "fit" or "unsuitable", and when they both
might be used.
Maybe a bit phylosophical doubt, dunno ...

[Bit Twister]

On Mon, 28 Sep 2020 00:40:22 +0200, Soviet_Mario wrote:

> I was more intrested in understanding better when the one or
> the other was more "fit" or "unsuitable", and when they both
> might be used.

It just depends on your requirements for the task at hand.

Comparing the results from "man find" and "man locate" will show you that
find is a Swiss army knife compared to locate being just an ax.

[Soviet_Mario]

agreed ! +1 point for find as far as flexibility and
versatility is concerned

[Richard Kettlewell]

Bit Twister <BitTw...@mouse-potato.com> writes:
> Richard Kettlewell wrote:

>> If we’re allowed to declare that one is faster than the other regardless
>> of what they’re actually doing then my conclsusion is that find is
>> substantially faster (and more accurate too):
>
> Your test is a bit skewed.

That’s the point. All possible comparisons are skewed, because the tools
are doing different things in different ways.

> locate has to scan all its database for the string.
> Your find was told to just scan the current directory,
> Had you used "find / " instead of "find . " you would have found
> a difference. Then there is the problem of cache.

Cache already warm in the example posted.

--
https://www.greenend.org.uk/rjk/

[Chris Elvidge]

Have you taken into account the time taken for (m)updatedb to run?
Really that should be added to your time for locate.


--

Chris Elvidge, England

[Carlos E.R.]

Not really. Scan once a day when I'm not looking, then search a thousand
times for hits. Seems reasonable for me, I don't need to search for
files created today, I know where they are.

--
Cheers, Carlos.

[Paul]

The time for an updatedb to run, has varied over the history
of that executable. Try repeated runs today, and see what
you notice. It's probably noticeably faster than the old
days. And likely thanks to RAM speeds, amongst other reasons.

https://i.postimg.cc/wMgp8QRf/updatedb-timing.gif

Paul

[Arlen Holder]

On Mon, 28 Sep 2020 10:01:09 +0100, Richard Kettlewell wrote:

> That┬ the point. All possible comparisons are skewed, because the tools

> are doing different things in different ways.

I found out about "locate" about two decades ago, and, I don't think I've
ever used "find" ever since.

I understand that "find" will find stuff that isn't in the "updatedb"
database, but almost always, if I need to locate something, it's something
that was there last night.

Only if it was put there after midnight today, would I ever use "find".
o Which is almost never.

If someone uses "find" to locate a file that was there last night...
o Then I assess they're wasting a lot of their valuable time. :)
--
Usenet is a wondrous way to converse with old men about esoteric topics.

[Arlen Holder]

Yes. Of course. You're right.
o But not really <http://www.linux-sxs.org/utilities/updatedb.html>

Not in actual practice anyway...
o 'Cuz the updatedb has been run, and is run, in the background already.

How to run updatedb as a cron job?
o <https://serverfault.com/questions/961351/how-to-run-updatedb-as-a-cron-job>
o <https://www.linuxquestions.org/questions/linux-software-2/updatedb-daily-cron-job-352592/>

Manpage:
o <https://linux.die.net/man/8/updatedb>

Anyone using "locate" will already have put "updatedb" in his crontab
o So, after the first updatedb, "locate" works much better than does find.

Much, much (much) much better.
o As long as the file you're looking for was there last night.

Which, let's face it, is most of the time, 'cuz you're looking for
something that you don't remember where it went (most of the time).

All I'm sayin' is that once you use locate, you'll almost never use find
ever again, unless you enjoy wasting time, which is fine.

The key is to _know_ about the "locate/updatedb" command.
o Once you use it, you'll almost never use find ever agin' (IMHO).

Did I mention that only people who waste time use the "find" command?
:)
--
On Usenet we can discuss things as adults with different experiences.

[J.O. Aho]

On 29/09/2020 01:13, Arlen Holder wrote:
> On Sun, 27 Sep 2020 22:50:28 +0200, J.O. Aho wrote:
>
>> On 27/09/2020 18:16, Arlen Holder wrote:
>>> Try "locate" when you get a chance.
>>
>> Don't work by itself, needs updatedb run before locate can work, changes
>> after updatedb has run are unknown for locate.
>
> Yes. Of course. You're right.
> o But not really <http://www.linux-sxs.org/utilities/updatedb.html>
>
> Not in actual practice anyway...
> o 'Cuz the updatedb has been run, and is run, in the background already.

In his example it was run 5:05 am, so all the changes done after 5:20 is
unknown till next time the cronjob is run. So sorry, I wasn't wrong,
maybe you were to hasty reading so you missed reading the whole sentence.

> Anyone using "locate" will already have put "updatedb" in his crontab

Yes, that is the default, but as soon you add a file after the cronjob
finished, the new/removed file change is unknown for locate. Also files
that are outside the directories listed in the updatedb.conf are not
tracked at all.

> The key is to _know_ about the "locate/updatedb" command.

> Once you use it, you'll almost never use find ever agin' (IMHO).
>
> Did I mention that only people who waste time use the "find" command?

And tell me how to find files that has been modified in the last 30
hours and was created 6 weeks ago with help of locate.

Or how to add the string "EOF" to the end of all files with a name
matching the pattern bash*.txt that is no older than 20 days?

--

//Aho

[Carlos E.R.]

On 29/09/2020 01.13, Arlen Holder wrote:
> On Sun, 27 Sep 2020 22:50:28 +0200, J.O. Aho wrote:
>> On 27/09/2020 18:16, Arlen Holder wrote:
>>> Try "locate" when you get a chance.

> All I'm sayin' is that once you use locate, you'll almost never use find
> ever again, unless you enjoy wasting time, which is fine.
>
> The key is to _know_ about the "locate/updatedb" command.
> o Once you use it, you'll almost never use find ever agin' (IMHO).
>
> Did I mention that only people who waste time use the "find" command?
> :)

Don't generalize and jump to conclusions like that, Arlen. The command
"find" can do more things that just find a file, like finding a file
with criteria such as ownership, or date bracket, or type, say.


--
Cheers, Carlos.

[Cecil Westerhof]

Yes I once put pictures on a non-standard place. The only way I could
find them was with find because I knew the date I shot them.
The solution was:
find / -iname '*.jpg' -type f -newermt 2019-06-28 ! -newermt 2019-06-29 -ls

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[Arlen Holder]

On Tue, 29 Sep 2020 13:45:40 +0200, Cecil Westerhof wrote:

>>> The key is to _know_ about the "locate/updatedb" command.
>>> o Once you use it, you'll almost never use find ever agin' (IMHO).
>>>
>>> Did I mention that only people who waste time use the "find" command?
>>> :)
>>
>> Don't generalize and jump to conclusions like that, Arlen. The command
>> "find" can do more things that just find a file, like finding a file
>> with criteria such as ownership, or date bracket, or type, say.
>
> Yes I once put pictures on a non-standard place. The only way I could
> find them was with find because I knew the date I shot them.
> The solution was:
> find / -iname '*.jpg' -type f -newermt 2019-06-28 ! -newermt 2019-06-29 -ls

Hi Carlos & Cecil Westerhof,

Yours are all good and quite appropriate clarifying points of view.
o There's a reason Linux includes _both_ "locate" and "find" after all. :)

o What's the difference between locate and find command in Linux
<https://www.thegeekdiary.com/whats-the-difference-between-locate-and-find-command-in-linux/>
<https://unix.stackexchange.com/questions/60205/locate-vs-find-usage-pros-and-cons-of-each-other>
<https://www.geeksforgeeks.org/difference-between-locate-which-and-find-command-in-linux/>
etc.

Adding the nuance of detail, my point of view can be summarized as...
a. Locate works fantastically extremely fast compared to the slow find...
b. If what you're looking for are specific filespec regular expressions.
c. In fact, if you use find for _that_, you're always wasting your time...
d. Unless, of course, the file was put there after the crontab'd updatedb.

Your perfectly valid point of view adds _another_ caveat, which is...
e. Yeah, but locate doesn't locate by file types while find does!

Fair enough.
o I don't ever disagree in the least with facts.

Nuances in detail are where all Usenet discussions should be.
o Thanks for adding value and clarifying my comments on the locate command.
--
I fell in love with a locate command decades ago & haven't used find since.

[Soviet_Mario]

On 30/09/20 19:31, Arlen Holder wrote:
> On Tue, 29 Sep 2020 13:45:40 +0200, Cecil Westerhof wrote:
>
>>>> The key is to _know_ about the "locate/updatedb" command.
>>>> o Once you use it, you'll almost never use find ever agin' (IMHO).
>>>>
>>>> Did I mention that only people who waste time use the "find" command?
>>>> :)
>>>
>>> Don't generalize and jump to conclusions like that, Arlen. The command
>>> "find" can do more things that just find a file, like finding a file
>>> with criteria such as ownership, or date bracket, or type, say.
>>
>> Yes I once put pictures on a non-standard place. The only way I could
>> find them was with find because I knew the date I shot them.
>> The solution was:
>> find / -iname '*.jpg' -type f -newermt 2019-06-28 ! -newermt 2019-06-29 -ls
>
> Hi Carlos & Cecil Westerhof,
>
> Yours are all good and quite appropriate clarifying points of view.
> o There's a reason Linux includes _both_ "locate" and "find" after all. :)
>
> o What's the difference between locate and find command in Linux
> <https://www.thegeekdiary.com/whats-the-difference-between-locate-and-find-command-in-linux/>
> <https://unix.stackexchange.com/questions/60205/locate-vs-find-usage-pros-and-cons-of-each-other>
> <https://www.geeksforgeeks.org/difference-between-locate-which-and-find-command-in-linux/>
> etc.
>
> Adding the nuance of detail, my point of view can be summarized as...
> a. Locate works fantastically extremely fast compared to the slow find...

with regard to this alleged slowlyness ... I am wondering
about one thing : on a mechanical rusty drive, find takes
sec-to-minutes to scan million files, not hours. And the
outcome comes after manual input in the cmd line, likely to
take tens of seconds.

So my opinion is : except when possibly nested in iterative
script, when called programmatically called multiple times,
the supposed slowlyness of find is actually very little
relevant.

maybe on scripted actions, expecially when a command is
nested into "for" cycles, the difference in speed might
become relevant. But not so in all contexts.

for example, in backup tasks, when most CPU time is spent in
compressing, a FIND command is not actually a bottleneck at all

> b. If what you're looking for are specific filespec regular expressions.
> c. In fact, if you use find for _that_, you're always wasting your time...

maybe, but for example the not up-to-date status is bad when
selecting files for backup purpose (where the versatile
time-criteria for selection of FIND can be useful)

> d. Unless, of course, the file was put there after the crontab'd updatedb.
>
> Your perfectly valid point of view adds _another_ caveat, which is...
> e. Yeah, but locate doesn't locate by file types while find does!
>
> Fair enough.
> o I don't ever disagree in the least with facts.
>
> Nuances in detail are where all Usenet discussions should be.
> o Thanks for adding value and clarifying my comments on the locate command.
>

just my penny, I am very far from skilled in anything has to
do with linux

[Carlos E.R.]

Telcontar:~ # time find / | wc -l
find: ‘/run/user/1000/gvfs’: Permission denied
find: ‘/var/run/user/1000/gvfs’: Permission denied
9570661

real 14m22.161s
user 0m5.201s
sys 0m22.309s
Telcontar:~ #


Although there were at least to NFS mounts that were also scanned.


--
Cheers, Carlos.

[Arlen Holder]

On Wed, 30 Sep 2020 22:19:40 +0200, Soviet_Mario wrote:

> with regard to this alleged slowlyness ... I am wondering
> about one thing : on a mechanical rusty drive, find takes
> sec-to-minutes to scan million files, not hours. And the
> outcome comes after manual input in the cmd line, likely to
> take tens of seconds.

Hi Soviet Mario,
I think someone already posted a speed differential in this thread.

Admittedly, the instant I found out about "locate", decades ago, I dropped
"find" like I would a hot potato, since locate was lightning fast at that
time by way of direct comparison for locating specific named files.

That was well before Linux existed.
o It may have been SunOS, or maybe Solaris at that time.

> So my opinion is : except when possibly nested in iterative
> script, when called programmatically called multiple times,
> the supposed slowlyness of find is actually very little
> relevant.
> maybe on scripted actions, expecially when a command is
> nested into "for" cycles, the difference in speed might
> become relevant. But not so in all contexts.
>
> for example, in backup tasks, when most CPU time is spent in
> compressing, a FIND command is not actually a bottleneck at all

The inordinate slowness of "find" is fine for those with patience.
o On a computer, I have almost zero patience for slow programs.

>> b. If what you're looking for are specific filespec regular expressions.
>> c. In fact, if you use find for _that_, you're always wasting your time...
>
> maybe, but for example the not up-to-date status is bad when
> selecting files for backup purpose (where the versatile
> time-criteria for selection of FIND can be useful)

You can always run an updatedb manually at any time, but it does take time:
o sudo updatedb

In general, your crontab'd updatedb command is more complex because you can
set a plethora of options, and many people do.

> just my penny, I am very far from skilled in anything has to
> do with linux

I'm no longer "skilled" at Linux myself.

I used to be on SunOS and Solaris (and many others before that), full time.
o But now, I only use Linux when I need the power of its command options

With the newly added WSL Windows Subsystem for Linux, even less nowadays.

For example, I get Linux commands on Windows simply by typing "wsl":
o Win+R > wsl

As explained in gory detail here:
o Tutorial for setting up Ubuntu as a Windows Subsystem for Linux WSL in Windows 10
<https://groups.google.com/forum/#!topic/alt.comp.freeware/rOT8xBWo9dk>

But I still dual boot to Linux mainly for connections to my iOS devices.

Thankfully, Linux treats iOS devices with such fantastic ability.
o That an iOS device is almost nothing but a USB storage device to Linux.

For example:
o Simultaneously slide Windows Linux iOS Android files back and forth
over USB at 7GB per minute speeds using 100% native devices
(no proprietary software needed)
<https://groups.google.com/forum/#!topic/alt.comp.freeware/K0NZ0nb1pWw>
--
Linux, for some reason, treats iOS devices like an operating system should.

[Soviet_Mario]

On 01/10/20 01:18, Arlen Holder wrote:
> On Wed, 30 Sep 2020 22:19:40 +0200, Soviet_Mario wrote:
>

CUT

>>
>> for example, in backup tasks, when most CPU time is spent in
>> compressing, a FIND command is not actually a bottleneck at all
>
> The inordinate slowness of "find" is fine for those with patience.
> o On a computer, I have almost zero patience for slow programs.
>
>>> b. If what you're looking for are specific filespec regular expressions.
>>> c. In fact, if you use find for _that_, you're always wasting your time...
>>
>> maybe, but for example the not up-to-date status is bad when
>> selecting files for backup purpose (where the versatile
>> time-criteria for selection of FIND can be useful)
>
> You can always run an updatedb manually at any time, but it does take time:
> o sudo updatedb

mmm, in such a case maybe locate + updatedb could run slower
than find itself

>
> In general, your crontab'd updatedb command is more complex because you can
> set a plethora of options, and many people do.

yes. I don't master creating crontab jobs. Maybe in the far
future :)

>
>> just my penny, I am very far from skilled in anything has to
>> do with linux
>
> I'm no longer "skilled" at Linux myself.
>
> I used to be on SunOS and Solaris (and many others before that), full time.
> o But now, I only use Linux when I need the power of its command options
>
> With the newly added WSL Windows Subsystem for Linux, even less nowadays.
>
> For example, I get Linux commands on Windows simply by typing "wsl":
> o Win+R > wsl
>
> As explained in gory detail here:
> o Tutorial for setting up Ubuntu as a Windows Subsystem for Linux WSL in Windows 10
> <https://groups.google.com/forum/#!topic/alt.comp.freeware/rOT8xBWo9dk>
>
> But I still dual boot to Linux mainly for connections to my iOS devices.
>
> Thankfully, Linux treats iOS devices with such fantastic ability.
> o That an iOS device is almost nothing but a USB storage device to Linux.
>
> For example:
> o Simultaneously slide Windows Linux iOS Android files back and forth
> over USB at 7GB per minute speeds using 100% native devices
> (no proprietary software needed)
> <https://groups.google.com/forum/#!topic/alt.comp.freeware/K0NZ0nb1pWw>
>


--

[Arlen Holder]

On Thu, 1 Oct 2020 13:27:19 +0200, Soviet_Mario wrote:

> mmm, in such a case maybe locate + updatedb could run slower
> than find itself

Certainly, but not, in general, in practice simply because both "find" and
"locate" tend to report too much stuff in the beginning, which you then
often progressively hone by repeat applications of ever finer-tuned
options.

In the practical sense, multiply repeated further honed "locate" commands
take almost no additional time at all, while correspondingly fine-tuned
"find" commands exasperatingly take essentially just as long each time you
repeat them as they did the first time you ran them.

In that common scenario of repeated "pipe grep" fine tuning, "locate" is
astronomically faster than is "find" in almost every instance conceivable.

>> In general, your crontab'd updatedb command is more complex because you can
>> set a plethora of options, and many people do.
>
> yes. I don't master creating crontab jobs. Maybe in the far
> future :)

Ah, but that problem set is no different between "updatedb/locate" & "find"
in that both generally require fine tuning which you learn over time, as
needed.

To my point above, in practice, tuning subsequent locates (usually via
piped greps of "-v" "-i" and other key honing options) is far (far) faster
than would be repeat subsequent tuning of the "find" command.
--
There's knowledge, which is why some people still use "find", and then
there's experience, which is why most of us decades ago ditched "find" for
"locate".

[Bit Twister]

On Thu, 1 Oct 2020 13:27:19 +0200, Soviet_Mario wrote:

>

> yes. I don't master creating crontab jobs. Maybe in the far
> future :)

If you can write a script that works with a
#!/bin/bash
PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin

actual comands
to be executed here

then you have a 99.9% completed a cron job.

[Soviet_Mario]

in which folder have such script to be located ?
how is the timing (schedule) controlled ?

[Carlos E.R.]

On 01/10/2020 18.14, Soviet_Mario wrote:
> On 01/10/20 14:26, Bit Twister wrote:
>> On Thu, 1 Oct 2020 13:27:19 +0200, Soviet_Mario wrote:
>>
>>>
>>> yes. I don't master creating crontab jobs. Maybe in the far
>>> future :)
>>
>> If you can write a script that works with a
>> #!/bin/bash
>>     PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
>>
>>     actual comands
>>     to be executed here
>>
>> then you have a 99.9% completed a cron job.
>>
>
> in which folder have such script to be located ?

You don't locate it, it does for you.

You call "crontab -e" and that will call the editor with the right file with "vi". If you want another editor, then define:

export EDITOR=/usr/bin/mcedit

for instance on ".bashrc".

> how is the timing (schedule) controlled ?

That's the "trick". The comment below is my guide:


SHELL=/bin/bash
MAILTO="cer"

# min hour day Month week_day 0=7=sunday.

* * * * * /usr/bin/play /tmp/time.wav

Runs every minute. This would run on the hour and the half hour:


-0,30 * * * *




This is not the only way. There is also an /etc/crontab file. Example on SUSE machines:

SHELL=/bin/sh
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
MAILTO=root
#
# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
#
-*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1


There are two differences. The "dash" in front makes syslog to not log every time it runs (it runs ever 15 minutes).
Then the word "root" means that it is run under that user (it can be any).
What goes after "root" is the command it runs, which is an *SUSE trick to run files placed on some special directories.


There is also the directory /etc/cron.d/. This place is typically used by packages that drop a file in there (instead of editing /etc/crontab), but the syntax is the same as for "/etc/crontab".


--
Cheers, Carlos.

[Bit Twister]

On Thu, 1 Oct 2020 18:14:52 +0200, Soviet_Mario wrote:
> On 01/10/20 14:26, Bit Twister wrote:
>> On Thu, 1 Oct 2020 13:27:19 +0200, Soviet_Mario wrote:
>>
>>>
>>> yes. I don't master creating crontab jobs. Maybe in the far
>>> future :)
>>
>> If you can write a script that works with a
>> #!/bin/bash
>> PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
>>
>> actual comands
>> to be executed here
>>
>> then you have a 99.9% completed a cron job.
>>
>
> in which folder have such script to be located ?

Depends on when you want it to run by whom.

For a start run
man cron
man crontab

> how is the timing (schedule) controlled ?

Depends. usually by crontab. run
cat /etc/crontab
for system cron jobs.

Since you provide no information on your setup all I can give is just
general information.

System cron jobs are in
$ ls -1d /etc/cron*ly
/etc/cron.daily
/etc/cron.hourly
/etc/cron.monthly
/etc/cron.weekly
/etc/cron.yearly

User cron job location is /var/spool/cron

As system administrator I do not want to have to help users getting
jobs into /var/spool/cron.

What I did/do is put a general purpose user job in /var/spool/cron
to run $HOME/.cron* jobs. After that user can do whatever they like
in their $HOME/.cron* directories,


For all that to work, I have put links in the /etc/cron* directories

$ ls -al /etc/cron*/_*
lrwxrwxrwx 1 root root 25 Dec 16 2019 snipped do to
/etc/cron.daily/_daily -> /local/bin/local_cron_job
/etc/cron.hourly/_hourly -> /local/bin/local_cron_job
/etc/cron.monthly/_monthly -> /local/bin/local_cron_job
/etc/cron.weekly/_weekly -> /local/bin/local_cron_job
/etc/cron.yearly/_yearly -> /local/bin/local_cron_job

$ cat /local/bin/local_cron_job
#!/bin/bash
#************************************************************************
#*
#* local_cron_job - cron job to run /local/cron/(hourly|daily...) jobs
#*
#*
#* Usually called from /etc/cron.hourly, daily, monthly,.....
#*
#* Usage: link _name to /local/bin/local_cron_job
#*
#* Example: cd /etc/cron.hourly
#* ln -s /local/bin/local_cron_job _hourly
#* Leading underscore on _name is important
#* because it is removed to get directory name in /local/cron and
#* causes it to be executed before any other jobs in the directory.
#*
#***********************************************************************

_exe=${0##*/}

_job=${_exe:1}

if [ ! -d /local/cron/$_job ] ; then
echo "$_exe FATAL error:"
echo "$0 link is incorrect"
echo "or /local/cron/$_job does not exist"
/bin/false
else
nice -n 19 run-parts --report /local/cron/$_job
/bin/true
fi

#**************** end /local/bin/local_cron_job *************

User cron job is
$ cat /etc/skel/.cron/cron.job
#*************** start of cron.job *********************************
#
####################################################################
# syntax example #
#minute (0-59), #
#| hour (0-23), #
#| | day of the month (1-31), #
#| | | month of the year (1-12), #
#| | | | day of the week (0-6 with 0=Sunday)#
#| | | | | commands #
#30 01 * * * /home/jim/bin/cleartmp #
# #
####################################################################
SHELL=/bin/bash
MAILTO=junk
HOME=/home/junk
_cron_loc=/home/junk
PATH=/home/junk/local/work:/sbin:/usr/sbin:/usr/local/bin\
:/local/bin:/usr/local/bin:/bin:/usr/bin:/usr/bin/X11:/usr/games\
:/home/junk/local/bin
0 0-23 * * * /bin/nice -n 19 /usr/bin/run-parts $_cron_loc/.cron/hourly
02 4 * * * /bin/nice -n 19 /usr/bin/run-parts $_cron_loc/.cron/daily
12 4 * * 0 /bin/nice -n 19 /usr/bin/run-parts $_cron_loc/.cron/weekly
22 4 1 * * /bin/nice -n 19 /usr/bin/run-parts $_cron_loc/.cron/monthly
32 4 * * * /bin/nice -n 19 /local/bin/ck_mail_msg
#*
## INSTALL: change junk to user's name, (ie, to jim)
#* cp ~junk/.cron/cron.job /var/spool/cron/junk
#* chown junk:junk /var/spool/cron/junk
#* chmod 600 /var/spool/cron/junk
#*
#************* end ~junk/.cron/cron.job **********************


All the user does is change junk to their name and I place a
copy in /var/spool/cron as their login id
Example
# ls -l /var/spool/cron/junk
-rw------- 1 junk junk 867 Dec 16 2019 junk

[Stéphane CARPENTIER]

Le 28-09-2020, Arlen Holder <arlen_...@newmachines.com> a écrit :
>
> If someone uses "find" to locate a file that was there last night...
> o Then I assess they're wasting a lot of their valuable time. :)

How do you find all of your empty files files with locate ?
How do you find all the files which belong to your group with locate ?

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[Stéphane CARPENTIER]

OK, I'm late I only saw nobody reply something like this the first time
I saw him mention it and I have still a lot to read to catch up.

[Arlen Holder]

On 01 Oct 2020 19:19:42 GMT, Stephane CARPENTIER wrote:

>> And tell me how to find files that has been modified in the last 30
>> hours and was created 6 weeks ago with help of locate.
>>
>> Or how to add the string "EOF" to the end of all files with a name
>> matching the pattern bash*.txt that is no older than 20 days?
>
> OK, I'm late I only saw nobody reply something like this the first time
> I saw him mention it and I have still a lot to read to catch up.

Hi Stephane,
I easily conceded that the find command finds _different_ things that the
locate command doesn't find, which, as I noted, is why both exist. :)

My only admonishment is that there are many people using find to find files
merely by name, and, for _that_, I stress that locate is fantastically
faster in real-world use models (as long as the filespec was there at the
time of the crontab'd updatedb).

Bear in mind that I also noted that it's common to _repeat_ a search, often
tacking on successive piped greps, such that the "bang bang pipe grep"
action lends itself efficiently to "locate" but not to "find".

Each find takes forever, forever again, and forever again.
o Each locate is much faster, even when run again & again & again.

Personally, the day I found out about locate, decades ago, was perhaps the
last time I ever wanted to use the find command, since I don't have that
kind of patience that it takes to successively hone the find command.

However, if you _already_ have a well-honed find, then you only need to run
it once, and the extraordinarily huge speed advantages of the "bang bang
pipe grep" tacked on to successive locates doesn't hold the allure.

In summary, both have their place, which is why both exist.
--
On Usenet we can discuss which commands we like best agreeing on the facts.

[Arlen Holder]

On 01 Oct 2020 19:16:14 GMT, Stephane CARPENTIER wrote:

>> If someone uses "find" to locate a file that was there last night...
>> o Then I assess they're wasting a lot of their valuable time. :)
>
> How do you find all of your empty files files with locate ?
> How do you find all the files which belong to your group with locate ?

Hi Stephane,

I don't disagree with your point of view in the least...
o There is a good reason both find & locate exist in almost every Linux

The typical use model for locating files, often is that you successively
hone the results, where I, for one, make extensive use of the "bang minus
one colon global search replace x with y" syntax, and the "bang bang grep"
syntax, which, from finger memory is syntactically something like:
$ locate xyz
$ !-1:gs/xyz/abc
$ !! + grep -v FOO
$ !! grep -i bar
etc.

Notice that a "typical" use model, for ad hoc searches, is to run the
search, see what it finds, then hone the search with successively tacked on
filters.

To do _that_ typical process with "locate" is astronomically faster than to
do the same task with the find command, which, from memory is something
like:
$ find . -name foo

But then a successively tacked on bang bang filter takes just as long to
run the second time as it did the first time.
$ !! | grep -v FOO

Of course, if you _already_ have honed your find command options to
perfection, that astronomical advantage of locate disappears.

The tremendous speed advantage of locate also disappears if you need to
find stuff which locate won't find (as you noted), and if the filespec is
more recent than the last crontab'd updatedb.

In short, if all you want is to find files by name, you're usually wasting
your time using the find command, but if you need to find files by more
than just name, then you're stuck with the arduously slow find command.

There's a reason both exist in almost every Linux I've ever seen.
--
Together we can discuss the nuances of each Linux command with open minds.

[Arlen Holder]

On Thu, 1 Oct 2020 21:00:02 -0000 (UTC), Arlen Holder wrote:

> $ locate xyz
> $ !-1:gs/xyz/abc
> $ !! + grep -v FOO
> $ !! grep -i bar

Typos...

$ locate xyz
$ !-1:gs/xyz/abc

$ !! | grep -v FOO

$ !! | grep -i bar

The main point is that the extensively honed series of locates is
astronomically faster than doing the same honing with the find command.

If you _already_ have your find command honed, or if you need a search that
locate doesn't do, then this astronomically huge speed advantage of the
locate command over the find command disappears.

It all depends on what you want to do...
o Which is why both commands exist, after all.
--
Discussing the merits of each Linux command has its merits indeed.

[Stéphane CARPENTIER]

Le 01-10-2020, Arlen Holder <arlen_...@newmachines.com> a écrit :
> On Thu, 1 Oct 2020 21:00:02 -0000 (UTC), Arlen Holder wrote:
>
>> $ locate xyz
>> $ !-1:gs/xyz/abc
>> $ !! + grep -v FOO
>> $ !! grep -i bar
>
> Typos...
> $ locate xyz
> $ !-1:gs/xyz/abc
> $ !! | grep -v FOO
> $ !! | grep -i bar
>
> The main point is that the extensively honed series of locates is
> astronomically faster than doing the same honing with the find command.

If you have no clue where to look for your file, I agree, you search
from the root directory and it really takes time. But if you have an
idea where to search for your files, it's not always that long.

And if your search returns a lot of answers, you have to use a lot of grep
after your locate and the time taken to display the result reduce the
difference.

[Bit Twister]

Fortunately, it a simple matter of programming to have a script take
each argument on the command line and pipe it through another grep.
Need to reduce result is as easy as hitting an up arrow to had another
value to the previous command.

As a matter of fact, you can make the script ambidextrous, for searching
man pages, locate, journalctl log, showrgb color selections,
systemctl list-units --type=service, spelling dictionary ....
Currently I have 50+ different searches.

For anyone wanting something to play with, here is your "ux" starter script.
-----8< ----8< ----8< ----8< cut below this line----8< ----8< ----8<
#! /bin/bash
#******************************************************************************
#*
#* ux - search different files with user supplied keywords. Version 2.3
#*
#* basename is called to determine command and file to use.
#*
#*
#* To add a new selection:
#* copy some_case_name stanza, set case_name, comment and
#* whatever commands needed.
#* create a link with ln -s ux new_case_name
#* or run the command ux -i
#*
#* Some linked example snippets: ls -l u*
#* ue -> ux
#* uh -> ux
#* uidx -> ux
#* ulocate -> ux
#* uman -> ux
#* urgb -> ux
#* urls -> ux
#* and to find a word in dictionary there is
#* sp -> ux
#*
#* sp usage example would be
#* sp amb d x to find ambidextrous
#*
#* Install procedure:
#* save this as ux
#* chmod +x ux
#* You install in any directory found in your $PATH variable. To check:
#* echo $PATH
#* Usual install location is /usr/local/bin, so
#* cp ux /usr/local/bin/ux
#* chmod +x /usr/local/bin/ux
#* cd /usr/local/bin
#* ux -i
#* cd
#*
#* Test:
#* ux
#* FYI: all commands may not work because I left some that depend
#* on files in my setup and to give you a stanza to work on.
#*
#* NOTE: Script requires xterm to be installed.
#* If you are going to use ujctl, your login needs to have the
#* systemd-journal group. If you add it, you need to log out/in
#* to pick up the new group.
#*
#*
#******************************************************************************

export PATH=\
/usr/local/sbin:/usr/sbin:sbin\
:/usr/local/bin:/usr/bin:/bin\
:/usr/libexec\
:/local/bin:$HOME/bin\

_cmd_line_args="$*"

which ux > /dev/null 2>&1
if [ $? -ne 0 ] ; then
which ux
echo "
ux needs to be in your path and you have followed the install procedure
"
exit 1
fi

_exe_fn=$(which ux)
_app=$(basename $0)
_node=$(hostname --short)

_tmp_fn=/$_app
_exe_dir=${_exe_fn%$_tmp_fn}
_xfont='-font 6x10 -geom 200'
_xcolor='-fg black -bg lightgrey'
_xlayout="-font 7x13 -geom 200 $_xcolor"

_tmp_fn=$HOME/tmp/$_app.x
_arg1=""
_args=""
_cmd_line=""
_tmp=""

#***************************
#* main code start here
#***************************
echo -ne '\033[?3h\033[?66h'
# echo "tput clear" >> $_tmp_fn
mkdir -p $HOME/tmp

/bin/cp /dev/null $_tmp_fn


echo "sleep 1" >> $_tmp_fn

case $_app in
ujctl)
_usage_args='bs:u:' # list of valid switches ':' indicates needs value

while getopts "$_usage_args" OPTION; do
case "$OPTION" in
b) _args="$_args -b" ;;
s) _args="$_args --since '$(date --date "$OPTARG" '+%Y-%m-%d %H:%M:%S')'" ;;
u) _args="$_args --until '$(date --date "$OPTARG" '+%Y-%m-%d %H:%M:%S')'" ;;
*)
echo "unrecognized $_app option $OPTION"
echo "$_cmd_line_args"
usage
;;
esac
done

if [ $OPTIND -gt 0 ] ; then
shift $((OPTIND-1))
set -- $*
fi
;;
ux)
set -- $_cmd_line_args
if [ $# -gt 0 ] ; then
if [ "$1" = "-i" ] ; then
cd $_exe_dir
while read -r line ; do
set -- $line
_fn=$1
if [ ! -e $_exe_dir/$_fn ] ; then
ln -sf $_exe_fn $_fn
fi
done < <(grep '#' $_exe_fn | grep ')' | tr -d '#)' | grep -v ux_fn )
echo "created:"
ls -al | grep -- '->'
exit 0
fi
fi
;;
*) ;;
esac

if [ $# -ne 0 ] ; then
_arg1=$1
shift
fi

while [ $# -ne 0 ] ; do
if [ $# -eq 1 ] ; then
_tmp=$_tmp" | grep --color -Eie \"$1\""
else
_tmp=$_tmp" | grep -Eie \"$1\""
fi
shift
done


case $_app in
sp) #- search spelling dictionary (assumes words,util-linux rpms installed)
echo "look \"$_arg1\" $_tmp" >> $_tmp_fn
;;
ualias) #- search ~/.bashrc /etc/bashrc
echo "echo -e \"\n# $_exe $_cmd_line\"" >> $_tmp_fn
echo "echo -e \"looking in $HOME/.bashrc\"" >> $_tmp_fn
echo "grep --color -Eie \"$_arg1\" $HOME/.bashrc $_tmp" >> $_tmp_fn
echo "echo -e \"looking in /etc/bashrc\"" >> $_tmp_fn
echo "grep --color -Eie \"$_arg1\" /etc/bashrc $_tmp" >> $_tmp_fn
;;
udir) #- search directory for file name
echo "ls -al | grep -Eie $_arg1 $_tmp" >> $_tmp_fn
;;
uenv) #- search for environment variable
echo "env |sort | grep -Eie \"$_arg1\" $_tmp" >> $_tmp_fn
;;
uh) #- search my /local/doc/unix.help file
echo "grep --color -Eie \"$_arg1\" /local/doc/unix.help $_tmp" >> $_tmp_fn
;;
ujctl) #- search journalctl log
echo "echo -e \"\n# looking in journalctl $_args \"" >> $_tmp_fn
echo "journalctl $_args | grep -Eie \"$_arg1\" $_tmp" >> $_tmp_fn
;;
ukernel) #- search /usr/share/doc/kernel-doc/
arr=(
"/usr/share/doc/kernel-doc/kernel-parameters.txt"
"/usr/share/doc/kernel-doc/video4linux/bttv/Insmod-options"
"/usr/share/doc/kernel-doc/networking/ip-sysctl.txt"
"/usr/share/doc/kernel-doc/vm/slub.txt"
"/usr/share/doc/kernel-doc/clk.txt"
"/usr/share/doc/kernel-doc/cgroups/memory.txt"
"/usr/share/doc/kernel-doc/x86/x86_64/boot-options.txt"
"/usr/share/doc/kernel-doc/block/cfq-iosched.txt"
"/usr/share/doc/kernel-doc/block/cmdline-partition.txt"
"/usr/share/doc/kernel-doc/blockdev/floppy.txt"
"/usr/share/doc/kernel-doc/blockdev/paride.txt"
"/usr/share/doc/kernel-doc/blockdev/ramdisk.txt"
"/usr/share/doc/kernel-doc/cgroups/cpusets.txt"
"/usr/share/doc/kernel-doc/debugging-via-ohci1394.txt"
"/usr/share/doc/kernel-doc/fb/modedb.txt"
"/usr/share/doc/kernel-doc/filesystems/nfs/nfsroot.txt"
"/usr/share/doc/kernel-doc/ide/ide.txt"
"/usr/share/doc/kernel-doc/input/joystick.txt"
"/usr/share/doc/kernel-doc/isdn/README.HiSax"
"/usr/share/doc/kernel-doc/kdump/kdump.txt"
"/usr/share/doc/kernel-doc/laptops/sonypi.txt"
"/usr/share/doc/kernel-doc/md.txt"
"/usr/share/doc/kernel-doc/networking/ipv6.txt"
"/usr/share/doc/kernel-doc/power/video.txt"
"/usr/share/doc/kernel-doc/s390/CommonIO"
"/usr/share/doc/kernel-doc/serial-console.txt"
"/usr/share/doc/kernel-doc/sound/alsa/alsa-parameters.txt"
"/usr/share/doc/kernel-doc/sound/oss/oss-parameters.txt"
"/usr/share/doc/kernel-doc/sysctl/vm.txt"
"/usr/share/doc/kernel-doc/video4linux/meye.txt"
"/usr/share/doc/kernel-doc/vm/transhuge.txt"
"/usr/share/doc/kernel-doc/watchdog/watchdog-parameters.txt"
"/usr/share/doc/kernel-doc/x86/boot.txt"
"/usr/share/doc/kernel-doc/x86/i386/IO-APIC.txt"
"/usr/share/doc/kernel-doc/x86/intel_mpx.txt"
"/usr/share/doc/kernel-doc/dynamic-debug-howto.txt"
)
for index in ${!arr[*]} ; do
echo "echo looking in ${arr[$index]} " >> $_tmp_fn
echo "grep --color -Eie \"$_arg1\" ${arr[$index]} $_tmp" >> $_tmp_fn
done
;;
ulocate) #- search system's locate database
echo "locate -i -- \"$_arg1\" $_tmp" >> $_tmp_fn
;;
uls) #- search ls results
echo "ls | grep -Eie $_arg1 $_tmp" >> $_tmp_fn
;;
uman) #- search apropos
echo "apropos \"$_arg1\" $_tmp" >> $_tmp_fn
;;
umanc) #- search apropos for C functions
echo "apropos \\(3\\) | grep -i \"$_arg1\" $_tmp | egrep -v \"::|DES_|Tcl_|XC|X|TCL_|^X\" " >> $_tmp_fn
;;
ups) #- search ps aux
echo "ps aux | grep -v $_app | grep -Eie \"$_arg1\" $_tmp" >> $_tmp_fn
;;
urgb) #- search showrgb color selections (assumes rgb rpm installed)
echo "showrgb | grep -Eie \"$_arg1\" $_tmp" >> $_tmp_fn
;;
urpm) #- search for installed rpm
echo "rpm -qa \"*$_arg1*\" $_tmp" >> $_tmp_fn
;;
userv) #- search /etc/services file
echo "grep --color -Eie \"$_arg1\" /etc/services $_tmp" >> $_tmp_fn
;;
uservers) #- search systemctl list-units --type=service
echo "systemctl list-units --all > $HOME/tmp/ctl.units" >> $_tmp_fn
echo "systemctl list-units --type=service >> $HOME/tmp/ctl.units" >> $_tmp_fn
echo "systemctl list-unit-files >> $HOME/tmp/ctl.units" >> $_tmp_fn
echo "sort -o $HOME/tmp/sys.tmp $HOME/tmp/ctl.units" >> $_tmp_fn
echo "rm --force $HOME/tmp/ctl.units" >> $_tmp_fn
echo "grep --color -Eie \"$_arg1\" $HOME/tmp/sys.tmp" >> $_tmp_fn
echo "rm --force $HOME/tmp/sys.tmp" >> $_tmp_fn
_xlayout=$_xfont
;;
usysctl) #- search /etc/sysctl.d/ /run/sysctl.d/ /usr/lib/sysctl.d/*.conf
echo "echo -e \"\n# $_exe $_cmd_line\"" >> $_tmp_fn
echo "echo -e \"looking in /etc/sysctl.d/*.conf\"" >> $_tmp_fn
echo "grep --color -Eie \"$_arg1\" /etc/sysctl.d/*.conf $_tmp" >> $_tmp_fn
echo "echo -e \"\nlooking in /run/sysctl.d/*.conf\"" >> $_tmp_fn
echo "grep --color -Eie \"$_arg1\" /run/sysctl.d/*.conf $_tmp" >> $_tmp_fn
echo "echo -e \"\nlooking in /usr/lib/sysctl.d/*.conf\"" >> $_tmp_fn
echo "grep --color -Eie \"$_arg1\" /usr/lib/sysctl.d/*.conf $_tmp" >> $_tmp_fn
;;
xmount) #- search mount igoring fs on, cgroup, systemd lines
if [ -z "$_arg1" ] ; then
echo "mount | sort -V | grep -v cgroup | grep -v systemd| grep -v devpts | grep -v sunrpc |
grep -v named | grep -v mqueue | grep -v /fs/ | grep -v \"fs on\" " >> $_tmp_fn
else
echo "mount | sort -V | grep -v cgroup | grep -v systemd| grep -v devpts | grep -v sunrpc |
grep -v named | grep -v mqueue | grep -v /fs/ | grep -v \"fs on\" | grep $_arg1 $_tmp" >> $_tmp_fn
fi
;;
*)
echo "grep --color -Eie '#' $_exe_fn | grep ')' | tr -d '#)' | grep -v ux_fn | sort" >> $_tmp_fn
echo "echo \" ==cmd== - ==== brief description ============================

For any of the above to work I assume you did a
cd $(dirname $_exe)
ln -s $_app each_above_cmd_here
or you need to run $_exe_fn -i

\"
" >> $_tmp_fn
;;
esac

echo "echo \" \"" >> $_tmp_fn
echo "echo \"# Completed: $_app $_cmd_line_args\"" >> $_tmp_fn
echo "read -p \"# hit return to close $_node $_tmp_fn\" var1 " >> $_tmp_fn

echo /bin/rm $_tmp_fn >> $_tmp_fn
chmod +x $_tmp_fn
nohup xterm -title "$_node $_exe $_cmd_line_args" $_xlayout -e $_tmp_fn \
> /dev/null 2>&1 &

#********************* end ux ******************************

[Arlen Holder]

On 02 Oct 2020 18:22:41 GMT, Stéphane CARPENTIER wrote:

> If you have no clue where to look for your file, I agree, you search
> from the root directory and it really takes time. But if you have an
> idea where to search for your files, it's not always that long.
>
> And if your search returns a lot of answers, you have to use a lot of grep
> after your locate and the time taken to display the result reduce the
> difference.

Agreed. All sensible points.

Find works fastest when you know "stuff" about what you seek...
o Locate tends to be more useful when you know less about what you seek.

Each tool has its use model, which is why both always seem to exist.
--
Note: I recall, decades ago, it seems, when "locate/updateb" first came to
our Sun boxes, where I don't remember what the OS version was, but that's
the moment I fell in love with the locate command & almost never used find
since.