←back to thread

/dev/null is an ACID compliant database

(jyu.dev)
587 points swills | 1 comments | 23 Oct 25 21:28 UTC | HN request time: 0s | source
Show context
pyuser583 ◴[23 Oct 25 22:19 UTC] No.45688089[source]▶
I've used /dev/null for exactly this purpose. I have output that needs to go somewhere, and I don't want to worry about whether that somewhere can handle it.

Later on in deployment, it will go somewhere else. Somewhere that has been evaluated for being able to handle it.

In that way, /dev/null is to storage what `true` is to execution - it just works.

replies(1): >>45688260 #
CaptainOfCoit ◴[23 Oct 25 22:36 UTC] No.45688260[source]▶
Bug free software is a pipe dream, but if there is anything I've never encountered any bugs with, /dev/null and true is certainly in the top 3.
replies(4): >>45688480 #>>45688959 #>>45690296 #>>45692706 #
noir_lord ◴[23 Oct 25 22:56 UTC] No.45688480[source]▶
Joking aside I can’t ever remember seeing a bug in either bash or zsh, never seen either crash or segfault and anytime I’ve had weirdness it’s always turned out to be me missing something.

Both (along with a lot of the standard utilities) are a testament to what talented C programmers plus years of people beating on them in unintended ways can achieve in terms of reliability/stability.

replies(7): >>45688631 #>>45688712 #>>45689009 #>>45689182 #>>45689808 #>>45689909 #>>45692642 #
1718627440 ◴[24 Oct 25 00:14 UTC] No.45689182[source]▶
Programs not outputting a final newline to stdout leave a prompt that doesn't start on column 0, and readline seams to not takes this into consideration, but still optimizes redraws and overwrites so you get an inconsistent display. This bugs seam to exist in a lot of shells and interactive programs. The program causing the issue isn't POSIX conform though.
replies(2): >>45689424 #>>45692721 #
tuetuopay ◴[24 Oct 25 09:38 UTC] No.45692721[source]▶
I don't get why this is still the case on classic shells. fish properly puts the prompt on column zero, while outputting a small "line return arrow" at the end of the command to indicate it lacked one.
replies(1): >>45694958 #
mort96 ◴[24 Oct 25 14:22 UTC] No.45694958[source]▶
It's arguably not the shell's role to protect against garbled output. Do you expect a shell to reset the TTY state after every command too in case you accidentally `cat /dev/urandom` and the terminal emulator enters a weird state due to random escape sequences?

The newline is a line terminator, a command outputting an incomplete line without a line terminator is producing garbled non-textual output. Files which contain incomplete lines without a line terminator are similarly garbled non-textual files and not very different from /dev/urandom or any other binary file.

replies(4): >>45695121 #>>45695354 #>>45698206 #>>45698404 #
1. schoen ◴[24 Oct 25 14:39 UTC] No.45695121[source]▶
I understand the terminal-garbling issue and know that I should run "reset" in this case (and that it wasn't the shell's fault), but I bet a lot of users who aren't very familiar with this might feel that the shell is "in charge of" the terminal or "in charge of" the whole interaction, and so that it actually should be more proactive in making sure that the terminal is in a visible sensible, usable, understandable state as often as possible -- in this case probably whenever a program exits and a new prompt is displayed?