Jan Schaumann <[email protected]> writes: > rm(1) currently says for the '-R' flag: > > "If the -i option is specified, the user is prompted > for confirmation before each directory's contents are > processed (as well as before the attempt is made to > remove the directory)." > > But it's actually a bit misleading and only prompts > for _removal_ of a directory, not for processing the > contents: > > $ mkdir -p dir/subdir/subsub dir/subdir2 > $ touch dir/file dir/subdir/file dir/subdir/subsub/file dir/subdir2/file > $ rm -ir dir > remove 'dir'? n > $ > > On macOS, rm(1) behaves like this: > > $ rm -ir dir > examine files in directory dir? y > examine files in directory dir/subdir2? y > remove dir/subdir2/file? n > examine files in directory dir/subdir2/subsub? n > remove dir/subdir2? > > Linux / GNU coreutils likewise: > > $ rm -ir dir > rm: descend into directory 'dir'? y > rm: descend into directory 'dir/subdir'? y > rm: remove regular empty file 'dir/subdir/file'? n > rm: descend into directory 'dir/subdir/subsub'? n > rm: remove regular empty file 'dir/file'? > > That behavior seems to match what the manual page > describes much more than what we do. Should we match > that?
We should ensure that the code and the man page conform to POSIX, unless there's a really good reason, in which the man page should explain and justify the nonconformance. https://pubs.opengroup.org/onlinepubs/9799919799/utilities/rm.html The other systems look conforming. It's a good question how FreeBSD documents -i and processes it.
