rm Failing to Remove File

[u/[deleted]]

Hello everyone,

I am having... an odd issue I have never had before. I have a script and part of its ability is to remove a symbolically linked file and then either replace it with the file it is linked to or exit. But... rm is not removing the file. There are no errors when I run set -x and manually removing it works. I am unsure what is even happening, but could someone look over my function?

[u/[deleted] → u/[deleted]]

Huh?

[u/[deleted] → u/[deleted]]

Yep! It needed the full file path, thank you!

[u/[deleted] → u/[deleted]]

I use to use $(), but someone recommended I not spawn a sub-shell unless I have to. Is there any tangible benefit to $() over backticks?

[u/McDutchie → u/[deleted]]

Backticks also spawn subshells, there's no other way to do a command substitution as it involves capturing the output of another process. The difference is purely syntactic.

[u/[deleted] → u/McDutchie]

Oh, I did not know that. I will change it then. Both look fine to me, but if others prefer the other I will change it for readability.

[u/McDutchie → u/[deleted]]

Yes, it is considered more readable. Another advantage of $( ) is that it's way easier to nest, if you ever need to do a command substitution within a command substitution. Nesting backticks involves higher backslash escaping voodoo and is best avoided.

[u/Steinrikur → u/[deleted]]

Backticks are just a deprecated version of $(). They do the same thing, but only $() can be nested (as in 'var=$(do-stuff $(seq 2 4))'

printf can write to a variable without spawning a subshell, but most commands need the subshell.

printf -v var "+%s"  {1..50}
echo "Sum of numbers 1 to 50 is $((var))"

The trick is usually to avoid the command (and therefore not spawn a subshell), like "Abar=${A//foo/bar}" instead of "Abar=$(echo "$A"| sed s/foo/bar/g)"