Hello Paul Eggert, Thanks for the feedback. I understand your point about not adding an option for every possible form of postprocessing.
However, my motivation for --count isn’t to replace shell pipelines, but to expose structured information that is already gathered internally while scanning directories. While ls | wc -l gives a quick total, it’s not reliable when filenames contain newlines, and it can’t distinguish between directories, regular files, and symbolic links. The --count option provides these accurate, categorized counts directly, without extra parsing or the risk of incorrect results. In that sense, it’s not arbitrary postprocessing — it’s using ls’s existing internal data to present summary statistics in a simple and consistent way. And normally from a new user's perspective, it comes to try with the --count option intuitively if they don't know about pipelines just only for this matter to know the count of categorized type of elements and its list. and later on if more post processing required users will definitely search more ways of using the pipeline. Thanks again for the review and consideration! Signed-off-by: Debkanta Mondal ([email protected]) On Wed, Oct 29, 2025 at 4:58 AM Paul Eggert <[email protected]> wrote: > > On 2025-10-28 12:18, Debkanta Mondal wrote: > > With --count, you get > > everything in one place: directories, files, links, and the table > > Sure, but we get all that info with -l already. > > Counting is just one of many things that one can already do with the > output of 'ls', and one cannot reasonably expect to have an 'ls' option > for every possible form of postprocessing. Suppose I want to count every > regular file with permission -r--r--r--, for example - should we have a > separate 'ls' option for that too? > > It's simpler to leave 'ls' alone and process its output as needed. > > > no need extra pipeline/ > > complex command for this simple and frequently required output > > I don't see that it's frequently required.
