[cs631apue] Understanding/confirming ls functionality

[Jan Schaumann]

Elliot Wasem <ewasem at stevens.edu> wrote:

> When you tell ls to list recursively (-R), it
> happily does so. However, is it the case that when
> we reach a symlink to a directory, we do not
> recursively search that symlink-targeted directory?

That is correct in your version of ls(1).

The system's ls(1) has an option '-L' that makes it
follow symlinks it encounters, but your program does
not need to support this.

You can test this via e.g.:

mkdir dir
mkdir dir/dir
touch dir/dir/file
ln -s / dir/d
ls -lR dir	# your program's behavior
ls -lLR dir	# your program doesn't support '-L'

> And that (unless -d is specified) we just list that
> target directory as you would a non-directory file
> (apart from the permission/mode string indicating
> that it's a direcotry)?

If one of the arguments left after command-line
options are processed is a directory, then the
contents of that directory are displayed.

If '-d' is specified, then any arguments left after
command-line options are processed are not searched
recursively.

The difference should be evident if you run:

mkdir dir
mkdir dir/dir
touch dir/file dir/dir/file
ln -s / dir/d
ls -l dir/file dir/d dir/dir
ls -l -d dir/file dir/d dir/dir

Note the different treatment of symlinks depending on
whether the pathname ends in a trailing slash or not:
ls dir/d
ls dir/d/

> Additionally, am I right in saying that it is not
> possible to hard link a directory, and only a
> non-directory file?

That is not correct.

You can create a hard link to many types of files:

mkdir dir
ln /dev/tty dir/tty
mkfifo /tmp/fifo
ln /tmp/fifo dir/fifo


Hardlinks to a directory, however, are generally not
allowed for non-uid 0, as those may create loops in
the filesystem.  I think the book has an anecdote
about the author trying to create one and hosing his
filesystem nearly beyond repair...

-Jan