10 ms·
What does " 2>&1 " mean?
- datawars 7mo ago[dead]
- vessenes 7mo agoNot sure why this link and/or question is here, except to say LLMs like this incantation. It redirects STDERR (2) to where STDOUT is piped already (&1). Good for dealing with random CLI tools if you're not a human.
- ElijahLynn 7mo agoI found the explanation useful, about "why" it is that way. I didn't realize the & before the 1 means to tell it is the filedescriptor 1 and not a file named 1.
- weavie 7mo agoI get the ocassional file named `1` lying around.
- LtWorf 7mo agoIt's an operator called ">&", the 1 is the parameter.
- WJW 7mo agoWell sure, but surely this takes some inspiration from both `&` as the "address of" operator in C as well as the `>` operator which (apart from being the greater-than operator) very much implies "into" in many circumstances. So `>&1` is "into the file descriptor pointed to by 1", and at the time any reasonable programmer would have known that fd 1 == STDOUT.
- hrmtst93837 7mo ago[flagged]
- WhyNotHugo 7mo agoHumans used this combination extensively for decades too. I'm no aware of any other simple way to grep both stdout and stderr from a process. (grep, or save to file, or pipe in any other way).
- TacticalCoder 7mo ago"not humans" are using this extensively precisely because humans used this combination extensively for decades. It's muscle-memory for me. And so is it for LLMs.
- GetTheFacts 7mo ago>It's muscle-memory for me. And so is it for LLMs. LLMs have neither muscles nor memories. They're token combinators based on statistical correlation, no more, no less. That's not to say LLMs can't be useful when they string together tokens. Quite the contrary, in fact. But let's not pretend LLMs are something they're not.
- anitil 7mo agoI've also found llms seem to love it when calling out to tools, I suppose for them having stderr interspersed messaged in their input doesn't make much difference
- gnabgib 7mo agoBetter: Understanding Linux's File Descriptors: A Deep Dive Into '2>&1' and Redirection https://news.ycombinator.com/item?id=41384919 https://news.ycombinator.com/item?id=41384919 https://news.ycombinator.com/item?id=39095755 https://news.ycombinator.com/item?id=39095755
- murphyslaw 7mo agoO'Reilly's Essential System Administration [1], I never do a job interview without it. [1]: https://www.oreilly.com/library/view/essential-system-administration/0596003439/ https://www.oreilly.com/library/view/essential-system-admini...
- wahern 7mo agoI 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 redirection operators are executed left-to-right, and traditionally each operator was executed immediately as it was parsed, left-to-right. The pipe operator works similarly, though it's a combination of fork and dup'ing, with the command being forked off from the shell as a child before processing the remainder of the line. Though, understanding it this way makes the direction of the angled bracket a little odd; at least for me it's more natural to understand dup2(2, 1) as 2<1, as in make fd 2 a duplicate of fd 1, but in terms of abstract I/O semantics that would be misleading.
- emmelaich 7mo agoYep, there's a strong unifying feel between the Unix api, C, the shell, and also say Perl. Which is lost when using more modern or languages foreign to Unix.
- tkcranny 7mo agoPython too under the hood, a lot of its core is still from how it started as a quick way to do unixy/C things.
- ifh-hn 7mo agoHaha, I'm even more confused now. I have no idea what dup is...
- jpollock 7mo agoThere are a couple of ways to figure out. open a terminal (OSX/Linux) and type: man dup open a browser window and search for: man dup Both will bring up the man page for the function call. To get recursive, you can try: man man unix (the unix is important, otherwise it gives you manly men)
- zem 7mo agoback when stackoverflow was still good and useful, I asked about some stderr manipulation[0] and learnt a lot from the replies [0] https://stackoverflow.com/questions/3618078/pipe-only-stderr-through-a-filter https://stackoverflow.com/questions/3618078/pipe-only-stderr...
- adzm 7mo agoI always wondered if there ever was a standard stream for stdlog which seems useful, and comes up in various places but usually just as an alias to stderr
- knfkgklglwjg 7mo agoPowershell has ”stdprogress”
- jibal 7mo ago/dev/stderr on Linux
- ucarion 7mo agoI've almost never needed any of these, but there's all sorts of weird redirections you can do in GNU Bash: https://www.gnu.org/software/bash/manual/bash.html#Redirecting-Output https://www.gnu.org/software/bash/manual/bash.html#Redirecti...
- keithnz 7mo agoagentic ai tends to use it ALL the time.
- amelius 7mo agoIt'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.
- zahlman 7mo agoAt the time, the users were the programmers.
- booi 7mo agoarguably if you're using the CLI they still are
- kube-system 7mo agonah, we have long had other disciplines using the CLI who do not write their own software, e.g. sysadmins
- spott 7mo agoYea, they are just much higher level programmers… most programmers don’t know the low level syscall apis.
- spiralcoaster 7mo agoYeah 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 7mo agoThis 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.
- emmelaich 7mo agoA gotcha for me originally and perhaps others is that while using ordering like $ ./outerr >blah 2>&1 sends stdout and stderr to blah, imitating the order with pipe instead does not. $ ./outerr | 2>&1 cat >blah err This is because | is not a mere redirector but a statement terminator. (where outerr is the following...) echo out echo err >&2
- inigyou 7mo agoWhy would that second one be expected to work?
- time4tea 7mo agoUseless use of cat error/award But also | isnt a redirection, it takes stdout and pipes it to another program. So, if you want stderr to go to stdout, so you can pipe it, you need to do it in order. bob 2>&1 | prog You usually dont want to do this though.
- kazinator 7mo agoThe point is that the order in which that is processed is not left to right. First the | pipe is established as fd [1]. And then 2>&1 duplicates that pipe into [2]. I.e. right to left: opposite to left-to-right processing of redirections. When you need to capture both standard error and standard output to a file, you must have them in this order: bob > file 2>&1 It cannot be: bob 2>&1 > file Because then the 2>&1 redirection is performed first (and usually does nothing because stderr and stdout are already the same, pointing to your terminal). Then > file redirects only stdout. But if you change > file to | process, then it's fine! process gets the combined error and regular output.
- murphyslaw 7mo agoYou can pipe the fd directly: # echo 1 >&2 2>| echo
- emmelaich 7mo agoTry it without the `cat` and tell me what you get.
- wodenokoto 7mo agoI enjoyed the commenter asking “Why did they pick such arcane stuff as this?” - I don’t think I touch more arcane stuff than shell, so asking why shell used something that is arcane relative to itself is to me arcane squared.
- Normal_gaussian 7mo agoI love myself a little bit of C++. A good proprietary C++ codebase will remind you that people just want to be wizards, solving their key problem with a little bit of magic. I've only ever been tricked into working on C++...
- nurettin 7mo agoI saw this newer bash syntax for redirecting all output some years ago on irc foo &> file foo |& program
- rezonant 7mo agoI didn't know about |&, not sure if it was introduced at the same time. So I'd always use &> for redirection to file and 2>&1 for piping
- ndsipa_pomu 7mo agoI think the "|&" is the most intuitive syntax - you can just amend an existing pipe to also include STDERR
- arjie 7mo agoRedirects are fun but there are way more than I actually routinely use. One thing I do is the file redirects. diff <(seq 1 20) <(seq 1 10) 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.
- Calzifer 7mo agoProcess substitution and calling it file redirect is a bit misleading because it is implemented with named pipes which becomes relevant when the command tries to seek in them which then fails. Also the reason why Zsh has an additional =(command) construct which uses temporary files instead.
- wmanley 7mo agoIt'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 without having an extra socat process and pipes running (and the buffering, odd flush behaviour, etc.). It would be great if programs expected to receive input file arguments as open fds, rather than providing filenames and having the process open them itself. Sandboxing would be trivial, as would understanding the inputs and outputs of any program. It's frustrating to me because the underlying unix system supports this so well, it's just the conventions of userspace that get in the way. [^1]: I know about /dev/tcp, but it's very limited.
- 1718627440 7mo agoYeah 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.
- csours 7mo agoIf you need to know what 2>&1 means, then I would recommend shellcheck It's very, very easy to get shell scripts wrong; for instance the location of the file redirect operator in a pipeline is easy to get wrong.
- TacticalCoder 7mo agoAs someone who use LLMs to generate, among others, Bash script I recommend shellcheck too. Shellcheck catches lots of things and shall really make your Bash scripts better. And if for whatever reason there's an idiom you use all the time that shellcheck doesn't like, you can simply configure shellcheck to ignore that one.
- maxeda 7mo ago> I am thinking that they are using & like it is used in c style programming languages. As a pointer address-of operator. [...] 2>&1 would represent 'direct file 2 to the address of file 1'. I had never made the connection of the & symbol in this context. I think I never really understood the operation before, treating it just as a magic incantation but reading this just made it click for me.
- jibal 7mo agoNo, the shell author needed some way to distinguish file descriptor 1 from a file named "1" (note that 2>1 means to write stderr to the file named "1"), and '&' was one of the few available characters. It's not the address of anything. To be consistent, it would be &2>&1, but that makes it more verbose than necessary and actually means something else -- the first & means that the command before it runs asynchronously.
- kazinator 7mo agoIt's not inconsistent. The & is attached to the redirection operator, not to the 1 token. The file descriptor being redirected is also attached: Thus you cannot write: 2 > &1 You also cannot write 2 >& 1 However you may write 2>& 1 The n>& is one clump.
- kazinator 7mo agoIt means redirect file descriptor 2 to the same destination as file descriptor 1. Which actually means that an undelrying dup2 operation happens in this direction: 2 <- 1 // dup2(2, 1) The file description at [1] is duplicated into [2], thereby [2] points to the same object. Anything written to stderr goes to the same device that stdout is sending to. The notation follows I/O redirections: cmd > file actually means that a descriptor [n] is first created for the open file, and then that descriptor's decription is duplicated into [1]: n <- open("file", O_RDONLY) 1 <- n
- nodesocket 7mo agoI understand how this works, but wouldn’t a more clear syntax be: command &2>&1 Since the use of & signifies a file descriptor. I get what this ACTUALLY does is run command in the background and then run 2 sending its stout to stdout. That’s completely not obvious by the way.
- nikeee 7mo agoSo if i happen to know the numbers of other file descriptors of the process (listed in /proc), i can redirect to other files opened in the current process? 2>&1234? Or is it restricted to 0/1/2 by the shell? Would probably be hard to guess since the process may not have opened any file once it started.
- viraptor 7mo agoNo restrictions. You can create your own beautiful monsters that way. > Would probably be hard to guess since the process may not have opened any file once it started. You need to not only inspect the current state, but also race the process before the assignments change.
- hugmynutus 7mo ago> Or is it restricted to 0/1/2 by the shell? It is not. You can use any arbitrary numbers provided they're initialized properly. These values are just file descriptors. For Example -> https://gist.github.com/valarauca/71b99af82ccbb156e0601c5df8a27d8b https://gist.github.com/valarauca/71b99af82ccbb156e0601c5df8... I've used (see: example) to handle applications that just dump pointless noise into stdout/stderr, which is only useful when the binary crashes/fails. Provided the error is marked by a non-zero return code, this will then correctly display the stdout/stderr (provided there is <64KiB of it).
- Normal_gaussian 7mo agoI know the underlying call, but I always see the redirect symbols as indicating that "everything" on the big side of the operator fits into a small bit of what is on the small side of the operator. Like a funnel for data. I don't know the origin, but I'm believing my fiction is right regardless. It makes <(...) make intuitive sense. The comment about "why not &2>&1" is probably the best one on the page, with the answer essentially being that it would complicate the parser too much / add an unnecessary byte to scripts.
- solomonb 7mo agoMan I miss stack overflow. It feels so much better to ask humans a question then the machine, but it feels impossible to put the lid back on the box.
- numbers 7mo agoand no ai fluff to start or end the answer, just facts straight to the point.
- globular-toast 7mo agoIt is possible. Many people choose a healthy lifestyle instead of becoming morbidly obese and incapable which is easy to do in our society.
- rkachowski 7mo agoIt's really jarring to see this wave of nostalgia for "the good old days" appear since ~2025. Suddenly these rose tinted glasses have dropped and everything before LLM usage became ubiquitous was a beautiful romantic era of human collaboration, understanding and craftsmanship. I still acutely remember the gatekeeping and hostility of peak stack overflow, and the inanity of churning out jira tickets as fast as possible for misguided product initiatives. It's just wild yo
- LatencyKills 7mo agoMSGA: Make Software Great Again? /s
- mrpopo 7mo agoProbably people complaining about AI today were fine with Stack Overflow before and didn't have anything to complain about back then. I also had a better experience with Stack Overflow over AI. It's been unable to tell me that I couldn't assign a new value to my std::optional in my specific case, and kept hallucinating copy constructor rules. A Stack Overflow question matching my problem cleared that up for me. Sometimes you need someone to tell you no.
- esafak 7mo agoIt means someone did not bother to name their variables properly, reminding you to use a shell from this century.
- JackAcid 7mo agoA.I. has made the self-important neckbeards of Stack Overflow obsolete.
- deleted 7mo ago[deleted]
- alwillis 7mo agoYes! And they're not happy about it.
- charcircuit 7mo agoI am surprised that there still is no built in way to pipe stdout and stderr. *| would be much more ergonomic than 2>&1 |.
- raincole 7mo agoThe comments on stackoverflow say the words out of my mouth so I'll just copy & paste here: > but then shouldn't it rather be &2>&1? > & is only interpreted to mean "file descriptor" in the context of redirections. Writing command &2>& is parsed as command & and 2>&1 That's where all the confusion comes from. I believe most people can intuitively understand > is redirection, but the asymmetrical use of & throws them off. Interestingly, Powershell also uses 2>&1. Given an once-a-lifetime chance to redesign shell, out of all the Unix relics, they chose to keep (borrow) this.
- zwischenzug 7mo agoIsn't that because of posix?
- TheDong 7mo agoPowershell is not posix compliant and does not pretend to be. Like conditionals using `()` instead of `[]` is already a clear departure from posix
- b40d-48b2-979e 7mo agoI don't think they were talking about pwsh? pwsh actually has types and is its own programming lang unlike *sh, so it doesn't rely on builtin command exit codes.
- zwischenzug 7mo agoDon't know if this is definitive, but: https://www.johndcook.com/powershell.html#:~:text=The%20core%20of%20the%20PowerShell,1003.2%20standard%20for%20Unix%20shells. https://www.johndcook.com/powershell.html#:~:text=The%20core... POSIX Korn shell, specifically, according to Wikipedia: https://en.wikipedia.org/wiki/PowerShell#Grammar https://en.wikipedia.org/wiki/PowerShell#Grammar so maybe it inherited 2>&1 from Korn shell, which in turn was POSIX. But yeah, Powershell was not built purely to be a POSIX shell, but I thought it tried to be compatible where it made sense (hence the seeming clash of cultures).
- 7mo ago
- whatever1 7mo agoAwesome. Next week I will forget it again.
- simoncion 7mo agoWhile you're still thinking about it, make sure to bookmark the "redirections" section of the manual. [0] Also useful might be the "pipelines" section [1] to remind you of the "|&" operator. [0] <https://www.gnu.org/software/bash/manual/bash.html#Redirections https://www.gnu.org/software/bash/manual/bash.html#Redirecti...> [1] <https://www.gnu.org/software/bash/manual/bash.html#Pipelines-1 https://www.gnu.org/software/bash/manual/bash.html#Pipelines...>
- AnimalMuppet 7mo agoSomewhat off topic, but related: I worked at this place that made internet security software. It ran on Windows, and on various flavors of Unix. One customer complained about our software corrupting files on their hard disk. Turns out they had modified their systems so that a newly-spawned program was not given a stderr. That is, it was not handed 0, 1, and 2 (file descriptors), but only 0 and 1. So whenever our program wrote something to stderr, it wrote to whatever file had been the first one opened by the program. We talked about fixing this, briefly. Instead we decided to tell the customer to fix their broken environment.
- MathMonkeyMan 7mo agoI regularly refer to [the unix shell specification][1] to remember the specifics of ${foo%%bar} versus ${foo#bar}, ${parameter:+word} versus ${parameter:-word}, and so on. It also teaches how && and || work, their relation to [output redirection][3] and [command piping][2], [(...) versus {...}][4], and tricky parts like [word expansion][5], even a full grammar. It's not exciting reading, but it's mostly all there, and works on all POSIXy shells, e.g. sh, bash, ksh, dash, ash, zsh. [1]: https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html [2]: https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_009_002 https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html... [3]: https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_007 https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html... [4]: https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_009_004 https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html... [5]: https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_006 https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html...
- tempodox 7mo agoThat’s nothing, try `&>`.
- oguz-ismail2 7mo agoThis is one of those places where Bash diverges from POSIX. The standard says `echo &>/dev/null' is two commands, namely `echo &' and `>/dev/null', but Bash interprets it as redirect both stdout and stderr of `echo' to `/dev/null' both in normal and POSIX mode.
- jolmg 7mo agoAlso known as `>&`. cmd >&out-and-err.txt
- otikik 7mo agoTo me it means “I didn’t want to come up with an intelligible syntax for this”. Shell scripts have many dark corners and sharp edges like this is one.
- piekvorst 7mo agorc [1] replaced it with a far more telling >[1=2] and >[1=] for closing. 1: https://p9f.org/sys/doc/rc.html https://p9f.org/sys/doc/rc.html
- hinkley 7mo agoI first encountered this thirty four years ago and I still hate it. Almost as much as I hate when people ask me to explain it. Look man, I didn’t invent this stupid shit, and I’m not telling you it’s brilliant, so don’t kill the messenger. I thought I’d seen somewhere that zsh had a better way to do this but I must have imagined it. Or maybe I’m confusing it with fish.
- xg15 7mo agoAlways wondered how the parser managed the ambiguity between & for file descriptors and & to start background tasks. (And without a good mental model, I kept forgetting where to put the & correctly in redirects) Treating ">&" as a distinct operator actually makes an elegant solution here. I like the idea.
- kuon 7mo agoIt was never fully clear to me why the ordre mattered.
- aichen_dev 7mo ago[dead]
- parasti 7mo agoCool tip - never knew this. I always figured piping to `tee` is a must in order to view-and-save command output at the same time. Turns out I can do "command >&1 >file.txt" instead!
- stuartjohnson12 7mo agoUnfortunately you are replying to an AI spambot
- cpach 7mo agoIf you see an account that you suspect is a spambot, please send an email to hn@ycombinator.com, then the mods can take action.
- lgeorget 7mo agoIt reminds me of this answer I made some years ago: https://unix.stackexchange.com/a/138046 https://unix.stackexchange.com/a/138046 The question was how to remember it's "2>&1" and not "2&>1". If you think of "&1" as the address/destination of, the syntax is quite natural.
- k3vinw 7mo agoPerhaps it’s the odd placement of the ampersand. Something like >2&1 would make more sense to me. On the other hand, pipe “|” is brilliant!
- everyone 7mo agostackoverflow, how quaint. Anyone here remember when it was actually useful and questions like the one featured could be asked and answered?
- joelthelion 7mo agoClosed as not a real question.
- james_marks 7mo agoClaude’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 going” (the & just means “I’m referring to a pipe, not a file named 1”)
- r4bbb1t 7mo ago[dead]
- NekkoDroid 7mo ago> • 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")
- DonaldPShimoda 7mo ago> 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.
- james_marks 7mo agoFWIW, I clicked the link, scanned the SO thread, then scanned the HN thread. The "bunch of important words taken out" is exactly the service I paid AI for. "I didn't have time to write you a short letter, so I wrote you a long one." is real.
- ontouchstart 7mo agoSometime all you need is to RTMF from the source instead of Nth hand information (N > 1) https://www.gnu.org/software/bash/manual/html_node/Redirections.html https://www.gnu.org/software/bash/manual/html_node/Redirecti...
- GuB-42 7mo agoGreat if you know where to look, but most people who ask themselves the question don't know they have to look up the bash manual in the "redirection" section. The usual thing (before LLMs) is to Google the question, but for the question to appear in Google, someone has to ask it first, and here we are. Also the Stackoverflow answers give different perspectives, context, etc... rather than just telling you what it does, which is useful to someone unfamiliar with how redirections work. As I said, someone who doesn't know about "2>&1" is unlikely to be an expert given how common the pattern is, so a little hand holding doesn't hurt.
- layer8 7mo ago> Great if you know where to look, but most people who ask themselves the question don't know they have to look up the bash manual in the "redirection" section. Where else would you look but in the manual of your shell? And you don’t have to know in which section to look, you can just search for “2>&1” in the bash man page.
- GuB-42 7mo agoWhat is a command and what is shell syntax is not always obvious, especially to a beginner, which I assume most people asking this question are. Take the command "ls -l ~/.. ; fg" for instance. What is interpreted by the shell and what are commands? If you have some experience in bash, you probably know, and therefore you know which part to look in which man page, but you probably also know "2>&1". Spoiler: "-l" is part of the command, so look in the "ls" manpage. "~", is expanded by the shell, ";" is shell syntax and "fg" is a builtin, all three are in the "bash" manpage. ".." is part of the filesystem.
- 7mo ago
- ptaffs 7mo agoI understood the point of the question was how shells work seems very context driven. An & here means something different to an & there. IFS=\| read A B C <<< "first|second|third" the read is executed and the IFS assignment is local to the one command echo hello this will "hello this", even though in the assignment above the space was important an & at the end of a line is run the task background and in the middle of the redirect isn't. All these things can be learned, but it's hard to explain the patterns, I think.
- NoSalt 7mo agoI always said it as: "2 goes into the address of 1", so wherever 1 is pointing, that's where 2 is going.
- twocommits 7mo ago[dead]
- casey2 7mo agoThis is why I dislike sites like stackoverflow. If I needed a quick lookup the v7 manpage explains it better, the v6 doesn't have it, but that's because unix didn't have bourne shell til V7 https://man.cat-v.org/unix_7th/1/sh#:~:text=%3C%26digit%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20The%20standard,descrip%2D%0A%20%20%20%20%20%20%20%20%20%20tor%201. https://man.cat-v.org/unix_7th/1/sh#:~:text=%3C%26digit%0A%2... Seriously when it comes to unix RTFM RTFM RTFM and you'll get the top comment on SO and HN rolled into one.
- antonvs 7mo agoIt means that whoever designed it didn’t have very good taste regarding language ergonomics.