6 ms·

It's a reminder of how archaic the systems we use are. File descriptors are like handing pointers to the users of your software. At least allow us to use names

• zahlman 9mo ago
  At the time, the users were the programmers.
  • booi 9mo ago
    arguably if you're using the CLI they still are
    • kube-system 9mo ago
      nah, we have long had other disciplines using the CLI who do not write their own software, e.g. sysadmins
    • spott 9mo ago
      Yea, they are just much higher level programmers… most programmers don’t know the low level syscall apis.
    • spiralcoaster 9mo ago
      Yeah but now they're using npm to install a million packages to do things like tell if a number is greater than 10000. The chances of the programmer wanting to understand the underlying system they are using is essentially nil.
  • amelius 9mo ago
    This is misleading because you use plural for both and I'm sure most of these UX missteps were _each_ made by a _single_ person, and there were >1 users even at the time.
    • Msurrow 9mo ago
      I think he meant that at that time all users were programmers. Yes, _all_ .
      • zahlman 9mo ago
        It was a bit of an over-generalization, but yes that's basically what I was going for.
    • andoando 9mo ago
      programmers are people too! bash syntax just sucks
    • ifh-hn 9mo ago
      > and there were >1 users even at the time. Are you sure there wasn't >&1 users... Sorry I'll get my coat.
      • mjevans 9mo ago
        I think that's likely to work as a no-op
      • worldsavior 9mo ago
        Get out.
    • NooneAtAll3 9mo ago
      did you mean to write "<1"?
• HackerThemAll 9mo ago
  > bash's syntax is so weird What should be the syntax according to contemporary IT people? JSON? YAML? Or just LLM prompt?
  • amelius 9mo ago
    Honestly, Python with the "sh" module is a lot more sane.
    • Normal_gaussian 9mo ago
      Is it more sane, or is it just what you are used to? Python doesn't really have much that makes it a sensible choice for scripting. Its got some basic data structures and a std-lib, but it comes at a non-trivial performance cost, a massive barrier to getting out of the single thread, and non-trivial overhead when managing downstream processes. It doesn't protect you from any runtime errors (no types, no compile checks). And I wouldn't call python in practice particularly portable... Laughably, NodeJS is genuinely a better choice - while you don't get multithreading easily, at least you aren't trivially blocked on IO. NodeJS also has pretty great compatibility for portability; and can be easily compiled/transformed to get your types and compile checks if you want. I'd still rather avoid managing downstream processes with it - but at least you know your JSON parsing and manipulation is trivial. Go is my goto when I'm reaching for more; but (ba)sh is king. You're scripting on the shell because you're mainly gluing other processes together, and this is what (ba)sh is designed to do. There is a learning curve, and there are footguns.
  • ifh-hn 9mo ago
    Nushell! Or powershell, but I much prefer nushell!
  • xeonmc 9mo ago
    Haskell
  • nazgul17 9mo ago
    Trying to be language agnostic: it should be as self-explanatory as possible. 2>&1 is all but. Why is there a 2 on the left, when the numbers are usually on the right. What's the relationship between 2 and 1? Is the 2 for std err? Is that `&` to mean "reference"? The fact you only grok it if you know POSIX sys calls means it's far from self explanatory. And given the proportion of people that know POSIX sys calls among those that use Bash, I think it's a bit of an elitist syntax.
• csours 9mo ago
  The conveniences also mean that there is more than ~one~ ~two~ several ways to do something. Which means that reading someone else's shell script (or awk, or perl, or regex) is INCREDIBLY inconvenient.
  • amelius 9mo ago
    Yes. There are many reasons why one shouldn't use sh/bash for scripting. But my main reason is that most scripts break when you call them with filenames that contain spaces. And they break spectacularly.
    • ndsipa_pomu 9mo ago
      You're not wrong, but there's fairly easy ways to deal with filenames containing spaces - usually just enclosing any variable use within double quotes will be sufficient. It's tricker to deal with filenames that contain things such as line breaks as that usually involves using null terminated filenames (null being the only character that is not allowed in filenames). e.g find . -type f -print0
      • deathanatos 9mo ago
        You're not wrong, but at my place, our main repository does not permit cloning into a directory with spaces in it. Three factors conspire to make a bug: 1. Someone decides to use a space 2. We use Python 3. macOS Say you clone into a directory with a space in it. We use Python, so thus our scripts are scripts in the Unix sense. (So, Python here is replacable with any scripting language that uses a shebang, so long as the rest of what comes after holds.) Some of our Python dependencies install executables; those necessarily start with a shebang: #!/usr/bin/env python3 Note that space. Since we use Python virtualenvs, #!/home/bob/src/repo/.venv/bin/python3 But … now what if the dir has a space? #!/home/bob/src/repo with a space/.venv/bin/python3 Those look like arguments, now, to a shebang. Shebangs have no escaping mechanism. As I also discovered when I discovered this, the Python tooling checks for this! It will instead emit a polyglot! #!/bin/bash # <what follows in a bash/python polyglot> # the bash will find the right Python interpreter, and then re-exec this # script using that interpreter. The Python will skip the bash portion, # b/c of cleverness in the polyglot. Which is really quite clever, IMO. But, … it hits (2.). It execs bash, and worse, it is macOS's bash, and macOS's bash will corrupt^W remove for your safety! certain environment variables from the environment. Took me forever to figure out what was going on. So yeah … spaces in paths. Can't recommend them. Stuff breaks, and it breaks in weird and hard to debug ways.
• xenadu02 9mo ago
  > At least allow us to use names instead of numbers. You can for the destination. That's the whole reason you need the "&": to tell the shell the destination is not a named file (which itself could be a pipe or socket). And by default you don't need to specify the source fd at all. The intent is that stdout is piped along but stderr goes directly to your tty. That's one reason they are separate. And for those saying "<" would have been better: that is used to read from the RHS and feed it as input to the LHS so it was taken.
• agentdrek 9mo ago
  It should be a lesson to learn on how simple, logical and reliable tools can last decades.
  • bool3max 9mo ago
    … Or how hard it is to replace archaic software that’s extremely prevalent.
  • crazygringo 9mo ago
    It's more like how the need for backwards compatibility prevents bad interfaces from ever getting improved.
  • phailhaus 9mo ago
    Bash syntax is anything but simple or logical. Just look at the insane if-statement syntax. Or how the choice of quotes fundamentally changes behavior. Argument parsing, looping, the list goes on.
    • akdev1l 9mo ago
      if statements are pretty simple if $command; then <thing> else <thing> fi You may be complaining about the syntax for the test command specifically or bash’s [[ builtin Also the choice of quotes changing behavior is a thing in: 1. JavaScript/typescript 2. Python 3. C/C++ 4. Rust In some cases it’s the same difference, eg: string interpolation in JavaScript with backticks
      • viraptor 9mo ago
        > Also the choice of quotes changing behavior is a thing in: In those languages they change what's contained in the string. Not how many strings you get. Or what the strings from that string look like. ($@ being an extreme example)
        • phatskat 9mo ago
          > $@ being an extreme example From the bash man page via StackOverflow: > @ Expands to the positional parameters, starting from one. When the expansion occurs within double quotes, each parameter expands to a separate word. That is, "$@" is equivalent to "$1" "$2" ... If the double-quoted expansion occurs within a word, the expansion of the first parameter is joined with the beginning part of the original word, and the expansion of the last parameter is joined with the last part of the original word. When there are no positional parameters, "$@" and $@ expand to nothing (i.e., they are removed). That’s…a lot. I think Bash is interesting in the “I’m glad it works but I detest having to work with it” kind of way. Like, fine if I’m just launching some processes or tail’ing some logs, but I’ve rarely had a time when I had to write an even vaguely complex bash script where I didn’t end up spending most of my time relearning how to do things that should be basic. Shellcheck was a big game changer at least in terms of learning some of the nuance from a “best practice” standpoint. I also think that the way bash does things is just a little too foreign from the rest of my computing life to be retained.
• spiralcoaster 9mo ago
  Who do you imagine the users were back when it was being developed?
  • crazygringo 9mo ago
    People who were not that one programmer? Even if you're a programmer, that doesn't mean you magically know what other programmers find easy or logical.
• nusl 9mo ago
  I quite like how archaic it is. I am turned off by a lot of modern stuff. My shell is nice and predictable. My scripts from 15 years ago still work just fine. No, I don't want it to get all fancy, thanks.
  • Steltek 9mo ago
    For a while, there was a strong trend of "I want to do everything in one singular language". Your coding is in language XYZ. Your build tools will be configured/written in XYZ. Your UI frontend will be generated from XYZ. Everything will be defined in XYZ. Shell is from a time when you had a huge selection of languages, each for different purposes, and you picked the right one for the job. For complex applications, you would have multiple languages working together. People look at Bash and think, "I would never dare do $Task with that language!". And you'd be right, because you're thinking you only have one tool in the toolbox.
• gdevenyi 9mo ago
  The programmers were the users. They asked. They said it was ok.
• jballanc 9mo ago
  Wait until you find out where "tty" comes from!
• Dylan16807 9mo ago
  > At least allow us to use names instead of numbers. You can use /dev/stdin, /dev/stdout, /dev/stderr in most cases, but it's not perfect.
  • murphyslaw 9mo ago
    > You can use /dev/stdin, /dev/stdout, /dev/stderr in most cases Never ever write code that assumes this. These dev shorthands are Linux specific, and you'll even need a certain minimum Linux version. I cringe at the amount of shell scripts that assume bash is the system interpreter, and not sh or ksh. Always assume sh, it's the most portable. Linux != Unix.
    • Dylan16807 9mo ago
      You shouldn't be assuming I'm writing code for Unix.
    • lpln3452 9mo ago
      lol truly informative and clearly something no one here knew. But your terminology is inaccurate. Please change it to GNU/Linux != Unix
    • eichin 9mo ago
      Actually, while the Actual Nodes are a linux thing, bash itself implements (and documents) them directly (in redirections only), along with /dev/tcp and /dev/udp (you can show with strace that bash doesn't reference the filesystem for these, even if they're present.) So, you're not wrong, but...
    • homebrewer 9mo ago
      It's a waste of time unless you're specifically targeting and testing mac, all of the BSDs, various descendants of Solaris, and other flavors of Unix. I wrote enough "portable shell" to run into so many quirks and slight differences in flags, in how different tools handle e.g. SIGPIPE. Adding a new feature in a straightforward way often makes it work only on 4/7 of the operating systems you're trying to support. You then rewrite it in a slightly different way (because it's shell — there's always 50 ways to do the same thing). This gets you to 5/7 working systems, but breaks one that previously worked. You rewrite it yet another way, fixing the new breakage, but another one breaks. Repeat this over and over again, trying to find an implementation that works everywhere, or start adding workarounds for each system. Spend an hour on a feature that should have taken two minutes. If it's anything remotely complicated, and you need portability, then use perl/python/go.
• varenc 9mo ago
  You can do: 2>/dev/stdout Which is about the same as `2>&1` but with a friendlier name for STDOUT. And this way `2> /dev/stdout`, with the space, also works, whereas `2> &1` doesn't which confuses many. But it's behavior isn't exactly the same and might not work in all situations. And of course I wish you could use a friendlier name for STDERR instead of `2>`
  • goku12 9mo ago
    > You can do: > > 2>/dev/stdout The situation where this is going to cause confusion is when you do this for multiple commands. It looks like they're all writing to a single file. Of course, that file is not an ordinary file - it's a device file. But even that isn't enough. You have to know that each command sees its own incarnation of /dev/stdout, which refers to its own fd1.
• fulafel 9mo ago
  They're more like capabilities or handles than pointers. There's a reason in Rust land many systems use handles (indices to a table of objects) in absence of pointer arithmetic. In the C API of course there's symbolic names for these. STDIN_FILENO, STDOUT_FILENO, etc for the defaults and variables for the dynamically assigned ones.
  • minitech 9mo ago
    What they point to are capabilities, but the integer handles that user space gets are annoyingly like pointers. In some respects, better, since we don’t do arithmetic on them, but in others, worse: they’re not randomized, and I’ve never come across a sanitizer (in the ASan sense) for them, so they’re vulnerable to worse race condition and use-after-free issues where data can be quietly sent to the entirely wrong place. Unlike raw pointers’ issues, this can’t even be solved at a language level. And maybe worst of all, there’s no bug locality: you can accidentally close the descriptor backing a `FILE*` just by passing the wrong small integer to `close` in an unrelated part of the program, and then it’ll get swapped out at the earliest opportunity.
    • eichin 9mo ago
      BITD the one "fd sanitizer" I ever encountered was "try using the code on VxWorks" which at the time was "posix inspired" at best - fds actually were pointers, so effectively random and not small integers. It didn't catch enough things to be worth the trouble, but it did clean up some network code (ISTR I was working on SNTP and Kerberos v4 and Kerberized FTP when I ran into this...)
  • 1718627440 9mo ago
    Handles and pointers are the same concept, the difference is just who resolves them. Pointers don't represent hardware addresses either.
    • fulafel 8mo ago
      Well, if we reduce it enough I supposed they can be seen as the same concept through a certain kind of philosophical lense. True and false also belong in the same class, they're handles to a pool of two possible boolean values. The difference is in scope. Pointers (aka memory addresses) are an ordered set of numbers enumerating all the memory locations, it enables unique powerful properties that enable a large set of uses that you cannot do with handles. And also make them quite unsafe and harder to understand.
• kristopolous 9mo ago
  I've long wanted easy, trivial multichannel i/o with duplication I want to be able to route x independent input and y independent output trivially from the terminal Proper i/o routing It shouldn't be hard, it shouldn't be unsolved, and it shouldn't be esoteric
  • bmicraft 9mo ago
    That's what named pipes do.
    • direwolf20 9mo ago
      They don't. They're single reader and, if I remember correctly, sequential single writer.
    • kristopolous 8mo ago
      Some kind of elegant unixy syntax would be nice [ ... Inputs ] | command | [ ... Outputs ] Basically select(1) as a cli syntax. I've done quite a bit of unix historical work ... Not enough for a talk at the CHM but decent enough that I have interviewed dozens of people. I really think some basic stuff was just left in a hacky state and we never revisited the primitives right. I've been trying to do that in my own projects For instance I should be able to do something like Command || processor And not have processor hijack the input without hacky pty stuff. I am intentionally using || here. There's lots of use cases to this: llms are the best, logging, rendering text, readline, translation, accessibility, it'd be a very useful primitive and it's impossible to do without a full pty wrapper or some kind of voodoo heuristic wrangling. Currently you have to do things like this https://github.com/day50-dev/ESChatch/blob/main/eschatch.py#L245 https://github.com/day50-dev/ESChatch/blob/main/eschatch.py#... It should be easy I know that some esoteric shells do it but I want everything to be traditional with better i/o features
• themafia 9mo ago
  > At least allow us to use names instead of numbers. Sure. Here's what that looked like: https://en.wikipedia.org/wiki/Job_Control_Language https://en.wikipedia.org/wiki/Job_Control_Language
• xorcist 9mo ago
  > At least allow us to use names instead of numbers Many people probably think in terms of "fd 0" and "fd 1" instead of "standard in" and "standard out", but should you wish to use names at least on modern Linux/BSD systems do: echo message >/dev/stdout echo error_message >/dev/stderr
  • vbezhenar 9mo ago
    I don't have macos right now but I think that it doesn't have these files. What's worse is that bash emulates these files so they might even somewhat work, but not in all situations. I distinctly remember issues with this command: install /dev/stdin file <<EOF something EOF
    • mechanicalpulse 9mo ago
      I do and it does. $ ls -al /dev/std* lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stderr -> fd/2 lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stdin -> fd/0 lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stdout -> fd/1 $ ls -n /dev/fd/[012] crw--w---- 1 501 4 0x10000000 Feb 27 13:38 /dev/fd/0 crw--w---- 1 501 4 0x10000000 Feb 27 13:38 /dev/fd/1 crw--w---- 1 501 4 0x10000000 Feb 27 13:38 /dev/fd/2 $ uname -v Darwin Kernel Version 24.6.0: Mon Jan 19 22:00:55 PST 2026; root:xnu-11417.140.69.708.3~1/RELEASE_ARM64_T6000 $ sw_vers ProductName: macOS ProductVersion: 15.7.4 BuildVersion: 24G517 Lest you think it's some bashism that's wrapping ls, they exist regardless of shell: $ zsh -c 'ls -al /dev/std*' lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stderr -> fd/2 lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stdin -> fd/0 lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stdout -> fd/1 $ csh -c 'ls -al /dev/std*' lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stderr -> fd/2 lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stdin -> fd/0 lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stdout -> fd/1 $ tcsh -c 'ls -al /dev/std*' lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stderr -> fd/2 lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stdin -> fd/0 lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stdout -> fd/1 $ ksh -c 'ls -al /dev/std*' lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stderr -> fd/2 lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stdin -> fd/0 lr-xr-xr-x 1 root wheel 0 Feb 24 15:08 /dev/stdout -> fd/1 I tried the install example that you provided and it worked on macOS as well as Linux.