1

From the manual of coreutils:

Some GNU programs (at least cp and mv) allow you to remove any trailing slashes from each source argument before operating on it. The --strip-trailing-slashes option enables this behavior.

This is useful when a source argument may have a trailing slash and specify a symbolic link to a directory. This scenario is in fact rather common because some shells can automatically append a trailing slash when performing file name completion on such symbolic links. Without this option, mv, for example, (via the system’s rename function) must interpret a trailing slash as a request to dereference the symbolic link and so must rename the indirectly referenced directory and not the symbolic link. Although it may seem surprising that such behavior be the default, it is required by POSIX and is consistent with other parts of that standard.

Does the bold mean that the filename expansion by shell appends a slash to a symbolic link?

Where do you see this in Bash manual or POSIX specifications?

Originally I thought that it is up to the command (instead of the shell) how to interpret a symbolic link with or without a trailing slash given as its command line argument.

  • 3
    Just a point, it seems most of the answers have confused "file name completion" with "path expansion." Observed behavior in all shells I have handy demonstrates that tab completion on a symlink to a directory does indeed append a trailing slash. – Wildcard Mar 26 '16 at 0:22
3

The behavior that is required by POSIX is that mv interprets a trailing slash as a request to dereference the symbolic link. That is, if foo is a symbolic link, POSIX states that mv (like any other command) must interpret

mv foo/ bar/

as a request to move the directory pointed to by foo, rather than foo itself. This is stated in the section on pathname resolution:

A pathname that contains at least one non-slash character and that ends with one or more trailing slashes shall be resolved as if a single dot character (.) were appended to the pathname.

In other words, foo/ is equivalent to foo/..

POSIX does not mandate, or even allow, for pathname expansion to append a slash to symbolic links. This is something that some shells do when setting non-default options. I don't know if bash has an option for that. In ksh, it's set -o markdirs. Zsh also has this option but it only affects directories, not symbolic links to directories.

There are other cases where a trailing slash would naturally end up at the end of a parameter. With a glob that ends with a slash, the glob matches only directories and symbolic links to directories, and filename expansion retains the trailing slash. So mv a*/ /somewhere moves all the subdirectories of the current directory whose name starts with a, and all the targets of symbolic links in the current directory such that the symbolic link starts with a and the target is a directory. Another case is on completion; I won't go into the details because bash and zsh have so many completion options, but depending on the options it can be fairly easy to end up with foo/ when completing foo and foo is a symbolic link to a directory.

1

Does the bold mean that the filename expansion by shell appends a slash to a symbolic link?

No. It means that a shell might plausibly do so, in the case that the link points to a directory, and that they have offered the `--strip-trailing-slashes option in part to allow the user to prevent what would otherwise be side effects of that action. This is the literal meaning of the text you quoted.

Where do you see this in Bash manual or POSIX specifications?

Nowhere, because it is not true. POSIX does not specify filename completion behaviour.

The second bolded passage refers to the behaviour described in the immediately preceding sentence that you didn't bold, and the POSIX pathname resolution requirement that paths ending in a / must be treated as directories if possible, and result in errors if not possible. It is not referring to the unrelated sentence earlier in the passage that you did bold.

Originally I thought that it is up to the command (instead of the shell) how to interpret a symbolic link with or without a trailing slash given as its command line argument.

Indeed, this very option is an example of that fact.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.