Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What does " 2>&1 " mean?

stackoverflow.com

Post reply on HN
Print view View original

201–210 of 260 posts

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

#201

Post by 1718627440 »

47282847 wrote: post #59
jez wrote: 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?

This is often used by shell scripts to wrap another program, so that those's input and output can be controlled. E.g. Autoconf uses this to invoke the compiler and also to control nested log output.

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

#202

Post by miki123211 »

goku12 wrote: post #134
wahern wrote: post #4

I find it easier to understand in terms of the Unix syscall API. `2>&1` literally translates as `dup2(1, 2)`, and indeed that's exactly how it works. In the classic unix shells that's all that happens; in more modern shells there may be some additional internal bookkeeping to remember state. Understanding it as dup2 means it's easier to understand how successive redirections work, though you also have to know that re…

This is probably one of the reasons why many find POSIX shell languages to be unpleasant. There are too many syntactical sugars that abstract too much of the underlying mechanisms away, to the level that we don't get it unless someone explains it. Compare this with Lisps, for example. There may be only one branching construct or a looping construct. Yet, they provide more options than regular programming languages us…

Shell is optimized for the minimal number of keystrokes (just like Vim, Amadeus and the Bloomberg Terminal are optimized for the minimum number of keystrokes. Programming languages are primarily optimized for future code readability, with terseness and intuitiveness being second or third (depending on language).

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

#203

Post by r4bbb1t »

james_marks wrote: post #200

Claude’s answer, which is the only one that clicked for me: Normally when you do something like command > file.txt, you’re only capturing the normal output — errors still go to your screen. 2>&1 is how you say: “send the error pipe into the same place as the normal output pipe.” Breaking it down without jargon: • 2 means “the error output” • > means “send it to” • &1 means “wherever the normal output is currently goi…

[dead]

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

#204

Post by 1718627440 »

fulafel wrote: post #117
amelius wrote: 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.

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.

Handles and pointers are the same concept, the difference is just who resolves them. Pointers don't represent hardware addresses either.

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

#205

Post by direwolf20 »

bmicraft wrote: post #154
kristopolous wrote: post #144

Earlier quoted context omitted.

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

That's what named pipes do.

They don't. They're single reader and, if I remember correctly, sequential single writer.

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

#206

Post by 1718627440 »

wmanley wrote: post #195
arjie wrote: post #21

Redirects are fun but there are way more than I actually routinely use. One thing I do is the file redirects. diff I do that with diff <(xxd -r file.bin) <(xxd -r otherfile.bin) sometimes when I should expect things to line up and want to see where things break.

It's a shame that unix tools don't support file descriptors better. The ability to pass a file (or stream, or socket etc) directly into a process is so powerful, but few commands actually support being used this way and require filenames (or hostnames, etc) instead. Shell is so limited in this regard too. It would be great to be able to open a socket in bash[^1] and pass it to another program to read/write from witho…

Yeah I started to design all my (sub)programs this way. If it should also be invoked by the shell, I make a wrapper program that sets the fds correctly.

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

#207

Post by NekkoDroid »

james_marks wrote: post #200

Claude’s answer, which is the only one that clicked for me: Normally when you do something like command > file.txt, you’re only capturing the normal output — errors still go to your screen. 2>&1 is how you say: “send the error pipe into the same place as the normal output pipe.” Breaking it down without jargon: • 2 means “the error output” • > means “send it to” • &1 means “wherever the normal output is currently goi…

> • 2 means “the error output” • > means “send it to” • &1 means “wherever the normal output is currently going” (the & just means “I’m referring to a pipe, not a file named 1”)

If you want it with the correct terminology:

2 means "file descriptor 2", > means "assign the previous mentioned to the following", &2 means "file descriptor 1" (and not file named "1")

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

#208

Post by phailhaus »

Towaway69 wrote: post #126
phailhaus wrote: post #82

Earlier quoted context omitted.

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.

Are taxes simple? Why does Bash syntax have to be "simple"? For me, Bash syntax is simple.

Uh, reading a bash script shouldn't be as hard as doing your taxes. Bash syntax has to be simple because bash code is going to be read and reasoned by humans. Reading just a simple if statement in bash syntax requires a TON of knowledge to avoid shooting yourself in the foot. That's a massive failure of usability just to save a couple of keystrokes.

This is like saying "what's wrong with brainfuck??? makes sense to me!" Every syntax can be understood, that does not automatically make them all good ideas.

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

#210

Post by DonaldPShimoda »

james_marks wrote: post #200

Claude’s answer, which is the only one that clicked for me: Normally when you do something like command > file.txt, you’re only capturing the normal output — errors still go to your screen. 2>&1 is how you say: “send the error pipe into the same place as the normal output pipe.” Breaking it down without jargon: • 2 means “the error output” • > means “send it to” • &1 means “wherever the normal output is currently goi…

> Claude’s answer

This response is essentially just the second answer to the linked question (the response by dbr) with a bunch of the important words taken out.

And all it cost you to get it was more water and electricity than simply clicking the link and scrolling down — to say nothing of the other costs.

Post reply on HN