On Sun, Dec 07, 2014 at 03:43:36PM -0800, Eric Pruitt wrote: > I don't know if this is the correct behavior. Whether or not a symlink > to a directory has its contents shown with GNU ls depends on whether or > not there's a slash present and the flags used: > > playground$ mkdir AFolder > playground$ touch AFolder/Horse > playground$ ln -s AFolder SymbolicLinkToAFolder > playground$ ls SymbolicLinkToAFolder > Horse > playground$ ls -l SymbolicLinkToAFolder > lrwxrwxrwx 1 ericpruitt ericpruitt 7 Dec 7 15:35 SymbolicLinkToAFolder > -> AFolder > playground$ ls -l SymbolicLinkToAFolder/ > total 0 > -rw------- 1 ericpruitt ericpruitt 0 Dec 7 15:34 Horse > > Personally, that "-l" made a difference surprised me, but prior to > actually running the command, I would expect "ls ... $SYMLINK" to show > the information for the symlink while "ls ... $SYMLINK/" to show the > contents of the directory. If I recall correctly, historically in things > like Sys V, whether or not a trailing slash was added to a directory > used as a command line argument changed the behaviour of various tools. > Check out http://unix.stackexchange.com/a/50522 which has a few links to > the POSIX docs.
Actually, POSIX specifies this behavior (contents of symlink without -l, symlink itself with -l): "If one or more of the -d, -F, or -l options are specified, and neither the -H nor the -L option is specified, for each operand that names a file of type symbolic link to a directory, ls shall write the name of the file as well as any requested, associated information. If none of the -d, -F, or -l options are specified, or the -H or -L options are specified, for each operand that names a file of type symbolic link to a directory, ls shall write the names of files contained within the directory as well as any requested, associated information." I will update the patch to interact correctly with the -l and -F flags, and maybe look at adding the -H and -L flags.
