Live data from Hacker News

What does " 2>&1 " mean?

stackoverflow.com

81–90 of 260 posts

Re: What does " 2>&1 " mean?

#81
post #51

Earlier quoted context omitted.

Another fun consequence of this is that you can initialize otherwise-unset file descriptors this way: $ cat foo.sh #!/usr/bin/env bash >&1 echo "will print on stdout" >&2 echo "will print on stderr" >&3 echo "will print on fd 3" $ ./foo.sh 3>&1 1>/dev/null 2>/dev/null will print on fd 3 It's a trick you can use if you've got a super chatty script or set of scripts, you want to silence or slurp up all of their output,…

Interesting. Is this just literally “fun”, or do you see real world use cases?

I have used this in the past when building shell scripts and Makefiles to orchestrate an existing build system:

https://github.com/jez/symbol/blob/master/scaffold/symbol#L1...

The existing build system I did not have control over, and would produce output on stdout/stderr. I wanted my build scripts to be able to only show the output from the build system if building failed (and there might have been multiple build system invocations leading to that failure). I also wanted the second level to be able to log progress messages that were shown to the user immediately on stdout.

    Level 1: create fd=3, capture fd 1/2 (done in one place at the top-level)
    Level 2: log progress messages to fd=3 so the user knows what's happening
    Level 3: original build system, will log to fd 1/2, but will be captured
It was janky and it's not a project I have a need for anymore, but it was technically a real world use case.

Re: What does " 2>&1 " mean?

#82
post #11

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 instead of numbers. And sh/bash's syntax is so weird because the programmer at the time thought it was convenient to do it like that. Nobody ever asked a user.

It should be a lesson to learn on how simple, logical and reliable tools can last decades.

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.

Re: What does " 2>&1 " mean?

#83
post #11

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 instead of numbers. And sh/bash's syntax is so weird because the programmer at the time thought it was convenient to do it like that. Nobody ever asked a user.

The programmers were the users. They asked. They said it was ok.

Re: What does " 2>&1 " mean?

#85
post #11

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 instead of numbers. And sh/bash's syntax is so weird because the programmer at the time thought it was convenient to do it like that. Nobody ever asked a user.

Wait until you find out where "tty" comes from!

Re: What does " 2>&1 " mean?

#86
post #51

Earlier quoted context omitted.

Another fun consequence of this is that you can initialize otherwise-unset file descriptors this way: $ cat foo.sh #!/usr/bin/env bash >&1 echo "will print on stdout" >&2 echo "will print on stderr" >&3 echo "will print on fd 3" $ ./foo.sh 3>&1 1>/dev/null 2>/dev/null will print on fd 3 It's a trick you can use if you've got a super chatty script or set of scripts, you want to silence or slurp up all of their output,…

Interesting. Is this just literally “fun”, or do you see real world use cases?

Red hat and other RPM based distributions recommended kickstart scripts use tty3 using a similar method

Re: What does " 2>&1 " mean?

#89
post #29
post #25

Earlier quoted context omitted.

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.

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.

Counter reason in favor is that you can always count on it being there and working the same way. Perl is too out of fashion and python has too many versioning/library complexities.

You have to write the crappy sh script once but then you get simple, easy usage every time. (If you're revising the script frequently enough that sh/bash are the bottleneck, then what you have is a dev project and not a script, use a programming language).

Post reply on HN