3 ms·

It has a ridiculously big help section. It is a pager!

by int0x80 10y ago

rwmj 10y ago
So his complaint is that it is well documented and featureful?
- int0x80 10y ago
  One could say that if a pager needs +1k lines of help, something is wrong. Complexity is usually not good. And never free.
  - rwmj 10y ago
    Is it affecting you adversely in some way? Almost all the time you can write: something or other | less and it does what you expect. The additional features and customization are there if you need them, and hide out of the way when you don't. If he really wants a pager with fewer features, then plenty of others exist, like plain "more": $ more |& wc 20 94 676 But people don't do that. They use less because it's better.
    - int0x80 10y ago
      When you do `smthin | less' the other bazilion options are loaded in less, using resources. If you want to have a quick look a the help you can get overwhelmed by all the information. Having so many options in less can be seen as over-engineering. Bloating the system. There are duplicate features, features that probably don't belong in less etc. It goes against the minimalism of Unix. It probably isn't a big deal in this case, but as a general rule being simple and lean is a feature IMO.
      - GFK_of_xmaspast 10y ago
        > the other bazilion options are loaded in less, using resources What kind of tiny little system are you using that you have to worry about less taking up too much of it?
  - mhd 10y ago
    Is the code particularly buggy or inefficient? If not, having a feature that you don't use doesn't really affect you. There's an argument that lets you squeeze together multiple blank lines into one. That's arguably superfluous, as you could pipe your text through a sed/awk/ed/perl/snobol script beforehand. I've never used that argument. But I never had less crash on me because of it, and I don't think it caused a big security impact. If having that command means that every second procedure in the code has to handle special cases because of it, then yes, it's probably not worth it. If it's just a few lines in one place, plus another command line argument parsing section, plus a line in the docs, then why not? Extraneous features can cause harm, but one shouldn't be too extremist about this and consider each case. When it comes to handling text, there are a lot of special cases that require little code and thus don't really hurt. That's one of the main reasons why GNU utilities might be considered bloated, but most of the time it's no big deal beyond philosophy/aesthetics. (I'm sure my Python/Perl standard lib has a lot of modules I'll never use, too) On the other hand, I'm not quite sure whether I'll ever need the Tektronix emulation of xterm...
    - benbenolson 10y ago
      This is going against exactly what Doug is arguing, though: Unix taste includes having many small, perfectly-designed programs to achieve great power. Adding more and more features to something simple adds complexity, and therefore, in Doug's opinion, makes it less elegant. Obviously `less` is a pretty bad example for this, because it's so simple. But that's his point-- it should just be a pager, that's it. But it doesn't just do that-- it does a great many other things, has all sorts of arguments that you can pass to it unnecessarily. Regarding your xterm comment, you might want to consider the `st` terminal emulator, a suckless tool. It's really great, consists of one C file, and is extremely minimal.
- oneeyedpigeon 10y ago
  Look in the man page. There's an entire section about how to edit the command line that is used when entering, for example, the command to view a different named file. That smells really bad - surely that mechanism shouldn't be specific enough to a pager that it needs a huge section in the help file. All-in-all, less does feel big relative to other programs adhering to the unix philosophy. I tried to do a feature-comparison between more and less just now but, unfortunately, on OSX: ~/src/c$ more --version less 418
  - GFK_of_xmaspast 10y ago
    So now you're complaining that "there's too much documentation"? (or that "once you're in less you shouldn't be able to view another file without quitting"?)
    - notalaser 10y ago
      He's complaining that there's too much crap in a single program that shouldn't have to do anything other than page files. It has been possible to view another file without quitting less since pretty much the dawn of Unix time by suspending less and launching another instance (or, more recently, as in for the last thirty years or so, by using a terminal multiplexer).
oneeyedpigeon 10y ago
That's not even the entirety of its help; the man page is gargantuan: $ man less | wc 1530 10418 77708

It has a ridiculously big help section. It is a pager!

by int0x80 10y ago

It has a ridiculously big help section. It is a pager!

rwmj 10y ago

So his complaint is that it is well documented and featureful?

int0x80 10y ago
One could say that if a pager needs +1k lines of help, something is wrong. Complexity is usually not good. And never free.
- rwmj 10y ago
  Is it affecting you adversely in some way? Almost all the time you can write: something or other | less and it does what you expect. The additional features and customization are there if you need them, and hide out of the way when you don't. If he really wants a pager with fewer features, then plenty of others exist, like plain "more": $ more |& wc 20 94 676 But people don't do that. They use less because it's better.
  - int0x80 10y ago
    When you do `smthin | less' the other bazilion options are loaded in less, using resources. If you want to have a quick look a the help you can get overwhelmed by all the information. Having so many options in less can be seen as over-engineering. Bloating the system. There are duplicate features, features that probably don't belong in less etc. It goes against the minimalism of Unix. It probably isn't a big deal in this case, but as a general rule being simple and lean is a feature IMO.
    - GFK_of_xmaspast 10y ago
      > the other bazilion options are loaded in less, using resources What kind of tiny little system are you using that you have to worry about less taking up too much of it?
- mhd 10y ago
  Is the code particularly buggy or inefficient? If not, having a feature that you don't use doesn't really affect you. There's an argument that lets you squeeze together multiple blank lines into one. That's arguably superfluous, as you could pipe your text through a sed/awk/ed/perl/snobol script beforehand. I've never used that argument. But I never had less crash on me because of it, and I don't think it caused a big security impact. If having that command means that every second procedure in the code has to handle special cases because of it, then yes, it's probably not worth it. If it's just a few lines in one place, plus another command line argument parsing section, plus a line in the docs, then why not? Extraneous features can cause harm, but one shouldn't be too extremist about this and consider each case. When it comes to handling text, there are a lot of special cases that require little code and thus don't really hurt. That's one of the main reasons why GNU utilities might be considered bloated, but most of the time it's no big deal beyond philosophy/aesthetics. (I'm sure my Python/Perl standard lib has a lot of modules I'll never use, too) On the other hand, I'm not quite sure whether I'll ever need the Tektronix emulation of xterm...
  - benbenolson 10y ago
    This is going against exactly what Doug is arguing, though: Unix taste includes having many small, perfectly-designed programs to achieve great power. Adding more and more features to something simple adds complexity, and therefore, in Doug's opinion, makes it less elegant. Obviously `less` is a pretty bad example for this, because it's so simple. But that's his point-- it should just be a pager, that's it. But it doesn't just do that-- it does a great many other things, has all sorts of arguments that you can pass to it unnecessarily. Regarding your xterm comment, you might want to consider the `st` terminal emulator, a suckless tool. It's really great, consists of one C file, and is extremely minimal.
oneeyedpigeon 10y ago
Look in the man page. There's an entire section about how to edit the command line that is used when entering, for example, the command to view a different named file. That smells really bad - surely that mechanism shouldn't be specific enough to a pager that it needs a huge section in the help file. All-in-all, less does feel big relative to other programs adhering to the unix philosophy. I tried to do a feature-comparison between more and less just now but, unfortunately, on OSX: ~/src/c$ more --version less 418
- GFK_of_xmaspast 10y ago
  So now you're complaining that "there's too much documentation"? (or that "once you're in less you shouldn't be able to view another file without quitting"?)
  - notalaser 10y ago
    He's complaining that there's too much crap in a single program that shouldn't have to do anything other than page files. It has been possible to view another file without quitting less since pretty much the dawn of Unix time by suspending less and launching another instance (or, more recently, as in for the last thirty years or so, by using a terminal multiplexer).

oneeyedpigeon 10y ago

That's not even the entirety of its help; the man page is gargantuan: $ man less | wc 1530 10418 77708