Any tool to find files modified on specific days?

Using applications, configuring, problems
Message
Author
musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#21 Post by musher0 »

MochiMoppel wrote:Please stop barking up the wrong awk tree. Three times is enough now. Thank you.
Hey MochiMoppei.

Wait a minute. This is a public thread. It does not belong to you, it belongs to the
Puppy community.

You asked a question and I contributed potential solutions. If you do not like them,
if you do not like tree, awk or piping, that's your problem, not mine.

Rest assured that I will "bark" every time that you ignore or squarely put down the
solutions that I suggest without a valid reason, or that you yourself offer one-track-
minded solutions. You do not have the monopoly of knowledge, and neither do I.

As of this writing, my solutions are better than those that you have presented. My
solutions are clear and they work. I've proven so. Be fair and I'll stop "barking".

Actually, I should be the one demanding apologies from you.

Best regards.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#22 Post by Sailor Enceladus »

@musher0: MochiMoppel's last post was about pfind, which is a GUI by zigbert that doesn't really have much to do with find, except sharing a similar name, and that it can also find things (and possibly using some of the code from find under the hood). I believe he was reporting the bugs/limitations with pfind just out of interest and for information, maybe zigbert will read this thread and fix them, if not then at least it is good (or useful) for others to know. find (not to be confused with pfind) already works great using the code MochiMoppel has posted/expanded upon. Now imagine if zigbert's tool was called ptree instead, we might all be saying use find because tree doesn't work, and you would be the one angered because people are suggesting "you should have used my superior find program because tree doesn't work" when tree really does work, and you already explained that it did, and it's ptree that is messed up (not to be confused with the Pteranodon from Land Before Time :lol: ).

Hopefully you can see from this explanation, that your response here seems a bit out to lunch (in the potatoes?):
musher0 wrote:As I said here, stop losing your time struggling with find and
use the tree + awk combination.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#23 Post by musher0 »

@Sailor Enceladus

Thanks for your intervention.

All I see in MochiMoppei's post and in some posts from others in this thread is that
results with "Find & Co." are incomplete or complicated to obtain.

Also, my suggestions are brushed away without a valid reason. The impression I get
is that those people do not have the intellectual thoroughness or integrity to test
solutions that are beyond their limited habits.

So yeah, I'm defending myself. My solutions and results up to now have been
good, even better than theirs, and they are too darn proud to admit it. Or to practice
"Cartesian doubt", such as: "I don't like musher0's solutions, but maybe he's is on
to something."

What makes me the most angry is not so much the lack of recognition from them
(at my age, i've become thick-skinned about it) as their tone and their indifference to
goal-focused research. With that attitude, they're going nowhere fast. They don't
have the intellectual curiosity to look beyond the fence they have surrounded
themselves with.

Bah. Human nature.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
trapster
Posts: 2117
Joined: Mon 28 Nov 2005, 23:14
Location: Maine, USA
Contact:

#24 Post by trapster »

They don't have the intellectual curiosity to look beyond the fence they have surrounded themselves with.
And that is their choice.
trapster
Maine, USA

Asus eeepc 1005HA PU1X-BK
Frugal install: Slacko
Currently using full install: DebianDog

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#25 Post by musher0 »

trapster wrote:
They don't have the intellectual curiosity to look beyond the fence they have surrounded themselves with.
And that is their choice.
Perhaps, but nobody should have to suffer from it.
Last edited by musher0 on Thu 21 Apr 2016, 18:13, edited 1 time in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

gcmartin

#26 Post by gcmartin »

Frankly, there is good information here.

Last year, we have discussed in the forum about the ability to "locate" files in the file system. @StemSee AND @Musher0 responded with tools that allows anyone, developer or user, to INSTANTLY find files they were looking for.

The problem that they addressed centered around decades old Linux commands that had been stripped out of Bash. Use of those commands gave PUP users instant locations of files without having to have the find command or similarly pfind spend eons of time crawling thru our file systems for the answers we seek.

This year, @Musher0 extended another command which was previously stipped out of Puppy's Bash; namely the Linux "tree" command which brings additional benefits in finding files contained in our filesystems.

I can see what he is trying to get members combing this tread to see. Although he hasn't mentioned the Linux "slocate/locate/updatedb" which he and @StemSee helped with last year (which I think is appropriate in this thread's discussion), he has shown how the Linux "tree" command can help us.

Hopefully, others can see benefit. If our "full" Bash has these commands, like say Lighthouse/FATDOG/Just-Lighthouse have, some of this discussion in this thread would not have occurred.

Look for yourself and evaluate what is a good alternative for yourselves. And, Don't overlook instantaneously locating your files, as well. For some of us, these abilities are a very valuable commodity.

Hope everyone finds benefit in the useful posts that members are offering.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#27 Post by musher0 »

Sailor Enceladus wrote:@musher0:(...) ptree that is messed up (not to be confused with the Pteranodon from Land Before Time :lol: ).
(...)
Cute little thing, that "ptree"! :lol:
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#28 Post by musher0 »

@gcmartin: Thanks for the words of wisdom.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

scientist
Posts: 860
Joined: Sat 23 May 2015, 08:21

#29 Post by scientist »

Impressive and pretty fast. :-)

I do not understand what the sort command does ?

"sort via key" is cryptic.
Thanks,
Andy


Slacko 6.3.0 FULL INSTALL
JWM
File Manager - Thunar

april

#30 Post by april »

musher0
guaranteed to mess up your thread and persist if you don't like his answers

I have found much wisdom in other posters posts here . Thanks

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#31 Post by Sailor Enceladus »

musher0 wrote:
Sailor Enceladus wrote:@musher0:(...) ptree that is messed up (not to be confused with the Pteranodon from Land Before Time :lol: ).
(...)
Cute little thing, that "ptree"! :lol:
Oh yeah, ducky is my favorite :lol:

Like gcmartin said, the more information the better! I always find old posts here that help me out in some way or another.

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#32 Post by MochiMoppel »

Now that the emotions have calmed down it's time for a review.

I started the thread in the hope to find a lightweight GUI file finder, something lighter than Pfind and more comfortable than the raw command line. In the worst case I could roll my own, but I'm lazy and lack the motivation to spend time on a function that I only sporadically use. It seems now that I'll have to settle for the command line with some simple GUI frills. My thanks go to all members who tried to help me. It's not always possible for me to answer each and every contribution but I appreciate them all ...well, almost all:
musher0 wrote:My solutions and results up to now have been good, even better than theirs, and they are too darn proud to admit it ..... those people do not have the intellectual thoroughness or integrity to test solutions that are beyond their limited habits ..... you yourself offer one-track-minded solutions ..... my suggestions are brushed away without a valid reason
Ridiculous accusations, funny judgements and bold statements.

I didn't "brush away" anything, I gave you a short explanation why I regard tree as the wrong tool, still you were trying to sell me your newly discovered toy as the answer to my question over and over again. This is annoying. I heard you the first time, I don't need reminders.

I normally don't give lengthy explanations about solutions I tested and found inadequate, but since you persistently asked for it, let's have a look at your tree+awk construct and see how superior it is.

I understand that your claim of superiority is solely based on your subjective impression that find is "convoluted" and your construct is "simple". I don't share your view, but that's a different story. If your code appears simple then only because you took shortcuts. I'm not interested in all the stuff that tree spills out. I'm interested in file paths (see my screenshot). You would have to add some code to cut the size/date crap. And if you do that you would also have to take care of filenames that include spaces, adding more complexity. Simplicity fades quickly. Here some of the more important issues:
  • Reliability
    Find simply works, your code does not. Even worse: Like Pfind your code only "seems" to work and fools you into thinking that the impressive screenshot you posted depicts a valid result. You don't know what you are missing or should miss: All files smaller than 1K.
  • Flexibility
    Your code can handle only a few days. How am I supposed to find files modified from 2015-04-15 to 2016-02-10? Piece of cake for find, impossible with your code.
  • Functionality
    I need the possibility to find regular files. I hope that this is not an unreasonable requirement. Trapster's proposal and my test code include the find option -type f, which restricts the result to regular files. End of the line for your solution. Not possible with tree.
  • Speed
    You seem to be proud that your solution took less than 10 sec to scan your whole system. What does this prove? On my system tree+awk takes 7 sec. And find? Find finishes the job in about 1 sec.
Bottomline:
Tree is a nice little tool with some unique functions, but its strength is visual representation and not the scan for sophisticated file patterns. It is the wrong tool to be (mis)used as a file finder.
Awk is very powerful and after fixing all bugs and shortcomings of your code the result would even look fairly tidy, but awk can not process data which tree can't deliver.
Find starts where tree+awk ends. Above usage scratches only the surface of find's power.
musher0 wrote:my solutions are better than those that you have presented. My solutions are clear and they work. I've proven so.
You may want to rephrase that.

some1
Posts: 117
Joined: Thu 17 Jan 2013, 11:07

#33 Post by some1 »

@MochiMoppel:

I think you nailed it quite well in the bullets
Reliability .. Bottomline.

And yes - follow the hint trapster gave.
There are much more to the newerXY-test,
than using literal Datetime-specs.

@Musher0:
The use of varying spacing in the TREE-output influences
the field-splitting.Your code does NOT handle that sufficiently.
A first step in bugfixing might be filtering through
sub(/\[/,"",$0);

@All:Stay on topic -please.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#34 Post by musher0 »

I'll accept Mochi's criticism on flexibility and that's it. That said, my one-liner answered
the initial question (modified a little bit by Mochi himself). The initial question was about a
few consecutive days, NOT years.

My speed argument was in reaction to what had been previously tested before that post.
The speed will obviously depend on how many files in total you have on your computer.
Mochi, to be able to compare comparables with more fairness, please state the results
of your find command 1) with < time > and 2) with < wc -l >, like I did.

The precision argument: if you remove the "h" parameter in the parameters used for this
tree one-liner, you get the byte-count, not only the kb-count. Please study tree's
capacities more in depth before jumping to erroneous conclusions and putting down a
very useful utility without reason.

Besides, I doubloe-checked, and that argument has no validity: even with the -h
parameter, tree includes files smaller than 1k in its listing. Please see attached screen
capture as an example.

Your counter-argument concerning "regular files" may be off-track as well: please see
here. The < tree > command respects the normal definition of a "regular file" under Unix.

I came up with my suggestion because the posters before me seemed to have
problems finding files with find according to time with the parameters allowed by find.
I am not a specialist of find, and cannot conclude with certainty whether the cause of
that was limitations within find itself or the lack of experience the posters have with find.

@some1
No need for the sub (or "substitute") function in such a simple awk command: the new
awks consider multiple consecutive spaces as one space: it's built-in. Therefore, my
one-liner does not contain any "bugs".

@all: a new version of find (4.6.0) came out in late December of 2015. I made it available
here yesterday.

BFN.
Attachments
tree-less_than_1k.jpg
(50.72 KiB) Downloaded 433 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#35 Post by MochiMoppel »

musher0 wrote:Mochi, to be able to compare comparables with more fairness, please state the results of your find command 1) with < time > and 2) with < wc -l >, like I did.
Here are the exact commands I used for the comparison:

Code: Select all

tree -Dfia --timefmt "%Y%m%d" /  | awk  -F'[(\\]|\\[| )]+' '{if ( $2 >= 20160414 && $2 <= 20160415 ) print $3 }'
find / -ignore_readdir_race -newermt "2016-04-13 23:59:59" ! -newermt "2016-04-15 23:59:59" | sort
As you can see I took the liberty to add date flexibility. I removed the sort command from tree+awk and added one after find to come up with comparable output. This and the fact that I didn't yet fix the filename space issue, which would require a loop withing awk, gives the tree+awk solution even a small speed advantage. So much for fairness. Because of the overhead involved the time gap will shrink from 7:1 down to around 2:1 when the search is applied to only a single directory, but my point is that find will always be faster
musher0 wrote:The precision argument.....Please study tree's capacities more in depth before jumping to erroneous conclusions and putting down a very useful utility without reason.
Oh boy, still the same attidude. The problem here is not with tree's capacities to display small files, the problem is with your awk code to correctly process tree's output. You would easily see the problem if you would test your tree+awk code (not tree+grep!) with small files. And before you brush aside some1's bug fix, try to understand his solution. I leave it to him to explain it to you. I'm exhausted.
musher0 wrote:Your counter-argument concerning "regular files" may be off-track as well
tree always displays symbolic links. Symbolic links are not regular files.
tree always displays directories. Directories are not regular files.
So how am I supposed to display only regular files?

Edit
For the record and those who are still interested: The problem of spaces in file names can probably be solved without looping. Eliminating space as a field separator should do. Awk seems to accept string patterns, not just single characters as field separator:
awk -F'(\\[|\\] *)' '{if ( $2 >= 20160414 && $2 <= 20160415 ) print $3}'
 
 
Last edited by MochiMoppel on Mon 25 Apr 2016, 09:38, edited 1 time in total.

gcmartin

#36 Post by gcmartin »

Question
Would the time command evaluate the total expression or just the 1st parts of each?

Code: Select all

time tree -Dfia --timefmt "%Y%m%d" /  | awk  -F'[(\\]|\\[| )]+' '{if ( $2 >= 20160414 && $2 <= 20160415 ) print $3 }'

time find / -ignore_readdir_race -newermt "2016-04-13 23:59:59" ! -newermt "2016-04-15 23:59:59" | sort 

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#37 Post by MochiMoppel »

The total expression (= the whole pipeline).

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#38 Post by musher0 »

@MochiMoppei
I guess we both got an attitude! :lol:

But finally you condescended to provide the reasons behind your position. That's
a step in the right direction. Communication and explanation of the material are as
important as the material. Otherwise the material does not get properly understood
or even known.

In that spirit, please provide an understandable link or reference to where you
learned what "regular files" are. Authority arguments are worth nothing if not
substantiated by some science or by some experience.

This should apply even if someone -- not just you, I really mean "anyone" -- had
a degree in computer science. Please understand that no elitist explanation will be
passing this electronic door. In clear terms: there is no knowledge unless it is
properly communicated.

Thanks in advance.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#39 Post by musher0 »

@MochiMoppei:
I don't see why you keep finding fault with my awk formulas.
The one-liner in the attached works as well as your hair-splitting.

Best regards.
Attachments
tree-less_than_1k(1).jpg
(50.85 KiB) Downloaded 353 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

Re: Any tool to find files modified on specific days?

#40 Post by musher0 »

MochiMoppel wrote:I'm looking for a tool which can list all files modified on specific days, e.g. all files modified from April 14th to April 15th. The tool should be able to scan a set of directories, not just recursively a single directory.
Any ideas?
Hi MochiMoppei.

Outlining of your words "all files" in the quote above is by me.

Just a refresher of your original question. You did not say "all regular files", you said
"all files". You cannot change the parameters of your question at will and then
find fault with people's solutions.

There's a very precise name for that in the vocabulary of... ethics. Go look for it.

I rest my case. I'm out of here. I've got no more time to lose.
Last edited by musher0 on Wed 20 Jun 2018, 13:57, edited 1 time in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

Post Reply