ln 使用通配符时出现意外行为

Question

我正计划为此在 coreutils 上提交一个错误，因为这种行为是出乎意料的，并且在现实世界中没有任何实际用途......虽然它确实让我一开始就笑了，因为我从来没有甚至知道可以在文件名中创建带有通配符的文件。带有通配符的文件名有多实用？谁甚至使用过这样的功能？

我最近运行了一个类似这样的 bash 命令：

ln -s ../../avatars/* ./

不幸的是，我没有添加正确数量的“../”，因此它没有向我提供信息性错误，而是创建了一个指向不存在的“*”文件的链接。我希望这样做：

ln -s "../../avatars/*" ./

因为这是处理此类文件名的正确方法。

在提交关于 coreutils 的错误之前，我想听听其他人的意见。这种行为有什么实际用途，还是应该提供有意义的错误消息？

是的，我知道可以链接到整个目录，而不是其中的每个文件，但我不希望将新创建的文件复制到旧位置。目前只有几个文件正在链接。

有些人甚至会说在符号链接中使用通配符是不好的做法。但是，我确切地知道目录的内容，这比手动手动执行每个文件要快得多。

Answer 1

这不是错误。

在 shell 中，如果您使用不匹配任何内容的通配符模式，则不会替换该模式。例如，如果你这样做：

echo *.c

如果当前目录中没有 .c 文件，它只会打印“*.c”。如果当前目录中有 .c 文件，则 *.c 将替换为该列表。

对于许多命令，如果您指定不存在的文件，则会出现错误，并且您会收到一条看似有意义的消息，例如“无法访问 *.c”。但是对于ln -s，由于是符号链接，所以实际文件不一定存在，它会继续做链接。