ls does not print 'l' mode indicator for symbolic links

[mknos]

• In long-listing mode (-l), the ls command prints the file mode as the first element on each line
• I created a symlink AP which refers to the file "apply"
• The GNU version prints "l" prefix on the file mode string but the perl version prints '-'
• The standards document says the 1st character of the mode-string is the entry-type, and for a symbolic link the entry-type should be "l" ("-" should be printed only for regular files) [1]
• I also verified that the OpenBSD and Sortix versions of ls print the "l" entry-type

1. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html

%readlink AP
apply
%ls -l AP # GNU
lrwxrwxrwx 1 x x 5 Mar 14 10:42 AP -> apply
%perl ls -l AP
-rwxr-xr-x   1 x       x            4488 Jan 19 14:25 AP

[mknos]

The file size printed for AP indicates the symlink might be followed before the entry listing occurs. The -l option is supposed to list symlinks as is.

[briandfoy]

I have an initial fix in #989, but I need to check that I didn't break something else. Feel free to build on that if you want to play with it.

[briandfoy]

We're going to need better tests for bin/ls because the fix I tried probably breaks other things.

In every case, bin/ls calls stat on its filename argument, so it always gets the target. If I change that to something like this is works out:

$mode = -l $Arg ? lstat($Arg) : stat($Arg);

However, there are several places where I make this change and I don't know if they are all appropriate; they probably aren't.

Then, in format_mode, the mode string is constructed just from the number, with the highest three bits used for the file type as an index into the @ftype array. For a link, that should be 0b101, but a regular file is 0b100.

But, there's are several other problems where the bin/ls does not check for a symlink, so it does the wrong thing for dangling symlinks (the @ is a macOS thing). This dangles because 000.link points to t/000.basic.t, so that would resolve to t/t/000.basic.t:

$ ls -l t/000.link
lrwxrwxr-x@ 1 brian  staff  13 Mar 14 19:11 t/000.link -> t/000.basic.t
$ perl bin/ls -ld t/000.link
ls: can't access 't/000.link': No such file or directory

bin/ls should not care if this resolves.

This is one of the things we covered in Learning Perl because people typically don't run into symlinks, and Randal wrote a Todo app using just symlinks to show off a bit.

[briandfoy]

Now here's the curious thing. Windows reports 777 for everything, but still recognizes "symlinks":

brian@GMK C:\Users\brian>wsl ls -l
total 7488
drwxrwxrwx 1 root root    4096 Mar 12 03:47  AppData
lrwxrwxrwx 1 root root      34 Mar 12 03:46 'Application Data' -> /mnt/c/Users/brian/AppData/Roaming
drwxrwxrwx 1 root root    4096 Mar 12 03:50  Contacts
lrwxrwxrwx 1 root root      62 Mar 12 03:46  Cookies -> /mnt/c/Users/brian/AppData/Local/Microsoft/Windows/INetCookies
drwxrwxrwx 1 root root    4096 Mar 12 03:50  Desktop
drwxrwxrwx 1 root root    4096 Mar 12 02:10  Dev
drwxrwxrwx 1 root root    4096 Mar 12 03:50  Documents
drwxrwxrwx 1 root root    4096 Mar 12 03:50  Downloads
drwxrwxrwx 1 root root    4096 Mar 12 03:50  Favorites
drwxrwxrwx 1 root root    4096 Mar 12 03:50  Links
lrwxrwxrwx 1 root root      32 Mar 12 03:46 'Local Settings' -> /mnt/c/Users/brian/AppData/Local
drwxrwxrwx 1 root root    4096 Mar 12 03:50  Music