1

I've a folder used by imapsync to store its own cache. Such a folder contains a subfolder for each of the mailbox I'm syncing, and nothing more:

[dv@monitor] find * -maxdepth 0 -type d | wc -l
126
[dv@monitor] find * -maxdepth 0  | wc -l
126

Every subfolder replicates the mailbox structure of the related user/mailbox (note: imapsync keeps track of the destination mail-server, so it adds also a reference to it, kept as an additional folder structure: 10.0.1.235 in the examples below).

[dv@monitor] find director -type d
director
director/10.0.1.235
director/10.0.1.235/director
director/10.0.1.235/director/Deleted Items
director/10.0.1.235/director/Deleted Items/Deleted Items
director/10.0.1.235/director/Contacts
director/10.0.1.235/director/Contacts/Contacts
[....]
director/10.0.1.235/director/INBOX
[...]

Inside every subfolder imapsync store a file for each of the messages sync-ed:

[dv@monitor] ls -l segreteria/10.0.1.235/segreteria/INBOX/INBOX | head -n 10
totale 0
-rw-r--r-- 1 root root 0 19 set 23:36 1000_109
-rw-r--r-- 1 root root 0 19 set 23:36 10009_1342
-rw-r--r-- 1 root root 0 19 set 23:36 10011_1343
-rw-r--r-- 1 root root 0 19 set 23:36 10013_1344
-rw-r--r-- 1 root root 0 19 set 23:36 10028_1345
-rw-r--r-- 1 root root 0 19 set 23:36 10042_1346
-rw-r--r-- 1 root root 0 19 set 23:36 10046_1347
-rw-r--r-- 1 root root 0 19 set 23:36 10048_1348
-rw-r--r-- 1 root root 0 19 set 23:36 10050_1349

Now, as I'm currently troubleshooting imapsync issues, I need to quickly identify mailboxes that have surely had problems with syncing. Basically, I simply need to count the number of files stored within each of first-level folders.

As I'm a fan of the "find is a great program. Learn of it!" concept, my first guess have been something like:

[**NOT WORKING**] find * -type d -maxdepth 0 -exec 'find {} -type f | wc -l' \;

but it didn't worked.

After more than 30 minutes of internet-based-searching-and-learning, and even after reading this other StackOverflow post, I've been (mildly) successful with:

find * -maxdepth 0 -type d -exec sh -c "echo -n {} ; echo -n : ; find {} -type f | wc -l" \;

Please note that, in the above find the first {} got correctly expanded by the first-level folder name, while the second {} got correctly expanded with each of the file herein contained.

Unfortunatly the output is in the form <mailbox>:<number_of_messages> like:

 director:25
 sv:25
 segreteria:11532
 registration:146
 newsletter:240

What I was still missing is a trivial form to sort the output, based on the number of messages. Should the output be reversed (<number_of_messages>:<mailbox>), a simple:

 .... | sort -n

would have solved my needs, with only 9 additional characters.

So I tried changing the order of the echo inside the nested find. Something like:

[**not working**] find * -type d -maxdepth 0 -exec sh -c "find {} -type f | wc -l ; echo -n : ; echo -n {} ;" \;

but it didn't worked, probably due to the need to expand {} in reverse order (first occurrence of {} being expanded by second find; second occurrenct of {} being expanded by first find).

So, after all of above introduction, can someone point me how to adapt this (properly working) one-liner:

find * -maxdepth 0 -type d -exec sh -c "echo -n {} ; echo -n : ; find {} -type f | wc -l" \;

in such a way to reverse the output (<number>:<mailbox> or, even better <number><space><mailbox>)?


(P.S.: obviously there are plenty of ways to achieve this very goal. As for myself, I would have no problem in firing a 3/4 lines perl-script to split/reverse the output of each line. I'm interested in solutions that will require a "slight-addition" of characters; something like | sort -n. Anyway every hints/suggestions, are welcomed)

1 Answer 1

1

Instead of trying to adapt the output of your nested find oneliner to the default behaviour of sort, I propose you tell sort where to find the sorting key:

... | sort -t: -k2n

This is of course assuming that none of your first-level directory names contains a colon.

1
  • Based on the -d/-f parameter of the cut command, I searched for something similar within sort man pages. Even if I regularly rely on the -n and -k options of sort, I (unforgivebly) missed the -t you mentioned in your answer. Thanks for pointing it. I promise to be a better man-page-reader, from now on :-) Sep 21, 2015 at 19:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .