Well, my phone decided to do a system upgrade in the middle of the night, which means I woke up too late. That together with 5h sleep seems to equal not being able to read and understand text properly today. Hence removed comment above. Apologies in advance to anyone ending up on my wrong side today.
Eh, to be fair, I dont know where one ends and the other starts
Im a programmer, wanting to learn more about servers. I have server experience, but nothing about email
My VPS came with postfix, so I went with that. I've now created a extra user which I (think I ) now should be able to use, yet it gives 'auth failed'. I can log into a shell so the UN/PW combo is correct
That's because of the order of redirections which, perhaps not very intuitively, are read from right to left. Taking your example:
cmd 1> >(tee f.out) 2> >(tee f.err)
This means that the first thing the shell will do is pass the standard error stream as input for the command tee f.err. The com...
@MichaelHomer thanks for your flag on meta. You might notice that it was dismissed as unhelpful but that's just because the only options we have for comment flags are "delete" (the comment) and "dismiss" (which appears as "declined" for you). Nevertheless, the flag was helpful and has been forwarded to those better positioned to deal with it. I just wanted to let you know in case you saw it was declined and wondered why.
@terdon, It was my understanding that it's right-to-left as well, but I think tee's output is getting mixed up. I'm getting intermingled output with my prompt, which makes me think (initially) that it's a timing thing.
@Kusalananda Are you sure about that? I know I can reproduce this easily and I know I have read that redirections are right-to-left, but I always have trouble finding a reference.
And the output of the second tee goes into the input of the first tee since the redirection of stdout is done before the redirection of stderr in that command.
@Kusalananda Ah! Yes, that's right. The 2> >(tee err will effectively convert stderr to stdout and since we've already redirected stdout to out, the file out gets both streams.
I know there's something or other that's read in the opposite direction to what you expect. Or what I expect, anyway. And I am pretty sure I read about it here in one of either Gilles's or Stéphane's answers, so I'm also sure it's correct. If only I could remember what it was!
@terdon the part that always sticks sideways in my head is that the redirections, being parsed in order, apply to the updated destination, which is why cmd > /dev/null 2>&1 sends stderr to /dev/null instead of stdout