3 ms·

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.

noir_lord 1y ago
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.
- qwertox 1y ago
  Amen.
- gucci-on-fleek 1y ago
  > I can’t ever remember seeing a bug in either bash Shellshock [0] is a rather famous example, but bugs like that are rare enough that they make the news when they're found. [0] https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29 https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29
- PokestarFan 1y ago
  I've been able to trigger a segfault in zsh with certain plugins, a directory with a lot of files/folders, and globs with a bunch of * characters.
- 1718627440 1y ago
  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.
  - latexr 1y ago
    > seams The correct spelling is “seems”. I first assumed it was a typo, but since you did it twice I thought you might like to know.
  - tuetuopay 1y ago
    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.
    - mort96 1y ago
      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.
      - schoen 1y ago
        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?
      - tuetuopay 1y ago
        > a command outputting an incomplete line without a line terminator is producing garbled non-textual output I would argue that no, there are many valid cases for commands to not produce a final \n in their output. The first example that come to mind is curl'ing a REST API whose body is a single line of JSON. Many of those will not bother with a final \n, and this does not qualify as "garbled output" in my book. I would even go as far as saying that a shell just printing the prompt at whatever place the cursor happens to be is a side-effect of how terminal emulation works and the fact it's just a character based terminal. This is actually something that Warp does pretty well, with a strong integration with the shell where your command is in a dedicated text box, by the virtue of it being GUI and leveraging GUIs. (I don't use it however, I'm too much of a sucker for dense UIs). However I do agree with your argument that it's not the role of the shell to protect you against `cat /dev/urandom` or `cat picture.png`. And fish indeed does not try. IMHO a shell is built for humans when in interactive mode (one of the raison d'être of fish), and the lack of final \n is such an annoyance that handling this specific edge case is worth it.
- rkeene2 1y ago
  I had a fun bug where bash would run scripts out of order! This would lead to impossible states, like if cat foo | false; then echo hmm; fi Producing output sometimes, depending on whether or not `cat foo` or `false` return value was used [0] https://lists.gnu.org/archive/html/bug-bash/2015-06/msg00010.html https://lists.gnu.org/archive/html/bug-bash/2015-06/msg00010...
  - lhmiles 1y ago
    This was an interesting read.
- AdieuToLogic 1y ago
  > 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. Given that this statement begins with "joking aside", I have to assume it is either a meta-joke or an uninformed opinion. Taking the subsequent sentence into account thoroughly reinforces the former. Well played. :-)
- probably_wrong 1y ago
  Depending on how you define "bash" and "bug", funny things happen when you run on a computer with 0 remaining hard drive space.
  - CaptainOfCoit 1y ago
    To be fair, bash won't be the only thing struggling when you end up in that state.
SanjayMehta 1y ago
False. Wait: that's just not true. Carry on.
MartijnBraam 1y ago
Ah you've never encountered /dev/null not existing yet, so when you try to trash data it will actually create a normal file there so every other program that uses it will actually append that file. Luckily it's usually a tmpfs
- CaptainOfCoit 1y ago
  > Ah you've never encountered /dev/null not existing yet I feel like that'd happen because of some other bug, I wouldn't consider that a bug in /dev/null :)
tuetuopay 1y ago
The only bug with it was due to my own stupidity. I wanted a quick way to see how fast a drive was, thus sending one of its large files to /dev/null was fine. Except I went too fast and cp'd the file to /dev/null. It took a while before noticing I had no more /dev/null on the machine (read: the time needed to fill the rootfs). In a panic, I removed the file. Seeing the machine collapse due to /dev/null missing was fun.
- augusto-moura 1y ago
  Wait, you can actually remove /dev/null? I always thought of it as a special driver file I guess that might not be true for all nixes out there
  - dredmorbius 1y ago
    /dev/null is a device file, and can be removed by root, or any user with write access to the /dev directory itself. You can recreate it with 'mknod /dev/null c 1 3; chmod 666 /dev/null'. The '1 3' are the major and minor device numbers, respectively, which are assigned / maintained by LANA, the Linux Assigned Numbers Authority.
  - RiverCrochet 1y ago
    Each item in the unix filesystem can be one of the following: file, directory, symlink, device node, socket, fifo. So nothing's stopping you from making it a normal file and capturing all the output programs send to it. For super funsies you can make it a symlink or socket, but I think most programs won't work if it's a socket. Nothing also is stopping you from removing it and mknod'ing a /dev/null into another device file, such as the one /dev/full or /dev/zero uses, or /dev/fb0 if you wanna be really silly.

noir_lord 1y ago

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.

qwertox 1y ago
Amen.
gucci-on-fleek 1y ago
> I can’t ever remember seeing a bug in either bash Shellshock [0] is a rather famous example, but bugs like that are rare enough that they make the news when they're found. [0] https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29 https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29
PokestarFan 1y ago
I've been able to trigger a segfault in zsh with certain plugins, a directory with a lot of files/folders, and globs with a bunch of * characters.
1718627440 1y ago
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.
- latexr 1y ago
  > seams The correct spelling is “seems”. I first assumed it was a typo, but since you did it twice I thought you might like to know.
- tuetuopay 1y ago
  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.
  - mort96 1y ago
    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.
    - schoen 1y ago
      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?
    - tuetuopay 1y ago
      > a command outputting an incomplete line without a line terminator is producing garbled non-textual output I would argue that no, there are many valid cases for commands to not produce a final \n in their output. The first example that come to mind is curl'ing a REST API whose body is a single line of JSON. Many of those will not bother with a final \n, and this does not qualify as "garbled output" in my book. I would even go as far as saying that a shell just printing the prompt at whatever place the cursor happens to be is a side-effect of how terminal emulation works and the fact it's just a character based terminal. This is actually something that Warp does pretty well, with a strong integration with the shell where your command is in a dedicated text box, by the virtue of it being GUI and leveraging GUIs. (I don't use it however, I'm too much of a sucker for dense UIs). However I do agree with your argument that it's not the role of the shell to protect you against `cat /dev/urandom` or `cat picture.png`. And fish indeed does not try. IMHO a shell is built for humans when in interactive mode (one of the raison d'être of fish), and the lack of final \n is such an annoyance that handling this specific edge case is worth it.
rkeene2 1y ago
I had a fun bug where bash would run scripts out of order! This would lead to impossible states, like if cat foo | false; then echo hmm; fi Producing output sometimes, depending on whether or not `cat foo` or `false` return value was used [0] https://lists.gnu.org/archive/html/bug-bash/2015-06/msg00010.html https://lists.gnu.org/archive/html/bug-bash/2015-06/msg00010...
- lhmiles 1y ago
  This was an interesting read.
AdieuToLogic 1y ago
> 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. Given that this statement begins with "joking aside", I have to assume it is either a meta-joke or an uninformed opinion. Taking the subsequent sentence into account thoroughly reinforces the former. Well played. :-)
probably_wrong 1y ago
Depending on how you define "bash" and "bug", funny things happen when you run on a computer with 0 remaining hard drive space.
- CaptainOfCoit 1y ago
  To be fair, bash won't be the only thing struggling when you end up in that state.

SanjayMehta 1y ago

False. Wait: that's just not true. Carry on.

MartijnBraam 1y ago

Ah you've never encountered /dev/null not existing yet, so when you try to trash data it will actually create a normal file there so every other program that uses it will actually append that file. Luckily it's usually a tmpfs

CaptainOfCoit 1y ago
> Ah you've never encountered /dev/null not existing yet I feel like that'd happen because of some other bug, I wouldn't consider that a bug in /dev/null :)

tuetuopay 1y ago

The only bug with it was due to my own stupidity. I wanted a quick way to see how fast a drive was, thus sending one of its large files to /dev/null was fine. Except I went too fast and cp'd the file to /dev/null. It took a while before noticing I had no more /dev/null on the machine (read: the time needed to fill the rootfs). In a panic, I removed the file. Seeing the machine collapse due to /dev/null missing was fun.

augusto-moura 1y ago
Wait, you can actually remove /dev/null? I always thought of it as a special driver file I guess that might not be true for all nixes out there
- dredmorbius 1y ago
  /dev/null is a device file, and can be removed by root, or any user with write access to the /dev directory itself. You can recreate it with 'mknod /dev/null c 1 3; chmod 666 /dev/null'. The '1 3' are the major and minor device numbers, respectively, which are assigned / maintained by LANA, the Linux Assigned Numbers Authority.
- RiverCrochet 1y ago
  Each item in the unix filesystem can be one of the following: file, directory, symlink, device node, socket, fifo. So nothing's stopping you from making it a normal file and capturing all the output programs send to it. For super funsies you can make it a symlink or socket, but I think most programs won't work if it's a socket. Nothing also is stopping you from removing it and mknod'ing a /dev/null into another device file, such as the one /dev/full or /dev/zero uses, or /dev/fb0 if you wanna be really silly.