macOS OSX Delete Script

[VAsRHDHachiRoku]

Hello,

Sorry to ask this, but I'm not much of a OSX person besides the GUI. If it was a Windows machine with PowerShell could have done this in about 5 minutes. Was hoping someone could point me in the right direction on how to create a script to do the following:

/Volumes/Downloads/Completed - Parent Folder

This folder will have child folders
I want to first check the size of the each child folder
If less than 100mb in size
Then move child folder to trash bin

Could someone please assist. I did some searching on the web, but didn't have much luck. I also tried to use the Automator, but this task seems above what the GUI can do.

Thanks

 

[Weaselboy]

I have not tested it, but with a bit of tweaking to get the paths you want, I think this Automator workflow might do the trick for you.

 

[talmy]

I've just tried it. Automator doesn't do it nor will Smart Folders. They seem to think that "size" is only something that files have. Hazel will do it, however. You can download a trial to test it out for yourself. http://www.noodlesoft.com/hazel

I did a Google search, out of curiosity, thinking that the command-line find program would do the job. Turns out that you can write a bash script that does it, but calculating size of a folder's contents ends up having to run an awk script that adds up the size of all the files. It's not an easy "one liner".

 

[chown33]

I did a Google search, out of curiosity, thinking that the command-line find program would do the job. Turns out that you can write a bash script that does it, but calculating size of a folder's contents ends up having to run an awk script that adds up the size of all the files. It's not an easy "one liner".

The 'du' command can do this:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/du.1.html

Restrict it to a depth of 1, and it will output the total size of each dir's contents. That output can be further parsed or manipulated by 'awk', or additional shell commands.

Example:

du -d 1 ~/Documents

There are options that may be useful, possibly even required, such as preventing 'du' from crossing devices (i.e. going into a mounted disk), choices for handling symlinks, formatting and units (MB, GB, etc.).

 

[subsonix]

I've just tried it. Automator doesn't do it nor will Smart Folders. They seem to think that "size" is only something that files have.

Isn't the problem that it doesn't look into sub folders of the stated folder though? If a folder contains less than 100MB of files, then all files in it must be less than 100MB and should be removed individually if the folder was visited by the script. Similarly you could have a folder with more than 100MB of content where each file is less than 100MB.

 

[subsonix]

Restrict it to a depth of 1, and it will output the total size of each dir's contents.

It seems to report blocks used, but I tried to compare it with summing the content and can't get it to match on bytes used.

For example:

$ du -d 1 -h Byte .
616K    .

$ nbytes=0 ; for file in * ; do nbytes=$(( $nbytes + $(stat -f "%z" "$file"))) ; done ; echo $nbytes bytes
348064 bytes

Edit: that loop sums files and directories, however sub directories must also be traversed for it to be correct. So for now, imagine that the folder only contains files.

 

[talmy]

Isn't the problem that it doesn't look into sub folders of the stated folder though? If a folder contains less than 100MB of files, then all files in it must be less than 100MB and should be removed individually if the folder was visited by the script. Similarly you could have a folder with more than 100MB of content where each file is less than 100MB.

That could be an issue, but I couldn't get either Automator or Smart Folders to give me any matches if I added a size constraint of any type (>something or <something didn't matter). Hazel, however, worked.

 

[chown33]

It seems to report blocks used, but I tried to compare it with summing the content and can't get it to match on bytes used.

For example:

$ du -d 1 -h Byte .
616K    .

$ nbytes=0 ; for file in * ; do nbytes=$(( $nbytes + $(stat -f "%z" "$file"))) ; done ; echo $nbytes bytes
348064 bytes

What directory is "." when you run those commands?

If it's your home dir, then 'du' will process every sub-dir, including those whose names start with '.'. A typical home dir has a surprising number of sub-dirs that start with '.'.

The shell pattern '*', however, does NOT include names that start with '.'. You can demonstrate this with:

echo * ; echo ____ ; ls -A1 .

There may be additional reasons for the disparity. The dot-name one is just the first that comes to mind.

 

[subsonix]

What directory is "." when you run those commands?

If it's your home dir, then 'du' will process every sub-dir, including those whose names start with '.'. A typical home dir has a surprising number of sub-dirs that start with '.'.

The shell pattern '*', however, does NOT include names that start with '.'. You can demonstrate this with:

echo * ; echo ____ ; ls -A1 .

There may be additional reasons for the disparity. The dot-name one is just the first that comes to mind.

"." is the current directory to match the wild card in the loop, it's a directory with small scripts only, which is why the size is only ~347KB. Each directory contains a "." and a ".." file, "." refers to the directory itself and ".." to the parent, so you can list the parent by: "ls .." for example.

The disparity, in my opinion seems to come from the fact that blocks used is always going to end up a bigger figure than bytes used unless the blocks are allocated perfectly, which isn't very likely. In my case this is a folder with mostly small scripts so it makes even more sense that there's a lot of "spill", for example a 1 byte file will still occupy a full block.

 

[VAsRHDHachiRoku]

Hazel

Thanks for everyones relies. This is really an awesome forum, I honestly didn't expect this many people to chip in and get this many replies.

I am testing out Hazel and it works great! Most likely I will buy the product after demo period has ended!