Bash Script – batch rename files in current directory with preview

I have written the following script to automate my frequent usage of rename.
This saves me from always typing the whole command to the command line as well as doing a dry run with -n for testing before applying the pattern.

#!/bin/bash

 if [ ! -d ~/.script-history ]; then
     echo -e "Folder .script-history does not exist and gets created... n";
     mkdir ~/.script-history
      && { echo -e "created folder: ~/.script-history n"; }
      || { echo -e "could not create folder: ~/.script-history n"; }
 fi

 history -r ~/.script-history/rename
 set -o vi
 search=""
 replace=""

 echo -e "Please enter token to be replaced: "
 read -e -r search
 history -s "$search"
 echo -e "Please enter replacement: "
 read -e -r replace
 history -s "$replace"
 history -w ~/.script-history/rename

 value=$(rename -n "s/$search/$replace/g" ./*)

 echo -e "$value"

 lines=$(echo -en "$value" | wc -m)

 if [ "$lines" -gt 0 ]; then
     read -p "Do you want to apply changes? [Y]es [n]o " yn
     case $yn in
         [yY]* ) echo "renaming files...";
                 rename "s/$search/$replace/g" ./*
                 && { echo "success :-)"; }
                 || { echo "failed :-("; };;
         [nN]* ) echo "no changes have been made."; exit;;
         * ) echo "Are you kidding me???";;
     esac
 elif [ "$lines" -eq 0 ]; then
     echo -e "No matches found for <$search> !"
 fi

• For making it easier to adjust or reuse the changes done with the script, I added a history, while the first part checks if the folder exists where I save my histories for script files. I do not quite understand this line set -o vi but it is working.
• For me as a beginner it was quite tricky to get the script recognizing whether there are changes to be applied or not. My workaround here is the $lines variable, where I count the output of chars and then process with
  "$lines" -gt 0 or "$lines" -eq 0.

One of the questions I have is about the usage of the A && B || C pipe. I use it quite frequently in my scripts, where ShellCheck reports the following:

SC2015: Note that A && B || C is not if-then-else. C may run when A is true.

The other output of ShellCheck is:

SC2162: read without -r will mangle backslashes.

I think it is ok, since the user is only expected to input YyNn. While I use the script on a daily basis, is the coding sufficient or where can it be improved?

The disadvantage of the script is that you have to type in both search and replacement before it checks if there are matches. An improvement could be to add a function that checks for that and returns to the search input when there are no matches.

Checking if a value is not empty

This is a very complicated way to check that value is not empty:

lines=$(echo -en "$value" | wc -m)

if [ "$lines" -gt 0 ]; then

This is equivalent:

if [ "$value" ]; then

Avoid echo -e

It’s good to avoid all flags of echo, such as -e,
because they are not portable.
Instead of this:

 echo -e "Folder .script-history does not exist and gets created... n";

I recommend to add a second empty echo:

echo "Folder .script-history does not exist and gets created..."
echo

The concern about A && B || C

Shellcheck raised an issue here:

 rename "s/$search/$replace/g" ./*
 && { echo "success :-)"; }
 || { echo "failed :-("; };;

The issue is that if rename succeeds but then echo success fails,
the || will get executed.
You can ignore this issue, because in the unlikely event that the first echo fails, the second (after the ||) is likely to fail too, so it won’t matter.
If you want to be pedantic/bullet-proof, then you have to spell out a proper if-else statement instead of the && ... || chaining.

In any case, the command can be simplified without the grouping:

rename "s/$search/$replace/g" ./* 
&& echo "success :-)" 
|| echo "failed :-(" ;;

I also added spaces in front of the before the line breaks,
to make it perfectly clear that the argument before the is not being continued on the next line.
Without that, this point would be ambiguous, making the script a bit harder to read.

The concern about read without -r

If the user input contains , it may not get preserved.
That’s hardly ever intended,
and probably you would not want that either.
As a rule of thumb,
it’s good to always use read -r.