Bug 19354

From NetBSD PRs 10384 and 10385:

If I create a symlink (on ffs) whose name contains a newline (ASCII
LF) character, "ls -l" fails to display the contents of the link
correctly, giving "No such file or directory".  The message seems to
indicate that ls is passing the filename to readlink() after replacing odd
characters with question marks.  Sending the output of ls through
"cat" (to disable -q) works around the problem.

When giving a long (-l) listing, ls(1) doesn't replace special characters
in the targets of symlinks with question marks.  This means that by
inserting suitable escape sequences in the contents of symbolic links, one
can do arbitrary awkward things to the display of someone running
"ls -l" on a directory, and probably cause ls to appear not to list
certain files.

Fix: 

See patches in NetBSD PR#10385.  I suspect these are applicable to FreeBSD.
How-To-Repeat: cromarty:/tmp$ ln -s "one line" "two
> lines"
cromarty:/tmp$ ls -l "two
> lines"

ls: two?lines: No such file or directory
lrwxrwxr-x  1 bjh21  wheel  8 Jun 17 15:02 two?lines
cromarty:/tmp$ ls -l "two
> lines" | cat
lrwxrwxr-x  1 bjh21  wheel  8 Jun 17 15:02 two
lines -> one line


$ ln -s `printf '\033c'` link
$ ls -l
Or, more fun:
$ mkdir hidden
$ ln -s `printf '\033[2K\033[F\033[2K\033[F'` hidden2
$ ls -l