Rendered at 06:30:46 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
eikenberry 5 hours ago [-]
> Use a pager (e.g. less) if you are outputting a lot of text.
If I wanted to use a pager I'd pipe the output to a pager, no pipe to pager means I want it all dumped to STDOUT.
So annoying.
ventana 4 hours ago [-]
This is a common approach, CLI tools often use isatty [1] to check if the output fd is a TTY or not. Try running "git log" for example; if you have many commits, it will page through "less" or $PAGER only if it sees that you're on a real TTY; but if not, it will not. Try this:
git log # PAGER undefined; uses less
PAGER=/usr/bin/head git log # pages through head, you get 10 lines
PAGER= git log # PAGER is empty; does not page
git log | cat # output is not a TTY; does not page
(also, notice that git uses colors if the output is going to a terminal, and does not if not)
I don't think I was ever bothered by the automatic paging through "less".
Right. IMO this is bad behavior. I have `pager=cat` in my git config to deal with it there and several other aliases (include --no-pager) for systemd related stuff that do it to.
jpitz 3 hours ago [-]
I'm bothered by it because whatever git command that I'm executing will put its output in a pager and when I quit the pager it's not there anymore. I want the output on the screen when I start typing the next command. Oh my God, this is such a frustrating pattern.
simon-b 3 hours ago [-]
This is indeed an annoying, but solvable, less default. You can eg use `export LESS="-XF"` to change behaviour.
ventana 3 hours ago [-]
Then export PAGER= in your shell profile should help!
Ferret7446 2 hours ago [-]
Unfortunately not all programs respect an empty PAGER vs an unset PAGER. It's more reliable to use PAGER=cat
yjftsjthsd-h 3 hours ago [-]
Another example, which I find very annoying, is `systemctl status`; when the service has... either enough log lines or wide enough lines, idk, it will helpfully page them. So checking the status of a service randomly may or may not block your terminal. I cannot stress enough that I do not want to have to look at the screen and decide interactively whether or not I need to hit q before I can run another command.
inetknght 3 hours ago [-]
Yeah no. If I wanted to use a pager, I'd use a pager.
I want the output visible on screen after I exit the pager. If I didn't want it on screen, I'd pipe it to a file and open that in a text editor. That will disappear when I close the file. As a bonus: I can then use grep without having to repeat whatever command I used.
Even more importantly: I want the command to behave identically regardless of whether its stdin or stdout is /dev/null or a terminal or a socket or a serial port or a pipe or anything else that it can read or write with. Try writing a script when the tools themselves change how they behave whether they're running in a script or in a terminal or elsewhere. It kinda sucks.
ithkuil 3 minutes ago [-]
You make a reasonable point so I don't want to oppose it but just to offer more tricks in case some of you don't know them:
_less_ has a nice "&" command that is like "/" (search) but that filters instead like grep.
You can also pipe to an external command from less
hulitu 1 hours ago [-]
> Try writing a script when the tools themselves change how they behave whether they're running in a script or in a terminal
But we smart coders. We think everything. Remind me later.
ventana 3 hours ago [-]
[dead]
keithnz 5 hours ago [-]
100% - I want to use whatever pager I might prefer at the moment, this advice violates their core principle "you make programs that are modular enough to be recombined as needed"
hankbond 6 hours ago [-]
> Whatever software you’re building, you can be absolutely certain that people will use it in ways you didn’t anticipate. Your software will become a part in a larger system—your only choice is over whether it will be a well-behaved part.
For comfortable reading, I just had to figure out what on this webpage causes Chromium to drop subpixel rendering, and it's not this:
html { -webkit-font-smoothing: antialiased; }
it's this:
#TableOfContents { backdrop-filter: blur(3px); }
A panel that overlaps content only on narrow screens disables subpixel rendering for the entire text. Thanks Chromium. Not an issue on Firefox, btw.
esalman 4 hours ago [-]
I have used click/typer packages to build some python-based CLI programs. It's easy and user-friendly way to build, but the amount of time it takes for python to start the environment followed by the actual program to do anything is annoying.
daitangio 1 hours ago [-]
I use python click too, and it helps me to focus on design before implementing.
I mean before asking AI to implement :)
kazinator 8 hours ago [-]
> A command is saying too little when it hangs for several minutes and the user starts to wonder if it’s broken.
Nope. For debugging the program, it is nice to have some debug tracing option, but if it's not the program's specification to produce output, it should not produce any. If the program's specification is that it produces a certain output after a certain calculation, then it shall not produce any other output, even if that calculation takes three weeks.
"cp -r from to" is supposed to be quiet until it's done or hits an error.
It would be nice to have an agreed-upon protocol for progress reporting. For instance, imagine of we had file descriptor 3 as "stdprogress". Programs could dump specially formatted messages there which the parent job control shell could intercept and turn into a progress display (with multiple rows for pipeline elements and such). It's not bad; but fluff like this can't be in band with the output, or at least not by default.
procflora 6 hours ago [-]
Isn't this basically how more modern "chatty" CLIs use stderr? Put all the nice progress bars and emojis behind `if isatty(2)`? I thought so anyway, but I'll admit I've never actually looked at what npm, uv, etc. do.
XYen0n 2 hours ago [-]
Although not a standard protocol, `OSC 9;4` can be used to display a progress bar in the terminal emulator.
yjftsjthsd-h 7 hours ago [-]
> It would be nice to have an agreed-upon protocol for progress reporting. For instance, imagine of we had file descriptor 3 as "stdprogress". Programs could dump specially formatted messages there which the parent job control shell could intercept and turn into a progress display (with multiple rows for pipeline elements and such).
Different thing, but I am reminded of the BSDs having SIGINFO.
> It's not bad; but fluff like this can't be in band with the output, or at least not by default.
FWIW, I would describe stderr as being out of band. IIRC that's how e.g. pv works; `<file.img pv | dd of=/dev/foo` sends data along stdout while giving status info to the user since stderr isn't being piped.
IgorPartola 6 hours ago [-]
Lots of programs report progress when you send SIGUSR1 or SIGUSR2.
cookiengineer 2 hours ago [-]
> It would be nice to have an agreed-upon protocol for progress reporting.
That was initially USR1 and USR2 as process signals, well, at least across binutils and coreutils.
I just wish that UNIX architecture or POSIX would have been modernized since then, like with JSONL based process communication or similar things.
In Go I usually end up building my own JSONL protocol to marshal/unmarshal states between long running processes. Wish that could've been a POSIX standard.
If I wanted to use a pager I'd pipe the output to a pager, no pipe to pager means I want it all dumped to STDOUT. So annoying.
I don't think I was ever bothered by the automatic paging through "less".
[1]: https://man7.org/linux/man-pages/man3/isatty.3.html
I want the output visible on screen after I exit the pager. If I didn't want it on screen, I'd pipe it to a file and open that in a text editor. That will disappear when I close the file. As a bonus: I can then use grep without having to repeat whatever command I used.
Even more importantly: I want the command to behave identically regardless of whether its stdin or stdout is /dev/null or a terminal or a socket or a serial port or a pipe or anything else that it can read or write with. Try writing a script when the tools themselves change how they behave whether they're running in a script or in a terminal or elsewhere. It kinda sucks.
_less_ has a nice "&" command that is like "/" (search) but that filters instead like grep.
You can also pipe to an external command from less
But we smart coders. We think everything. Remind me later.
good advice
- (2024): https://news.ycombinator.com/item?id=39273932
- (2020): https://news.ycombinator.com/item?id=25304257
I mean before asking AI to implement :)
Nope. For debugging the program, it is nice to have some debug tracing option, but if it's not the program's specification to produce output, it should not produce any. If the program's specification is that it produces a certain output after a certain calculation, then it shall not produce any other output, even if that calculation takes three weeks.
"cp -r from to" is supposed to be quiet until it's done or hits an error.
It would be nice to have an agreed-upon protocol for progress reporting. For instance, imagine of we had file descriptor 3 as "stdprogress". Programs could dump specially formatted messages there which the parent job control shell could intercept and turn into a progress display (with multiple rows for pipeline elements and such). It's not bad; but fluff like this can't be in band with the output, or at least not by default.
Different thing, but I am reminded of the BSDs having SIGINFO.
> It's not bad; but fluff like this can't be in band with the output, or at least not by default.
FWIW, I would describe stderr as being out of band. IIRC that's how e.g. pv works; `<file.img pv | dd of=/dev/foo` sends data along stdout while giving status info to the user since stderr isn't being piped.
That was initially USR1 and USR2 as process signals, well, at least across binutils and coreutils.
I just wish that UNIX architecture or POSIX would have been modernized since then, like with JSONL based process communication or similar things.
In Go I usually end up building my own JSONL protocol to marshal/unmarshal states between long running processes. Wish that could've been a POSIX standard.