grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Behavior of file test operations on symlinks


From: Alan Dunn
Subject: Behavior of file test operations on symlinks
Date: Tue, 16 Feb 2016 16:34:55 -0800

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.

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" without specifying the symlink behavior (unlike "man test").

Thanks,
- Alan

Note: To test how GRUB behaved here, I created a symlink /boot/grub/dangling_symlink that linked to "nowhere".  Then I booted GRUB with config file:

...
dangling_symlink_f=false
if [ -f /boot/grub/dangling_symlink ]
then dangling_symlink_f=true
fi

echo "dangling_symlink_f: $dangling_symlink_f"
...

and streamed the serial console output from GRUB to obtain the value of $dangling_symlink_f.  Similar can be done for "-s".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]