# chmod all .htaccess files under all website dirs under public_html dir

This is my code to chmod all .htaccess files under all website dirs under public_html dir.

The reason I use this code is to make sure WordPress plugins won't "freak out" and change my .htaccess file undesirably.

This is a shared server environment so I can't access htppd.conf instead, and must edit the different .htaccess files per each site, with the below code:

for dir in "$HOME"/public_html/*.{com,co.il}/; do if pushd "$dir"; then
chmod 644 .htaccess
popd
fi
done 2>/dev/null


Instead of manually scanning each files and directory and testing if they are a directory using pushd, I would directly try to target .htaccess files using find:

find "$HOME"/public_html/*.{com,co.il} -name ".htaccess"  Then, to apply the proper permissions, you can use the -exec option of find: find "$HOME"/public_html/*.{com,co.il} -name ".htaccess" -exec chmod 644 {} \;


I don't understand why redirect the loop's stderr to /dev/null. What do you expect to go wrong there? If the chmod fails, I think it would be better to know about it than to quietly ignore. Same for pushd. If there are no matching files, that will lead to pushd on the literal unmatched pattern, which will probably fail. If you want to avoid the loop in case nothing matches the glob pattern, you could do shopt -s nullglob before the loop.

In any case, you don't need a loop to do this, you can use a single chmod command:

chmod 644 "\$HOME"/public_html/*.{com,co.il}/.htaccess


This will fail if there are no matches of the glob pattern, but well, isn't that good like that? If it isn't, then you can do as you did in your script, and redirect stderr.

• +1. You are right, the stderr redirection is indeed redundant, if something goes wrong (no .htacess files under a given dir), which shouldn't happen, it is best to have an error. – user9303970 Jun 21 '18 at 1:21