Re: [Nix-dev] less: When assumptions ruin the world
Just a note for those who are annoyed that less will clear the screen on quit. export LESS=-X On Fri, Jan 2, 2015 at 4:30 PM, Ertugrul Söylemez ert...@gmx.de wrote: Hi Eelco, There is a very good reason for this principle. If a program does more than what it's intended to do, then it hurts composability. There shouldn't be an issue with composability here, because Nix will only run the pager when stdout is a terminal. So things work fine if you pipe Nix into another command. Let me give you an example where this assumption fails: Listing the current generations from your shell profile. In fact something very similar happened to me, which motivated me to start this thread: The change broke my assumption that Nix can be used safely from a shell script. Nothing bad happened, but one day was wasted, because a script stopped for `less` without my knowledge. I really believe that projects should start as non-interactive script- and command-line-friendly programs /by default/. I'd go as far as to call this a good design principle. Frontends can always be made. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi. On 01/02/2015 02:36 AM, Ertugrul Söylemez wrote: since Nix 1.8 much of the output of nix commands is piped through `less`, which is certainly meant to be a convenience, but that convenience depends on a few assumptions: If you set PAGER=cat or PAGER= you get pretty much the old behavior. Also, if the output isn't a terminal, less isn't used, e.g. ``nix-env -q | cat`` or ``nix-env -q | grep foo`` works the old way for me. I see no harm in having the option. Most importantly, people can choose their preferred way of displaying long output with one variable common to many programs, which IMO rather helps those with special needs (blind; or e.g. PAGER=tail if you always want the end, etc.). Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi Charles, Perhaps suggesting shell aliases would be sufficient for those that may want the pager by default? Yes, that's a good solution. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi Michael, When I explicitly launch man, I am going to read the top of the man page and some place in the middle, so less is useful. Absolutely, `man` is supposed to be an interactive program, and it usually displays formatted text that wouldn't fit on one page anyway. But honestly I wouldn't even mind if `man` just dumped everything on stdout. Since we have a Unix-like system I can easily set my shell up to pipe its output through PAGER by default. When I launch some nix build-related tool I expect to monitor current progress, and read the last 50 lines if something fails (something like tail -f, but for a stream). Your terminal emulator does exactly that. People, especially text-based UX programmers, often forget that there is a terminal that displays everything, and that the terminal is a non-trivial piece of software that offers everything you need to view long output, etc. You only really need an additional program when you need to save the output to a file, but nix-build writes build logs by itself anyway. But the PAGER really matters for man, so I keep it set to 'less -R' anyway. And then a command like the following uses it as well: nix-env --list-generations I'm mostly only interested in the last few lines, so just printing everything to stdout would be the correct solution for me. The original poster probably has other motivations and workflow patterns, but that's my experience. I think I have similar workflow patterns, but my point is that Nix 1.8 makes assumptions on the workflow patterns, and that's horrible. It helps ruining the world of UX, slowly, piece by piece. Systemd makes the same assumptions. That's why invoking most systemd commands is a horrible experience. Either I write `--no-pager` with every command, or I have to live with the fact that they abuse PAGER and my output disappears when I press `q`, when all they should really do is to print to stdout. That's what stdout is for after all! Assumptions ruin the world. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi Vladimír, If you set PAGER=cat or PAGER= you get pretty much the old behavior. Also, if the output isn't a terminal, less isn't used, e.g. ``nix-env -q | cat`` or ``nix-env -q | grep foo`` works the old way for me. I'm aware of that, and it's a terrible solution. I want to have PAGER=less for other programs, I just don't want Nix to use the pager. `nix-env -q` using the pager has already been trouble for me, but now even things like `--list-generations` use it. I see no harm in having the option. It's not an option. It's builtin and enforced behaviour since Nix 1.8. And it annoys me to such an extent that I'm almost willing to fork Nix and remove this option, or to write a command-line front-end to Nix, because Nix is no longer a command line program. It has become an interactive program. Think about it: Do you want `ls` or `find` to force-use the pager? Do you want to opt out by setting PAGER to something that isn't a pager? Or by piping every invocation of them through `cat`? If you really want interactive behaviour, there should be an interactive frontend. Most importantly, people can choose their preferred way of displaying long output with one variable common to many programs, which IMO rather helps those with special needs (blind; or e.g. PAGER=tail if you always want the end, etc.). No, they can't choose. I would choose to use `less` as a pager when I need it, and otherwise I would use my terminal. I can't make that choice without corrupting the PAGER variable (which I use for other things!). Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
If it helps at all, git seems to use GIT_PAGER first and then falls back to PAGER and then to `less` for the commands that use it. Perhaps nix could respect a NIX_PAGER env var? To me it depends on the output of the command. I love that git pages the output of `git log` automatically but that is because I generally want to see the most recent commits first. I don't mind that `apt-cache search blah` isn't paged as the top of the list is no more specifically relevant than the bottom and I can scroll up in the terminal. Michael On Fri, Jan 2, 2015 at 11:46 AM, Paul Colomiets p...@colomiets.name wrote: Hi, On Fri, Jan 2, 2015 at 1:37 PM, Ertugrul Söylemez ert...@gmx.de wrote: No, they can't choose. I would choose to use `less` as a pager when I need it, and otherwise I would use my terminal. I can't make that choice without corrupting the PAGER variable (which I use for other things!). I'm not a fan of using less for nix tools. But it seems you're inconsistent here. Which other programs use $PAGER for legitimate reasons? And what reasons are good for that? I'm asking not to insult you, but rather to make my own future decisions better. -- Paul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi Paul, No, they can't choose. I would choose to use `less` as a pager when I need it, and otherwise I would use my terminal. I can't make that choice without corrupting the PAGER variable (which I use for other things!). I'm not a fan of using less for nix tools. But it seems you're inconsistent here. Which other programs use $PAGER for legitimate reasons? And what reasons are good for that? I'm asking not to insult you, but rather to make my own future decisions better. Personally I don't use PAGER much anymore, because most of my use cases have vanished by replacing applications. For example my mail client is Emacs now, so I don't need an external pager any longer. I just use Emacs itself to view, for example, text attachments. Of course new use cases could pop up any time. For example I could choose to pipe the output of `ledger reg` through PAGER by default. The reasonable use case of PAGER is the scenario where you have an interactive program that either does not have a built-in pager or gives you the choice to use an external one, similar to how the EDITOR and BROWSER variables are used. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi Michael, I know; I was answering the question of why it is a problem to choose a single PAGER value. Sorry, I'm still getting used to my new mail setup. =) nix-env --list-generations I use ls instead of this command. That's actually a good idea, thanks. Well, systemd is intentionally breaking my workflow in ways that cannot be worked around with trivial shell scripts, and I don't care what pager journalctl when it takes multiple minutes to do the job that tail -f does in tens of milliseconds. So I let's not compare oversight with malice.. Sure, systemd is broken in too many ways to enumerate. Nix has just taken a small step into the wrong direction. Nothing will explode because of that, but we should be aware of that and step back. Of course all of this is my personal opinion. If the majority of the community disagrees, then I will have to live with it. I have opened this thread because I think that many people will actually agree. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi, On Fri, Jan 2, 2015 at 1:37 PM, Ertugrul Söylemez ert...@gmx.de wrote: No, they can't choose. I would choose to use `less` as a pager when I need it, and otherwise I would use my terminal. I can't make that choice without corrupting the PAGER variable (which I use for other things!). I'm not a fan of using less for nix tools. But it seems you're inconsistent here. Which other programs use $PAGER for legitimate reasons? And what reasons are good for that? I'm asking not to insult you, but rather to make my own future decisions better. -- Paul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
My 2c: if Nix offers a way to disable the pager then I'd rather see 1% of users for such needs to make the bash alias instead of the other way around. On 2 Jan 2015 02:36, Ertugrul Söylemez ert...@gmx.de wrote: Hi everybody, since Nix 1.8 much of the output of nix commands is piped through `less`, which is certainly meant to be a convenience, but that convenience depends on a few assumptions: * the user uses a crappy terminal emulator, * the user is interested in all of the output, * the user reads using their eyes. The first assumption is wrong for me and probably for a lot of other people as well. The second assumption is wrong for me most of the time; in most cases only the last few lines are interesting. The third one is wrong for blind people. If they can't afford an external braille terminal (not those single-line pads, which are expensive enough, but a real terminal), they will rely on text-to-speech. If not all three assumptions hold, then this feature makes Nix consistently `less` convenient to use. Not only do I have to press `q` now, but `less` is an ncurses program, which means that the output disappears after quitting. This does not happen when I just use my terminal emulator to scroll, and yes, most of them if not all allow scrolling with the keyboard (commonly Shift+PageUp and Shift+PageDown). Furthermore we hold in our hands an operating system that follows the Unix philosophy, which is about composability. There is simply no need to precompose everything with `less`. As humans we are smart beings, and we have a powerful shell, so that every user can decide for themselves when to use a pager. Also remember that we may have disabled users. A blind person will dislike this new anti-feature even more than I do, because `less` is not exactly a text-to-speech-friendly program. Feature request 1: Please do your part in saving the software world and remove this anti-feature. Don't even consider making it optional. It's useless. Remove it. In the future, whenever you think that some UX-related automation will make things easier, think again. You are most likely wrong. Just look at the huge damage that Microsoft has done by assuming that users are complete idiots. Feature request 2: Also I strongly believe that `--help` should absolutely never open a man-page. When we need a manual, we will use the `man` command, but in most cases we just need a quick reminder of what that one option was called that we're failing to recall, so I would much prefer the original purpose of the `--help` option: Print a short summary to the terminal. If this appears superficial to you, please remember that many little bad things can do a lot of damage in the long run. The purpose of this post is to wake everybody up before it's too late. I hope that some people agree with me, and if yes, I will turn these into actual feature requests on Github. I'm also happy to help with implementing the latter one, because writing a good `--help` system for commands with subcommands is not necessarily easy. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi Bjørn, Hm, I've never thought of automatic less as a misfeature before. I didn't have anything to do with its inclusion in nix, but I remember when I started using git that I was pleasantly surprised by it's use of less, which made git more fun to work with. (If I was a nix developer I might have added automatic less myself.) I guess that you're not the only one who likes a more interactive user experience, which is probably why Nix got this feature in the first place. But it assumes a workflow where interactivity is achieved through the program in question. In my case it is achieved by my shell and my terminal emulator and that fits the way I use Nix. In particular I don't want Nix to enforce the invoke-pager-then-quit pattern on me, even if I do use a pager, because that's not the way I work. Just to give you a data point: I've always been pissed off by Git's auto-invocation of the pager. But that's only one and a rather small addition to my long list of reasons why I hate Git. So what's the best way forward? Using $NIX_PAGER first, as suggested by Michael Jones earlier in this thread? That should cover your use case, right? (_And_ preserve the current behaviour for people liking it interactive? That sounds like a reasonable solution to me, as long as it's strictly opt-in. In other words, you have to set NIX_PAGER to pipe through a pager by default, otherwise it just prints to stdout. The sole fact of using a pager on the wrong level (program-level instead of shell-level) will make NIX_PAGER completely useless for me, even when I use a pager. There is good reason why I insist that piping should always be done by the shell, not by the programs you invoke. However, I really think that a better solution is to use your shell properly. There is absolutely no reason for Nix to do the piping, and there is plenty of reason not to do it. Remember that programs should only do one thing and do it well? Shells are for piping, and they do it well. Nix is for building and managing derivations and environments, and it does it well. There is a very good reason for this principle. If a program does more than what it's intended to do, then it hurts composability. That will piss people like me off who really love the Unix philosophy, because it fits well with my algebraic way of thinking and therefore with the assumptions I make about my system. Bonus: Making programs less interactive is always a win, because you can always make an interactive frontend to a noninteractive program. But you cannot make a noninteractive frontend to an interactive one. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Forgot the list... On 02/01/2015 9:36 am, Ertugrul Söylemez ert...@gmx.de wrote: Feature request 1: Please do your part in saving the software world and remove this anti-feature. Don't even consider making it optional. It's useless. Remove it. In the future, whenever you think that some UX-related automation will make things easier, think again. You are most likely wrong. Just look at the huge damage that Microsoft has done by assuming that users are complete idiots. Feature request 2: Also I strongly believe that `--help` should absolutely never open a man-page. When we need a manual, we will use the `man` command, but in most cases we just need a quick reminder of what that one option was called that we're failing to recall, so I would much prefer the original purpose of the `--help` option: Print a short summary to the terminal. I hope that some people agree with me, and if yes, I will turn these into actual feature requests on Github. I'm also happy to help with implementing the latter one, because writing a good `--help` system for commands with subcommands is not necessarily easy. I agree with your sentiment on both points. Luke ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
On 2 January 2015 at 14:01, Ertugrul Söylemez ert...@gmx.de wrote: [...] Of course all of this is my personal opinion. If the majority of the community disagrees, then I will have to live with it. I have opened this thread because I think that many people will actually agree. Hm, I've never thought of automatic less as a misfeature before. I didn't have anything to do with its inclusion in nix, but I remember when I started using git that I was pleasantly surprised by it's use of less, which made git more fun to work with. (If I was a nix developer I might have added automatic less myself.) So what's the best way forward? Using $NIX_PAGER first, as suggested by Michael Jones earlier in this thread? That should cover your use case, right? (_And_ preserve the current behaviour for people liking it interactive? Best regards, Bjørn Forsman ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
On 2 January 2015 at 14:21, Michael Raskin 7c6f4...@mail.ru wrote: So what's the best way forward? Using $NIX_PAGER first, as suggested by Michael Jones earlier in this thread? That should cover your use case, right? (_And_ preserve the current behaviour for people liking it interactive? Just in case: existence but emptiness of the variable would mean no pager, right? I guess so. But I'm probably (most likely) not the one that will implement it :-) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi Domen, My 2c: if Nix offers a way to disable the pager then I'd rather see 1% of users for such needs to make the bash alias instead of the other way around. why do you insist on an interactive-by-default Nix? There should be an interactive frontend, something like an interactive nox. [...] 1% [...] Also let's not throw around unfounded numbers here. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi, On 02/01/15 12:57, Michael Jones wrote: If it helps at all, git seems to use GIT_PAGER first and then falls back to PAGER and then to `less` for the commands that use it. Perhaps nix could respect a NIX_PAGER env var? I've implemented this now, with the same semantics as GIT_PAGER and SYSTEMD_PAGER. -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi Eelco, There is a very good reason for this principle. If a program does more than what it's intended to do, then it hurts composability. There shouldn't be an issue with composability here, because Nix will only run the pager when stdout is a terminal. So things work fine if you pipe Nix into another command. Let me give you an example where this assumption fails: Listing the current generations from your shell profile. In fact something very similar happened to me, which motivated me to start this thread: The change broke my assumption that Nix can be used safely from a shell script. Nothing bad happened, but one day was wasted, because a script stopped for `less` without my knowledge. I really believe that projects should start as non-interactive script- and command-line-friendly programs /by default/. I'd go as far as to call this a good design principle. Frontends can always be made. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi Eelco, If it helps at all, git seems to use GIT_PAGER first and then falls back to PAGER and then to `less` for the commands that use it. Perhaps nix could respect a NIX_PAGER env var? I've implemented this now, with the same semantics as GIT_PAGER and SYSTEMD_PAGER. Thanks a lot! What about issue #2? Would you agree to switch from `man` to short context-sensitive help-messages? If yes, I can refresh my rusty C++ skills and implement it. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Hi, On 02/01/15 14:49, Ertugrul Söylemez wrote: There is a very good reason for this principle. If a program does more than what it's intended to do, then it hurts composability. There shouldn't be an issue with composability here, because Nix will only run the pager when stdout is a terminal. So things work fine if you pipe Nix into another command. -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
I agree with this. I have `less` configured to restore the screen at termination (via smcup/rmcup), which is a bit annoying if I want to keep the results around. I'd rather be explicit about opting-in to the pager being used (with `| less`) rather than opting-out (with `| cat`). I also have to explicitly hit 'q' to get back to my shell. Perhaps suggesting shell aliases would be sufficient for those that may want the pager by default? -Charles On Thu, Jan 1, 2015 at 8:36 PM, Ertugrul Söylemez ert...@gmx.de wrote: Hi everybody, since Nix 1.8 much of the output of nix commands is piped through `less`, which is certainly meant to be a convenience, but that convenience depends on a few assumptions: * the user uses a crappy terminal emulator, * the user is interested in all of the output, * the user reads using their eyes. The first assumption is wrong for me and probably for a lot of other people as well. The second assumption is wrong for me most of the time; in most cases only the last few lines are interesting. The third one is wrong for blind people. If they can't afford an external braille terminal (not those single-line pads, which are expensive enough, but a real terminal), they will rely on text-to-speech. If not all three assumptions hold, then this feature makes Nix consistently `less` convenient to use. Not only do I have to press `q` now, but `less` is an ncurses program, which means that the output disappears after quitting. This does not happen when I just use my terminal emulator to scroll, and yes, most of them if not all allow scrolling with the keyboard (commonly Shift+PageUp and Shift+PageDown). Furthermore we hold in our hands an operating system that follows the Unix philosophy, which is about composability. There is simply no need to precompose everything with `less`. As humans we are smart beings, and we have a powerful shell, so that every user can decide for themselves when to use a pager. Also remember that we may have disabled users. A blind person will dislike this new anti-feature even more than I do, because `less` is not exactly a text-to-speech-friendly program. Feature request 1: Please do your part in saving the software world and remove this anti-feature. Don't even consider making it optional. It's useless. Remove it. In the future, whenever you think that some UX-related automation will make things easier, think again. You are most likely wrong. Just look at the huge damage that Microsoft has done by assuming that users are complete idiots. Feature request 2: Also I strongly believe that `--help` should absolutely never open a man-page. When we need a manual, we will use the `man` command, but in most cases we just need a quick reminder of what that one option was called that we're failing to recall, so I would much prefer the original purpose of the `--help` option: Print a short summary to the terminal. If this appears superficial to you, please remember that many little bad things can do a lot of damage in the long run. The purpose of this post is to wake everybody up before it's too late. I hope that some people agree with me, and if yes, I will turn these into actual feature requests on Github. I'm also happy to help with implementing the latter one, because writing a good `--help` system for commands with subcommands is not necessarily easy. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
