Note that using yellow text on a white or gray background produces text that is almost invisible to an old guy like me with glaucoma.

Note that when you ask how a segment of code is going to behave, failing to EXACTLY copy the code about which you have questions wastes everybody's time (especially yours).

Note that when trying to get some code working, you usually NEED to set up a test bed where you have files with similar (preferably identical) names in file hierarchies that mimic the file hierarchies your script will be processing. For example, your script looks at files in the directory named by the variable CARTELLA_BACKUPS. Set up a copy of the files in that directory in another directory and change the way CARTELLA_BACKUPS is set to point to your test bed copy of those files while you are debugging your script. That way you can run your code and see what it does and not have to worry about destroying anything.

The shell's set -xv command is your friend when trying to figure out what code is doing. Once you issue that command, every command bash executes after that will be copied to your script's standard error output with all of the variables expanded so you (and us, if you need our help) can see clearly what the shell is trying to do for you.

Note that the on-line manual pages for your system are your friends too. The command man sed will display the manual page for sed on your system so you can read all about what it is supposed to do. If you look at the sed manual page you will find that the command I asked you to run:

Code:

echo -n $(listUniqueBackups) | sed "s//\\\|g"

will NEVER destroy anything in any file unless you redirect its output to a file or invoke it with the -i option (neither of which is the case here).

When I run that command on my system running macOS Mojave (version 10.14.5) without creating a function or utility named listUniqueBackups first, bash prints the diagnostic messages:

Code:

sed: 1: "s//\\|g": unterminated substitute in regular expression
bash: listUniqueBackups: command not found

If we use the real command that is in your script instead of the code you asked us about in post #3 in this thread and I feed it a fixed string containing a <newline> character, then I get the diagnostic message:

Code:

 echo a b c | sed "s//\\\|/g"
sed: first RE may not be empty

Maybe you'll get a similar diagnostic and you'll know that you have to actually supply an RE for sed to match. Maybe your version of sed will assign some meaning to an initial search for the empty RE (which is not mentioned on the Linux 2.6 commands sed man page and we'll be able to figure out what it is that it does, if you run the command and show us the output. If you're not willing to help me figure out how utilities behave on your system, then I'm afraid there is nothing I can do to help you.

Also note that if you change the line in your complete script:

Code:

rm -rf ${file_da_cancellare}

to:

Code:

echo rm -rf ${file_da_cancellare}

there won't be anything in your script that creates or removes any permanent files. It will be perfectly safe to run without even setting up a shadow file hierarchy.

Have you tried asking the person who gave you this code how the pieces of it that you don't understand are supposed to work?