[SOLVED] rename HIDDEN files recursively

grail · 07-30-2011, 08:55 PM

Could you explain why you feel the brackets are necessary?

mrmnemo · 07-30-2011, 10:23 PM

Sure,
I seem to remember reading somehting about the way that bash interpets a line. I guess a way of telling bash to read the brackets as part of the commands rather than to enclose another command. er, thats why.

David the H. · 07-30-2011, 11:24 PM

If you have bash version 4 or higher, then here's a solution that doesn't require find or any other outside tool. It should also work fine with any unusual filename characters, as it relies only on simple shell globbing.

Code:

#!/bin/bash

shopt -s dotglob globstar

files=( ./** )

for file in "${files[@]}" ; do

     path="${file%/*}"
     name="${file##*/}"

     if [[ ! -f $file || ! $name == .* ]] ; then
          echo "skipping $file"
          continue
     else
          mv "$file" "$path/${name#.}"
     fi

done

exit 0

David the H. · 07-31-2011, 12:37 AM

Quote:

Originally Posted by mrmnemo

Sure,
I seem to remember reading somehting about the way that bash interpets a line. I guess a way of telling bash to read the brackets as part of the commands rather than to enclose another command. er, thats why.

Except that grail's question was about why you want to do this in the first place. Parentheses in find are only needed to group expressions together to enforce precedence. In this case it appears you simply want both tests to be evaluated equally, so they are unnecessary. Just use...

Code:

find /media/music/ -depth -name "*.m4a" -o -name "*.wma

But to answer your actual question, $(..) is a subshell. Simply treat everything inside it as if it were on a separate line.

Code:

for f in $( find /media/music/ -depth \( -name "*.m4a" -o -name "*.wma \) )

Also note that $((..)) is a separate operator that expands arithmetical expressions.

Finally, it may have been mentioned before, but a for loop is not recommended when the input is from a command that generates filenames or other strings that can include spaces. This is because for reads each word as a separate input, and can't distinguish lexical whitespace from syntactical whitespace (at least not without futzing about with IFS).

Use a while+read loop instead, with process substitution for input. Since read works on a per-line basis, rather than per-word, each line from find will be safely accepted as the complete filename that it is (barring the unlikely possibility of encountering a filename that itself contains a newline character).

Code:

while read f ; do
     your commands
done < <( find /media/music/ -depth -name "*.m4a" -o -name "*.wma" )

mrmnemo · 07-31-2011, 11:02 PM

Quote:

Originally Posted by David the H.

Except that grail's question was about why you want to do this in the first place. Parentheses in find are only needed to group expressions together to enforce precedence. In this case it appears you simply want both tests to be evaluated equally, so they are unnecessary. Just use...

Code:

find /media/music/ -depth -name "*.m4a" -o -name "*.wma

But to answer your actual question, $(..) is a subshell. Simply treat everything inside it as if it were on a separate line.

Code:

for f in $( find /media/music/ -depth \( -name "*.m4a" -o -name "*.wma \) )

Also note that $((..)) is a separate operator that expands arithmetical expressions.

Finally, it may have been mentioned before, but a for loop is not recommended when the input is from a command that generates filenames or other strings that can include spaces. This is because for reads each word as a separate input, and can't distinguish lexical whitespace from syntactical whitespace (at least not without futzing about with IFS).

Use a while+read loop instead, with process substitution for input. Since read works on a per-line basis, rather than per-word, each line from find will be safely accepted as the complete filename that it is (barring the unlikely possibility of encountering a filename that itself contains a newline character).

Code:

while read f ; do
     your commands
done < <( find /media/music/ -depth -name "*.m4a" -o -name "*.wma" )

Wow, thanks you so much. That makes things a lil easier for me to wrap my head around. Could you point me to a book that would be linear in how it goes through bash? I have looked at the bash cook book and it leaves me spun around a little bit. Nominal Animal posted the wiki link for gaining a better grasp of regex ( thanks). Any ways, thanks guys. I have a new job which I will be using bash much more. This is all very helpful.

Ollie

chrism01 · 07-31-2011, 11:46 PM

Some good links for bash
http://rute.2038bug.com/index.html.gz
http://tldp.org/LDP/Bash-Beginners-G...tml/index.html
http://www.tldp.org/LDP/abs/html/

David the H. · 08-01-2011, 09:19 AM

This is my usual list of bash scripting references:

http://mywiki.wooledge.org/BashGuide
http://www.linuxcommand.org/index.php
http://mywiki.wooledge.org/BashFAQ
http://mywiki.wooledge.org/BashPitfalls
http://tldp.org/LDP/Bash-Beginners-G...tml/index.html
http://www.tldp.org/LDP/abs/html/index.html
http://www.gnu.org/software/bash/manual/bashref.html
http://wiki.bash-hackers.org/start

Definitely read the first one at least. It covers in fair detail all the basic concepts you need to know. Follow sublinks too; the whole site is a treasure trove of bash info.

Speaking of which, I need to retract something from my last post. After writing it, I came across their find tutorial, and it seems that parenthetical grouping can be more important than I had thought (see section 10).

http://mywiki.wooledge.org/UsingFind

mrmnemo · 08-01-2011, 10:02 AM

@chrism01 and David the H : bookmarked and scanned real fast. Thanks for taking the time to post that guys.

grail · 08-01-2011, 07:03 PM

Quote:

Speaking of which, I need to retract something from my last post. After writing it, I came across their find tutorial, and it seems that parenthetical grouping can be more important than I had thought (see section 10).

Don't beat yourself up too hard on this one David as the current example given would not have fallen prey to the issue
mentioned here. In saying that, thanks for the find as I did not know that detail before

David the H. · 08-02-2011, 07:03 AM

Nah, I'm not "beating myself up" over it. There's always something new to learn, after all, and that sometimes means unlearning wrong stuff too.

I'm mostly just keeping myself honest, and trying to avoid giving bad advice. While the specific example above isn't affected, it would only take a small modification, such as adding an -exec command, to make it vitally important.

grail · 08-02-2011, 05:40 PM

True enough

isoneguy · 09-17-2012, 05:20 AM

I wasn't able to get any of these previous resolutions to work in CentOS.

With a little digging I came to this conclusion:

find ./ -depth -name '.*' -exec bash -c 'mv {} $(echo {} | cut -c 4-)' \;

It might be a little hacky but it successfully renames hidden files and folders within your current directory to not be hidden(unfortunately it doesn't currently work recursively).