7 ms·

One of the maintainers of uutils here. We have a few flags that are not in GNU for one reason or another. Some were rejected by GNU, others come from other core

by terts 4y ago

One of the maintainers of uutils here. We have a few flags that are not in GNU for one reason or another. Some were rejected by GNU, others come from other coreutils implementations like FreeBSD. We document those at https://uutils.github.io/user/extensions.html https://uutils.github.io/user/extensions.html 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!

mcqueenjordan 4y ago
Oh wow, I had no idea that was a feature. That significantly hampers extending the tools in the future. Has there ever been a discussion to consider breaking that functionality? (I understand it could be a huge impact & not worth it, but just curious to read the discussion if it exists.)
- terts 4y ago
  I can't find any discussion. But I know that some alternative implementations disable this feature. The cause of this behaviour is actually the glibc `getopt_long` function, which does this automatically, so it can't be changed until it's changed in glibc, which has been rejected at least once that I can find: https://sourceware.org/bugzilla/show_bug.cgi?id=6863 https://sourceware.org/bugzilla/show_bug.cgi?id=6863
pas 4y ago
How about introducing three dahses for these custom parameters/flags? 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!
- terts 4y ago
  It's possible I suppose, but three dashes already sometimes appears in GNU for hidden options and, probably more importantly, I think it would be frustrating to have to remember whether it was `--filter` or `---filter` for all long flags.
  - zaarn 4y ago
    Maybe uutils could have a build feature that specifically turns off the prefix matching and will break stuff but allows using newer and more useful flags in exchange. I've VERY rarely seen prefix-matched flags being used so I'd wager a distro could be fine deploying it that way. Ie, setup the features "gnu-compatible-opt-matching" and ship it by default, then gate the extra features behind not turning on that feature.
    - terts 4y ago
      It's a good idea to make the prefix matching optional. I think it might be confusing to gate other features behind it though. I guess we'll get to this once we find flags that are important enough. So far, we haven't really had significant issues with this; compatibility remains our primary focus for now.
- terts 4y ago
  > In a busybox situation depending on some regex crate is a given anyway 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.
ricardobeat 4y ago
That's the first time I hear of this "feature" (using `--fi` instead of `--file`). I tried a few commands in my shell and none actually support it. How common is this?
- terts 4y ago
  Outside of the coreutils, not much I think. The GNU coreutils all have it though. It's documented here: https://www.gnu.org/software/coreutils/manual/html_node/Common-options.html https://www.gnu.org/software/coreutils/manual/html_node/Comm...
  - n8henrie 4y ago
    Wow, can't believe I didn't know this. Thanks!
emmelaich 4y ago
FWIW, this particular behaviour can be achieved with `find . -type d -maxdepth 1 ....`
efreak 4y ago
A solution might be too only allow traditional flags to be shorthand, and require the full long option for new flags.

by terts 4y ago

mcqueenjordan 4y ago

Oh wow, I had no idea that was a feature. That significantly hampers extending the tools in the future. Has there ever been a discussion to consider breaking that functionality? (I understand it could be a huge impact & not worth it, but just curious to read the discussion if it exists.)

terts 4y ago
I can't find any discussion. But I know that some alternative implementations disable this feature. The cause of this behaviour is actually the glibc `getopt_long` function, which does this automatically, so it can't be changed until it's changed in glibc, which has been rejected at least once that I can find: https://sourceware.org/bugzilla/show_bug.cgi?id=6863 https://sourceware.org/bugzilla/show_bug.cgi?id=6863

pas 4y ago

How about introducing three dahses for these custom parameters/flags? 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!

terts 4y ago
It's possible I suppose, but three dashes already sometimes appears in GNU for hidden options and, probably more importantly, I think it would be frustrating to have to remember whether it was `--filter` or `---filter` for all long flags.
- zaarn 4y ago
  Maybe uutils could have a build feature that specifically turns off the prefix matching and will break stuff but allows using newer and more useful flags in exchange. I've VERY rarely seen prefix-matched flags being used so I'd wager a distro could be fine deploying it that way. Ie, setup the features "gnu-compatible-opt-matching" and ship it by default, then gate the extra features behind not turning on that feature.
  - terts 4y ago
    It's a good idea to make the prefix matching optional. I think it might be confusing to gate other features behind it though. I guess we'll get to this once we find flags that are important enough. So far, we haven't really had significant issues with this; compatibility remains our primary focus for now.
terts 4y ago
> In a busybox situation depending on some regex crate is a given anyway 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.

ricardobeat 4y ago

That's the first time I hear of this "feature" (using `--fi` instead of `--file`). I tried a few commands in my shell and none actually support it. How common is this?

terts 4y ago
Outside of the coreutils, not much I think. The GNU coreutils all have it though. It's documented here: https://www.gnu.org/software/coreutils/manual/html_node/Common-options.html https://www.gnu.org/software/coreutils/manual/html_node/Comm...
- n8henrie 4y ago
  Wow, can't believe I didn't know this. Thanks!

emmelaich 4y ago

FWIW, this particular behaviour can be achieved with `find . -type d -maxdepth 1 ....`

efreak 4y ago

A solution might be too only allow traditional flags to be shorthand, and require the full long option for new flags.