4 Answers
4

Using + instead of ; to terminate the -exec action makes it faster by batching the invocations of ls. You can sort by piping through the sort command; tell it to start sorting at the 10th field (the first 9 are the metadata: blocks, permissions, link count, user, group, size, and 3 date/time fields). The option -n tells ls to use numeric values for the user and group, which avoids the risk of user or group names containing whitespace.

Alternatively, with zsh, you can get away with no assumption on any name by using glob qualifiers to collect and sort the files and zargs to run ls multiple times if the command line would be too long. You do need GNU ls (specifically its -f option) to avoid re-sorting by ls (another approach would be to emulate ls with zsh's zstat).

Thank you so much! Using the first command you sent does the sort. Would the number still be 10 if I use a shorter path? For example, if I run the same command from /home/setefgge instead of from public_html ?
–
MaJJul 4 '14 at 16:29

@MaJ 10 is the number of skipped fields, it has nothing to do with the size of the file name.
–
GillesJul 4 '14 at 18:28

Thank you. I appreciate your help, and also the help everyone else provided. I consider this problem solved. My cron command is now sorting the files. This is the first time I ever submitted a question to Stackexchange. I do not see a "Solved" option. If any of you know how to post this as solved, please go ahead and do so. Thanks!
–
MaJJul 5 '14 at 23:19

@MaJ The closest thing we have to marking a question as solved is to mark one of the answers as accepted. Only you, the asker, can do so. To do this, click the check mark next to the answer that helped you most. If you accept an answer, you'll get 2 more reputation points, and after that you will be able to upvote posts; you can upvote all the posts that you found helpful. For more information, see the tour page and the help page on what to when someone answers your question.
–
GillesJul 6 '14 at 18:19

The <date and time> field shall contain the appropriate date and timestamp of when the file was last modified. In the POSIX locale, the field shall be the equivalent of the output of the following date command:

date "+%b %e %H:%M"

...if the file has been modified in the last six months, or:

date "+%b %e %Y"

Taking this into consideration, and ensuring that if there are any newlines in a filename they are properly globbed with the also POSIX specified ls -q option, it is relatively easy to prepare a regex for an ls result without find at all:

Yes, it even works with LS_COLORS - which is probably a low priority for your cron of course, but, hey your options are open.

In any case this offers some significant advantages over some other possible solutions.

In the first place find + ls involves multiple invocations - this only involves a single ls process, and this is why it is able to reliably sort everything - which it does by default - and so sort is also made ancillary.

Any solution involving find and sort and ls is pretty much doing all of the work twice. ls and find will both resolve every pathname and stat every file. ls and sort will both sort all of the results. It is probably best instead to just use the single ls.

Then of course there's the date and sed portions of this answer. What's important to note about that is you do the hard part and get the regex first - and only once - and afterward you only prune a single list of results rather than say, get results, get results, sort results and sort results.

This does not break on filenames containing newlines, as other solutions likely will. This solution does have its own caveats - which I explain next - but they are minute and easily handled. In my opinion, this is the most robust solution here.

There are two cases in which the above command might cause you problems. The first involves the ? globs in the filenames - while as is it is already a more robust solution than any other offered here, and the likelihood that you will encounter a ? at all is small enough on its own, there is a possibility that resolving those globs could match more than one filename. Please see this for more information on this subject.

The other possibility involves a false positive - for instance if you have a filename actually matching the date string for which we are searching with grep but that was not actually modified on either of those days. I am not counting on that being an issue, but, if it is, ask about it and I can probably help you make the regex more specific in order to handle this.

ls does its own sorting, so piping the output of find through sort is useless. Furthermore your command mangles file names containing whitespace (among others) and will fail if there are too many file names.
–
GillesJul 3 '14 at 23:27