← Back to context

Comment by skywal_l

15 hours ago

There must be a law of system design about this, because this happens all the time. Every abstraction creates a class of users who are powerful but fragile.

People who build a system or at least know how it works internally want to simplify their life by building abstractions.

As people come later to use the system with the embedded abstractions, they only know the abstractions but have no idea of the underlying implementations. Those abstractions used to make perfect sense for those with prior knowledge but can also carry subtle bias which makes their use error prone for non initiated users.

> Those abstractions used to make perfect sense for those with prior knowledge but can also carry subtle bias which makes their use error prone for non initiated users.

I don't think 2>&1 ever made any sense.

I think shell language is simply awful.

  • > I don't think 2>&1 ever made any sense.

    It's not that hard. Consider the following:

      $ command &2>&1
    

    The shell thinks that you're trying to run the portion before the & (command) in the background and the portion after the & (2>&1) in the foreground. There is just one problem. The second part (2>&1) means that you're redirecting stderr/fd2 to stdout/fd1 for a command that is to follow (similar to how you set environment variables for a command invocation). However, you haven't specified the command that follows. The second part just freezes waiting for the command. Try it and see for yourself.

      $ command 2>1
    

    Here the shell redirects the output of stderr/fd2 to a file named 1. It doesn't know that you're talking about a file descriptor instead of a filename. So you need to use &1 to indicate your intention. The same confusion doesn't happen for the left side (fd2) because that will always be a file descriptor. Hence the correct form is:

      $ command 2>&1
    

    > I think shell language is simply awful.

    Honestly, I wish I could ask the person who designed it, why they made such decisions.

I like abstractions when they hide complexity I don't need to see nor understand to get my job done. But if abstractions misdirect and confuse me, they are not syntactical sugar to me, but rather poison.

(But I won't claim that I am always able to strike the right balance here)

Seems related to the Law of Leaky Abstractions?

  • It's not necessarily a leaky abstraction. But a lack of _knowledge in the world_.

    The abstraction may be great, the problem is the lack of intuitive understanding you can get from super terse, symbol heavy syntax.