Shell script for renaming files (lowercase & remove spaces)

[pattulus]

I cleaned up my Hazel folders pane. Now I have several rules which deal with files in subfolders. Hazel can't run rules on these files in the bottom "Do the following to the matched file or foler" section. So I target them via a "Run shell script" action.

Adding this variable at the top to my shell script allows me parse the files in a subfolder:

Code: Select all

path=`dirname "$1"/sub_dir`

In Terminal I can run:

Code: Select all

for i in "$path"/*.png; ${binaries}/mogrify -resize 640x800\> "$path"/*.png

I haven't found a way to make Hazel understand the "for" command and since it targets each file anyway I can write:

Code: Select all

/usr/local/bin/mogrify -resize 640x800\> "$path"/*.png

Using "for" would give me more flexibility. So far I could work around it, but now I'm facing a problem when trying to rename files – more specific: making them lowercase and replacing spaces with dashes.

I have to do this because some of the shell scripts won't accept files with spaces in their name. "for" dealt with this beautifully in Terminal, but I guess for Hazel I have to rename them.

This works in Terminal for one part of what I want (the elimination of spaces):

Code: Select all

for f in *; do mv "$f" "$(echo $f | sed 's/ /-/g')"; done

What I tried so far is:

Code: Select all

mv "$path"/* | sed 's/ /*/g'




Code: Select all

mv "$path"/* "$(echo $path | sed 's/ /-/g')"

I try to keep it to one rule and not create additional an additional "Run Rules On Folder Content" - in addition I simply want to understand how I can work more with Hazel and shell scripts.

I learned a lot in last week when setting up a (at least for me) complex set of rules which rely heavily on shell scripts. This forum gave me many clues and I found the posts from a_freyer very helpful. I'm eager to post about it, but for now I need this last puzzle solved. Any help is appreciated.

Update:

I found another script which I tried to modify to work with Hazel - also with no success:

Code: Select all

#!/bin/bash
FILES=/path/to/dir/*
for f in $FILES
do
new_file=`echo $f|sed "s/ /-/g"`
if [ "$f" != "$new_file" ]
then
mv "$f" "$new_file"
fi
done
exit 0

[a_freyer]

Thanks for the shout out! :-)

Question - is there any particular reason you're not embracing multiple Hazel rules? I understand this may be a matter of preference, but I'm curious as to why.

Alright, lets take these script issues one at a time:

Code: Select all

for i in "$path"/*.png; ${binaries}/mogrify -resize 640x800\> "$path"/*.png


First things first, this has some syntax issues. I do not have ImageMagik installed anymore, so I can't test expressly. But on first blush, you're not using this for loop at all. IIRC, passing a wildcard to mogrify will rename every file in the folder. In effect, you're modifying every file in the directory for each loop iteration. If you have 100 files, you ask mogrify to resize each file 100 independent times. I anticipate mogrify skips resizing if no change is necessary, but still...

If you want to name files individually, you should pass the for loop iterator $i (also note do and done):

Code: Select all

for i in "$path/"*.png;do ${binaries}/mogrify -resize 640x800 "$i"; done


QUESTION - Now why are we replacing the spaces in names? Which binary can't accept a quoted path?


Now, for:

Code: Select all

for f in *; do mv "$f" "$(echo $f | sed 's/ /-/g')"; done

You are asking sed to replace every space in the filename of the current directory. The reason this works in terminal is that you have cd'd to the directory. In Hazel, you will have to cd to the subfolder you are interested in (again, untested, but this should work):

Code: Select all

cd "$path"; for f in *; do mv "$f" "$(echo $f | sed 's/ /-/g')"; done

Your last script is not working for the same reason as stated above. Make sure to change directories since you are working with base filenames.

[pattulus]

First and foremost: THANKS in all caps – this helped me get everything going without any stopgaps.

Question - is there any particular reason you're not embracing multiple Hazel rules? I understand this may be a matter of preference, but I'm curious as to why.

Well, I got a main folder with several subfolders. One part of me didn't want to clutter up the rules section with additional rules for the "Run Rules On Folder Content" macros and the other part wanted to figure out how to do this with shell scripts - the learning by doing approach works great for me, although it took a lot of time in some cases. I still have a lot of reading to do when it comes to scripting. By the way: I finally learned how to "Run Rules On Folder Content" more intelligently a couple of days ago which opened a new world of possible us cases for me. Great stuff.

But on first blush, you're not using this for loop at all. IIRC, passing a wildcard to mogrify will rename every file in the folder. In effect, you're modifying every file in the directory for each loop iteration. If you have 100 files, you ask mogrify to resize each file 100 independent times. I anticipate mogrify skips resizing if no change is necessary, but still...

That was exactly what really stressed me. I had a workaround which most of the time worked – until I chained too many commands. The way you explained it is definitely how it is supposed to work. You might have noticed that I haven't grasped the concept of when to use which variable. Passing the "$path/"*.png" was the only way I got the scripts working and I was unsure how to break the loop and address files individually. Good to know how to use variables properly - again, I need to setup some more scripts to test the waters.

QUESTION - Now why are we replacing the spaces in names? Which binary can't accept a quoted path?

I had this problem for instance with pngquant when not running it through a for-loop. Since you showed me how to write them properly that's of the table. I still plan on using sed to prepare images for web usage.

Dear sir, you really deserve a Hazel support award. I'm so glad I learned something and got the thing working which I worked on the last couple of days.

[a_freyer]

I'm glad that the problems were solved!

Compliments are always nice too. :-)