We tend to do this sparingly, however, because even just adding new flags might break existing scripts that use abbreviated long options. For example, if the flag you propose is called `--filter` it might break scripts that use `--fi` as a shorthand for `--file-type`, because the prefix is now ambiguous.
I personally like the flag you propose!
Regarding filtering. In a busybox situation depending on some regex crate is a given anyway, but if we are talking about separate binaries adding it to `ls` makes it bigger for everyone, even for those who will never use this feature. Does piping the results to grep make things so much slower that adding filtering to ls is "worth it"? Is this pushing the "philosophy" of do one thing well and be compostable too much? How many kilobytes are we talking about anyway?
Care to share your opinion on these theoretical/pragmatic questions? Thanks!
uutils can behave as a busybox-like binary. But I think there's some confusion over the requested feature, because that can't really be done with regex, but you have to inspect the file metadata to check the type of file. That's also why a grep solution doesn't really work, unless you use `ls --classify` and then use the indicators to filter in `grep`.
> if we are talking about separate binaries adding it to `ls` makes it bigger for everyone, even for those who will never use this feature
It's generally not these kinds of features that increase the binary size, but if it does we could also introduce feature flags for it, where you can choose at compile time whether you want the uutils extensions or not. It still adds a bit of a maintenance burden of course.
Ie, setup the features "gnu-compatible-opt-matching" and ship it by default, then gate the extra features behind not turning on that feature.
Eg once upon a time I thought it would be fun to add a flag to ls to limit its results to a certain kind of file so you could list only directories for example. It came up for me as something I needed so I did it. Somebody on the gnu mailing list for core utils rejected it on the basis of ls "having a high bar" for a new flag. $ man ls suggests this hasn't been a consistent policy. It wasn't clear to me if that person was in charge or it was just a vague notion of theirs or anything useful so obviously I dropped it because I'd have something different from someone if there was any interest.
The Rust implementation might come to precisely the same conclusion that it isn't worthwhile. But they also might not on some case if not that one.
Do they do what's better or do they do what's Gnu always and everywhere?
Do they wait until they have significant traction and only then consider such things?
Interesting questions for them to ponder and maybe they have?