Conversation started Mar 4, 2016 at 10:47.
Mar 4, 2016 10:47
@Wildcard while searching on web, found &> to redirect stdout and stderr. And as we know &> seems also works same, I am planning to post a question for it on U&L
what do you think?
48
A: What are the shell's control and redirection operators?

terdonThese are called shell operators and yes, there are more of them. I will give a brief overview of the most common among the two major classes, control operators and redirection operators, and how they work with respect to the bash shell. A. Control operators These are tokens that perform contr...

I think @terdon knows well
@terdon what is the difference between &> and >&?
How about such question on U&L (Should I post?)
10
Q: Why does 'nohup command >& /dev/null' seem to "work" in some shells?

terdonI edited an answer on Ask Ubuntu that was suggesting the following nohup gedit >& /dev/null & When they actually meant nohup gedit &> /dev/null & The latter correctly redirects both stderr and stdout to /dev/null. I was expecting the former to either create a file called & or, more likel...

>& isn't a thing.
> bash initially did no understand >&, but it introduced the &> operator for that, breaking POSIX compatibility in the process
> bash added support for >& in 2.05.
Is &> just starting process in background and then redirecting output? @terdon
Mar 4, 2016 11:03
Yes. command &> foo is the same as
command &
> foo
>& is csh for &>, apparently.
But I didn't understand how &> writes stderr and stdout to a file
&> file is the equivalent of > file 2>&1
I don't understand starting process in background and then write output by &>
Example:
I've make file
$ cat execute
cat rr&
>foo
and if I run it by ./execute, then I get nothing in foo
Whereas with cat rr &> foo, I get: cat: rr: No such file or directory written in foo
$ cat execute
cat rr &
> foo
So why ^^^ isn't working @terdon ?
@Pandya Yes, but it creates foo. That will first run cat rr in the background and then, as an independent command, run > foo which creates foo if it doesn't exist and truncates it if it does.
@Pandya Yes, because that is running cat rr and redirecting both standard error and standard output to the file foo.
Then How command &> foo is the same as
command &
> foo
Mar 4, 2016 11:19
@Pandya It isn't. I said that command >& foo is the same as command & and > foo,
Oh. No, I didn't. Sorry.
That's what I meant.
Argh, I've confused you more. OK, let's try again.
2
ok
Let's we've two executables:
1.
In bash, &>foo redirects standard error and standard output to a file called foo and >&foo redirects standard output to a file descriptor named foo.
$ cat exe1
cat xyz &> foo
2.
$ cat exe2
cat xyz &
> foo
now ./exe1 is not working same as ./exe2
No.
exe1 will redirect both standard error and standard output of the command cat xyz into the file foo. The command will be run in the foreground.
exe2 will run the command in the background and won't redirect anything anywhere. After launching the command, it runs a completely separate command: > foo which will truncate the file foo and create it if it doesn't exist.
ok then what first part of answer says about they (syntax) are same?
Mar 4, 2016 11:35
@Pandya It's talking about comm &> file being the same as comm & and > file in POSIX shells.
but not in my case right?
oh! that's why:
> bash initially did no understand >&, but it introduced the &> operator for that, breaking POSIX compatibility in the process
right?
Yes. Bash uses &> to redirect both stderr and stdout.
>& isn't a thing by itself, it needs &>FileDescriptor. That's why >&2 works, it redirects output to the file descriptor "2", which is standard error.
OK. Now I understand
@terdon thanks for exchanging stack with me on stack exchange!
 
Conversation ended Mar 4, 2016 at 11:42.