It omits some characters from its output. It also mangles some others through octal escape codes or other such stuff. Depending on flags it will also not handle filenames with spaces or newlines properly. ls output is meant for human consumption, not parsing.

There are several reasons.

- Running ls forks an unnecessary process.

- The ls may be aliased with "-F" (or -p) which will corrupt the filenames.

- Environment variables may otherwise (unexpectedly) manipulate ls behavior.

- Files with spaces will not be evaluated correctly.

- Hostile files can be placed that mimic command line arguments.

The shell should evaluate filenames itself; it is very capable of doing so.

POSIX ls: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/l...

https://mywiki.wooledge.org/BashPitfalls#for_f_in_.24.28ls_.... describes the failure modes (and note that it's the very first pitfall because it's a common one - and one I've perpetrated plenty of times myself).

Given the situation and the project names, I wouldn't expect the use of `ls` described in TFA to ever be a problem, but doing it with a simple glob would still be nicer and is a good habit to get into overall since then you don't have to ask yourself "is this use of ls going to be safe?"

Not that I agree 100%, but the topic is covered fairly well here:

https://mywiki.wooledge.org/ParsingLs

Never, ever parse or rely on the output of ls. It's very unpredictable.