0

Why would I want to use the command

rm -rf "`pwd`/folder"

instead of

rm -rf ./folder

What reasons are there to prefer one over the other?

ilkkachu
  • 138,973
  • Did someone delete all the comments here, or is the site doing something weird? – Hack Saw Jul 08 '20 at 23:23
  • 1
    @HackSaw Comments are often deleted by the posters, and sometimes by a moderator if they no longer serve a purpose (remember they are described as "transient information" in the documentation). This is often the case when comments are either better posted as answers, or when they have spun into an idle discussion. – AdminBee Jul 09 '20 at 07:48
  • Thanks, @AdminBee. Never actually seen it happen before. Makes sense. – Hack Saw Jul 09 '20 at 16:38

1 Answers1

5

rm -rf "`pwd`/folder" is bad and you shouldn't use it. It's only bad due to a corner case, but this corner case could turn out to be a security issue leading to deleting the wrong directory. The corner case is if the current directory ends with a newline character: the command substitution strips trailing newlines, so if the current directory is /some/where/strange⏎ (where ⏎ stands for a newline), this command would delete /some/where/strange instead.

The variant rm -rf "$PWD/folder" has no downside over using the pwd command, and has the advantage that it doesn't suffer from the corner case of a trailing newline. Every Bourne/POSIX shell updates the PWD variable after each directory-changing command (cd, pushd, etc.) and it has the same value that the pwd built-in command outputs. (The external pwd command might have a different output, but 1. pwd calls the built-in if there is one and all common shells have one, and 2. there is no advantage to using the external command here anyway.)

rm -rf "$PWD/folder" has no advantage over rm -rf ./folder, however. It has the theoretical downside that rm -rf "$PWD/folder" might go over the maximum command line length while rm -rf ./folder fits. However the maximum command line length is almost always significantly larger than the maximum file path length, so a command with a single path pretty much always fits.

Using "$PWD/$foo" instead of "$foo" has the advantage that it's guaranteed not to start with a dash, so it won't look like an option. That's not an issue if the path is spelled out explicitly in the script, only when it's a variable. And "./$foo" offers the same protection. Both "$PWD/$foo" and "./$foo" are correct only when $foo is a relative path. So rm -rf "$PWD/$foo" has no advantage over rm -rf "./$foo". And as seen above, if there are many paths involved, using the shorter relative form can help to stay under the command line length limit.

Using "$PWD/folder" has a clear benefit over "./folder" if you're storing it in a variable for later use: it keeps designating the same file even if the script changes to another directory in the meantime. While rm -rf "./folder" is perfectly fine, code like this requires an absolute path:

output_directory="$PWD/output"
# If interrupted, delete the partial output.
trap 'rm -rf "$output_directory"; exit 1' HUP INT TERM

do_stuff >"$output_directory/file1" do_more_stuff >"$output_directory/file2" cd "$output_directory" further_stuff file1 file2 >file3

If $output_directory was a relative path, the cleanup code could work before the cd command or after, but not both.

  • 2
    Another corner case arises if the current working directory is moved (e.g. mv ../this ../new). But I guess that advantages and disadvantages of PWD (which will still be /path/to/this) and . (which will refer to new) would depend on the specific use case. – fra-san Jul 08 '20 at 21:53