Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 18 Jul 2018, 09:03
All times are UTC - 4
 Forum index » House Training » Users ( For the regulars )
Any tool to find files modified on specific days?
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 3 of 3 [44 Posts]   Goto page: Previous 1, 2, 3
Author Message
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1528

PostPosted: Thu 21 Apr 2016, 15:58    Post subject:  

musher0 wrote:
Sailor Enceladus wrote:
@musher0:(...) ptree that is messed up (not to be confused with the Pteranodon from Land Before Time Laughing ).
(...)

Cute little thing, that "ptree"! Laughing

Oh yeah, ducky is my favorite Laughing

Like gcmartin said, the more information the better! I always find old posts here that help me out in some way or another.
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1549
Location: Japan

PostPosted: Sun 24 Apr 2016, 07:08    Post subject:  

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.
Back to top
View user's profile Send private message 
some1

Joined: 17 Jan 2013
Posts: 81

PostPosted: Sun 24 Apr 2016, 14:05    Post subject:  

@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.
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12399
Location: Gatineau (Qc), Canada

PostPosted: Sun 24 Apr 2016, 14:57    Post subject:  

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.
tree-less_than_1k.jpg
 Description   
 Filesize   50.72 KB
 Viewed   339 Time(s)

tree-less_than_1k.jpg


_________________
musher0
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1549
Location: Japan

PostPosted: Mon 25 Apr 2016, 00:37    Post subject:  

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:
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, 05:38; edited 1 time in total
Back to top
View user's profile Send private message 
gcmartin

Joined: 14 Oct 2005
Posts: 6730
Location: Earth

PostPosted: Mon 25 Apr 2016, 00:57    Post subject:  

Question
Would the time command evaluate the total expression or just the 1st parts of each?
Code:
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

_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engines or use DogPile
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1549
Location: Japan

PostPosted: Mon 25 Apr 2016, 01:05    Post subject:  

The total expression (= the whole pipeline).
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12399
Location: Gatineau (Qc), Canada

PostPosted: Mon 25 Apr 2016, 03:56    Post subject:  

@MochiMoppei
I guess we both got an attitude! Laughing

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
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12399
Location: Gatineau (Qc), Canada

PostPosted: Mon 25 Apr 2016, 04:35    Post subject:  

@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.
tree-less_than_1k(1).jpg
 Description   
 Filesize   50.85 KB
 Viewed   255 Time(s)

tree-less_than_1k(1).jpg


_________________
musher0
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12399
Location: Gatineau (Qc), Canada

PostPosted: Mon 25 Apr 2016, 04:51    Post subject: Re: Any tool to find files modified on specific days?  

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.

_________________
musher0
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)

Last edited by musher0 on Wed 20 Jun 2018, 09:57; edited 1 time in total
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 2471
Location: Cradle of Humankind

PostPosted: Mon 25 Apr 2016, 05:27    Post subject:  

Slightly off topic but still looking for an application to find files in real time like "everything" the Windows programme. I want results as I'm typing the query.
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1549
Location: Japan

PostPosted: Mon 25 Apr 2016, 20:27    Post subject:  

musher0 wrote:
The one-liner in the attached works as well as your hair-splitting.

Do you really find it funny to garnish ignorance with insults?
I took it for granted that you would test your original code.

To filter files that match the month "Apr" your original code uses the condition $2=="Apr".
When tree outputs a line like
[1.3K Apr 15 2:58]  /path/to/file1
awk sees 5 fields. The month is the 2nd field, so $2=="Apr" will match.

In case of small files tree will output
[    9 Apr 15 2:58]  /path/to/file2
awk sees 6 fields. The bracket is the 1st field, the size (here 9 bytes) is the 2nd and the month has now become the 3rd field. $2=="Apr" will not match. You will never see small files in your search results, not for April or any other month. Never! This is bad. This is a bug!
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12399
Location: Gatineau (Qc), Canada

PostPosted: Mon 25 Apr 2016, 22:04    Post subject:  

Thank you your bringing that quirk to my attention. I had not anticipated it.

Solution:
If we remove the "h" parameter from the tree command, only bytes, not composites, are
shown in the size field. Then all the fields provided by < tree > remain at the same
position whatever the size of the file.

What is left to do is to push up all < awk > fields by one. We do not have to impose a
special field delimiter to awk if we simply want to see a general list of files with their date.

If we want to show the entire line, the awk { print } statement is not required. If we want
to see only the filenames with their path, we will add { print $NF } exactly before the
second apostrophe.

Since a date is a number, we need to add the -n parameter in the < sort > section before
mentioning the field to sort on.

The DIR variable can be defined beforehand or stated directly. Like so:
Code:
DIR=" < Whatever is needed > " # Can be /, ~, /usr, /opt, etc.
tree -Dfis $DIR | awk '$3=="Apr" && $4 ~ /14|15|16/ && $5 ~ /:/' | sort -n -k 4

Depending on the goal we are seeking,
-- one or more parameters, such as -a, -x, -p or --timefmt=%Y-%m-%d, etc., may need
to be added to the < tree > parameters already used;

-- similarly concerning the field delimiter and/or other operations in the < awk > section;

-- finally we may wish to change the column of the < sort > to bring one field or another
into focus -- and remove or keep the -n parameter if that field is alphabetical or numeric.

For example, if we wish to limit the list to
-- files only, leaving out symlinks and directories,
-- in /opt,
-- modified on April 14, 15 and 16 of this year, and
-- see only the filenames with their path,
-- sorted alphabetically,
we could use the following one-liner:
Code:
tree -Dfisp /opt | awk '$3=="Apr" && $4 ~ /14|15|16/ && $5 ~ /:/ && $1 !~ /d|l/ { print $NF }' | sort
Since the permissions information provided by the -p parameter in < tree > is tacked
directly against the beginning bracket, the previously stated < awk > section does not
need to be altered (except for the addition of { print $NF }). However, since in this case
we are sorting alphabetical material on a single column, a simple < sort > at the end will
do the job.

Best regards.

_________________
musher0
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
hamoudoudou


Joined: 24 Jul 2014
Posts: 1317
Location: rabat

PostPosted: Wed 20 Jun 2018, 04:28    Post subject: mtime with pfind works well  

mtime with pfind works well / sort result by date size by click on the concerned column..
* means all then tick mtime and choose dates
Atime access time
Ctime changed time
time.jpg
 Description   too many results found !
 Filesize   9 KB
 Viewed   44 Time(s)

time.jpg

Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 3 of 3 [44 Posts]   Goto page: Previous 1, 2, 3
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Users ( For the regulars )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.2113s ][ Queries: 13 (0.0154s) ][ GZIP on ]