LS – What Does a Red-Colored Filename Mean?

I am not at all convinced of this, but let's suppose for the sake of argument that you could, if you're prepared to put in enough effort, parse the output of ls reliably, even in the face of an "adversary" — someone who knows the code you wrote and is deliberately choosing filenames designed to break it.

Even if you could do that, it would still be a bad idea.

Bourne shell is not a good language. It should not be used for anything complicated, unless extreme portability is more important than any other factor (e.g. autoconf).

I claim that if you're faced with a problem where parsing the output of ls seems like the path of least resistance for a shell script, that's a strong indication that whatever you are doing is too complicated for shell and you should rewrite the entire thing in Perl or Python. Here's your last program in Python:

import os, sys
for subdir, dirs, files in os.walk("."):
    for f in dirs + files:
      ino = os.lstat(os.path.join(subdir, f)).st_ino
      sys.stdout.write("%d %s %s\n" % (ino, subdir, f))

This has no issues whatsoever with unusual characters in filenames -- the output is ambiguous in the same way the output of ls is ambiguous, but that wouldn't matter in a "real" program (as opposed to a demo like this), which would use the result of os.path.join(subdir, f) directly.

Equally important, and in stark contrast to the thing you wrote, it will still make sense six months from now, and it will be easy to modify when you need it to do something slightly different. By way of illustration, suppose you discover a need to exclude dotfiles and editor backups, and to process everything in alphabetical order by basename:

import os, sys
filelist = []
for subdir, dirs, files in os.walk("."):
    for f in dirs + files:
        if f[0] == '.' or f[-1] == '~': continue
        lstat = os.lstat(os.path.join(subdir, f))
        filelist.append((f, subdir, lstat.st_ino))

filelist.sort(key = lambda x: x[0])
for f, subdir, ino in filelist: 
   sys.stdout.write("%d %s %s\n" % (ino, subdir, f))

This indicates that ping has extra capabilities:

$ getcap /usr/bin/ping
/usr/bin/ping = cap_net_raw+ep

or even (on Fedora up to 30):

$ getcap /usr/bin/ping
/usr/bin/ping = cap_net_admin,cap_net_raw+ep

This allows ping to open a raw socket (and send and receive ICMP packets) without running as root. setcap(8) and capabilities(7) give more details.

Historically, ping was installed setuid so that it would run as root and be able to use raw sockets; once capabilities became usable, many distributions switched to using those instead, since the finer-grained control they offer over permissions seems preferable. In Ubuntu though, there are issues apparently with the installer, so ping is still installed setuid root (the capabilities code is disabled in the relevant maintainer script, which comes from Debian where ping is configured using capabilities if possible).

The ping manpage describes its requirements thus:

ping requires CAP_NET_RAW capability to be executed 1) if the program is used for non-echo queries (See -N option), or 2) if kernel does not support non-raw ICMP sockets, or 3) if the user is not allowed to create an ICMP echo socket. The program may be used as set-uid root.

Kernels 2.6.39 and later provide another mechanism to allow programs to send and receive ICMP echo messages: net.ipv4.ping_group_range. This is used in Fedora 31 and later to allow ping to work without extra capabilities (notably, inside rootless containers); see How does ping work on Fedora without setuid and capabilities? for details.