17.02.2016 03:34, Alan Dunn пишет: > Hi folks, > > Apologies if the following has already come up on this list; I looked for > it and could not find any mention of it. > > I noticed that in a GRUB script "[ -f <dangling symlink path> ]" evaluates > to true. This is unlike the behavior of the "test" binary, in which it > returns false: most file test operations dereference their symlinks > recursively (i.e., strace on Linux reveals they use stat, which does > this). By contrast, "[ -s <dangling symlink path> ]" evaluates to false, > which seems inconsistent since if the file exists by -f, then it seems like > -f is referring to the symlink itself, which has non-zero file size. >
It looks rather side effect of implementation which looks for directory entry. It is straightforward to fix it by just trying to grub_file_open() which fails in this case. But the interesting question is semantic of both tests with mandatory signature checking in place. I.e. if signature for a file is invalid, should "test -s" and "test -f" still report true? I suppose yes, because file still exists. > I was curious whether there is some motivation with respect to any > deviations that GRUB has in interpreting file test operations in comparison > to the "test" binary, or whether this is considered a bug/thing that should > be improved in the documentation. The GRUB manual ( > http://git.savannah.gnu.org/cgit/grub.git/tree/docs/grub.texi) only > indicates that -f tests whether the "file exists and is not a directory" Well, current behavior is compliant with this description (symlink does exist and it is not directory), it is just not very useful in practice. Actually implementing "test -h" is pretty trivial. > without specifying the symlink behavior (unlike "man test"). > I vote for changing it to follow symlink. Anyone has argument to keep current behavior? _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
