I am a new Linux user learning from Arch Linux and recently Linux From Scratch (7.7). I set up a new installation of AL to be my LFS host; I manually (and also with the provided bash script) checked prerequisite packages on my host. In my case, I am confident I resolved all discrepancies except for linking /usr/bin/yacc to /usr/bin/bison.The provided script results in yacc is bison (GNU Bison) 3.0.4, as opposed to /usr/bin/yacc -> /usr/bin/bison. Because the latter was the output format for checked symbolic links, I assumed the script was telling me yacc is prepared but employing a different kind of link. I investigated more about Linux file systems and took away a cursory understanding that actual data is described by inodes (metadata), which are in turn pointed to by the (abstract) files we interact with. Files that simply point to the same inode are considered hard links (although, I think the files are independent of each other). I ran sudo ls -il /usr/bin | less and found yacc and bison had slightly different inode numbers (152077 and 152078, respectively). Does this mean they are not hard linked, or am I misinterpreting the script output and require a fix?Edit: Relevant commands from bash script:bison --version | head -n1if [ -h /usr/bin/yacc ]; then  echo /usr/bin/yacc -> `readlink -f /usr/bin/yacc`;elif [ -x /usr/bin/yacc ]; then  echo yacc is `/usr/bin/yacc --version | head -n1`else  echo yacc not found fi
Can files with different inum be hard linked?
arch linux;symlink;hard link
When you did the ls -il /usr/bin, you were listing file names and matching inode numbers. In this context, it's probably best to think of file name as separate from inode, and to think of the inode as the file.The inode is typically an on-disk data structure containing metadata (permissons, ownership, creation time, access time, etc) and the disk blocks that contain the file's data. Depending on the file system, inodes can be located strategically around the disk, or live in a database of sorts. Most of the time, there's a fast algorithm to go from inode number to the disk block the inode is in, so that lookup is quite rapid.From this standpoint, every file name is just a hard link. A directory just matches up file names and inode numbers. No distinction is made between a real file name and a hard link. So your file names /usr/bin/yacc and /usr/bin/bison are matched to different inode numbers means that those two names refer to different metadata, and different file data. Speaking casually, the files are not hard links in the sense that only one file name matches each of the two inodes, but from a technical sense, both file names are hard links, they're each just the single hard link to the inode.As far as your script and the almost identical inode numbers, yacc and bison are related.  On my Arch laptop:1032 % ls -li /usr/bin/yacc /usr/bin/bison1215098 -rwxr-xr-x 1 root root 394152 Jan 23  2015 /usr/bin/bison*1215097 -rwxr-xr-x 1 root root     41 Jan 23  2015 /usr/bin/yacc*1033 % file /usr/bin/yacc/usr/bin/yacc: POSIX shell script, ASCII text executable1034 % cat /usr/bin/yacc#! /bin/shexec '/usr/bin/bison' -y $@The file names yacc and bison identify inode numbers only one apart, probably because they got created one after the other. The file name for yacc does not represent a symbolic link or a hard link. A symbolic link would show up differently in the ls -li output, two hard links would each represent the same inode number.But yacc is related to bison in that it's a shell script that invokes bison. That's why your script gives output something like:bison (GNU Bison) 3.0.4yacc is bison (GNU Bison) 3.0.4Your script invokes /usr/bin/yacc which actually just executes /usr/bin/bison.