4 ms·

> tend to have more features and better help output Just a random opinion. Others disagree and prefer the BSD way. Concrete reasons include code-base simplicit

> tend to have more features and better help output Just a random opinion. Others disagree and prefer the BSD way. Concrete reasons include code-base simplicity. https://github.com/coreutils/coreutils/blob/master/src/yes.c https://github.com/coreutils/coreutils/blob/master/src/yes.c https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c

throwaway09223 5y ago
That's a developer-perspective issue. You're talking to a user here, and from a user perspective, the GNU utilities are generally strictly superior. Take the example you provided, of yes(1). Most of the extra code relates to optimizations, and ensuring that the entire argv is echoed back rather than just the first argument. Because of this, even a very simple example like: "yes hello world" will behave differently on BSD vs GNU, with the GNU version likely being what users expect.
- chrisseaton 5y ago
  > with the GNU version likely being what users expect Lol why? Not everyone grew up on GNU. > strictly superior This isn't something you can quantify and say 'strictly superior' it's all just taste and opinions.
  - throwaway09223 5y ago
    Because the functionality in this case is a strict superset, regardless of what you're accustomed to. I didn't grow up on GNU either, but the GNU yes does everything I expect having used other unix systems. > This isn't something you can quantify and say 'strictly superior' it's all just taste and opinions. For a complicated tool, sure. But this tool is very simple. The GNU yes(1) accepts 100% of inputs that work on the BSD tool. It does a few additional things too.
    - chrisseaton 5y ago
      > Because the functionality in this case is a strict superset Extra functionality is always better? Then I can fork GNU, add extra junk options, and give you a strictly superior tool? Nonsense. The GNU tools are the Homer Cars of UNIX. Not everyone wants that.
      - throwaway09223 5y ago
        Hey, look. As a systems guy myself I understand the aesthetic around clean and simple software. That's a totally reasonable preference. Here's the thing: GNU userland isn't some poorly designed aberration. It's by far the most popular unix userland in the world and is very commonly ported to systems which may do things differently. Almost every other unix has a distro to supply GNU userland tools on it -- no other unix userland can make the same claim. Not everyone wants it, sure. Especially people with perspectives broader than the typical user. Of course. But it's the most popular system in the world -- not some weird never-used prototype. And in the case of yes(1), I think you would have to try very hard to find a reason for a user of the tool to have a negative preference.
      - ben0x539 5y ago
        > Then I can fork GNU, add extra junk options You likely can't, all the possible option flags already have some meaning. <:)
pxc 5y ago
edit: I can't read
- chrisseaton 5y ago
  > OpenBSD `yes` doesn't look very useful if your language isn't English, or you're dealing with any other kind of prompt than y/n Not sure what you mean - you can get it to print whatever you want by passing that on the command line? puts(argv[1]);

throwaway09223 5y ago

That's a developer-perspective issue. You're talking to a user here, and from a user perspective, the GNU utilities are generally strictly superior. Take the example you provided, of yes(1). Most of the extra code relates to optimizations, and ensuring that the entire argv is echoed back rather than just the first argument. Because of this, even a very simple example like: "yes hello world" will behave differently on BSD vs GNU, with the GNU version likely being what users expect.

chrisseaton 5y ago
> with the GNU version likely being what users expect Lol why? Not everyone grew up on GNU. > strictly superior This isn't something you can quantify and say 'strictly superior' it's all just taste and opinions.
- throwaway09223 5y ago
  Because the functionality in this case is a strict superset, regardless of what you're accustomed to. I didn't grow up on GNU either, but the GNU yes does everything I expect having used other unix systems. > This isn't something you can quantify and say 'strictly superior' it's all just taste and opinions. For a complicated tool, sure. But this tool is very simple. The GNU yes(1) accepts 100% of inputs that work on the BSD tool. It does a few additional things too.
  - chrisseaton 5y ago
    > Because the functionality in this case is a strict superset Extra functionality is always better? Then I can fork GNU, add extra junk options, and give you a strictly superior tool? Nonsense. The GNU tools are the Homer Cars of UNIX. Not everyone wants that.
    - throwaway09223 5y ago
      Hey, look. As a systems guy myself I understand the aesthetic around clean and simple software. That's a totally reasonable preference. Here's the thing: GNU userland isn't some poorly designed aberration. It's by far the most popular unix userland in the world and is very commonly ported to systems which may do things differently. Almost every other unix has a distro to supply GNU userland tools on it -- no other unix userland can make the same claim. Not everyone wants it, sure. Especially people with perspectives broader than the typical user. Of course. But it's the most popular system in the world -- not some weird never-used prototype. And in the case of yes(1), I think you would have to try very hard to find a reason for a user of the tool to have a negative preference.
    - ben0x539 5y ago
      > Then I can fork GNU, add extra junk options You likely can't, all the possible option flags already have some meaning. <:)

pxc 5y ago

edit: I can't read

chrisseaton 5y ago
> OpenBSD `yes` doesn't look very useful if your language isn't English, or you're dealing with any other kind of prompt than y/n Not sure what you mean - you can get it to print whatever you want by passing that on the command line? puts(argv[1]);