« first day (1973 days earlier)      last day (3275 days later) » 

08:20
@Wildcard thanks for improvement in my answer
I've put your line at the end (with revising at some extent).
@Pandya Did you get a response re Hurd? Sorry, I was distracted when you asked about it earlier.
@FaheemMitha Yes, they recommend me to use qemu (as I want to try Debian Hurd)
Thanks for pointing out to connect IRC.
I had never used any IRC before.
08:41
@Pandya, sure, no problem. I made a couple more tweaks...hope you don't mind.... ;)
@Wildcard no problem, I've also added one more (>&)
@Pandya Sure thing. Did irccloud work Ok for you then?
@FaheemMitha Yes, but now I've set my IRC account with Pidgin IM (with freenode.net). And also thinking to use HexChat
@Pandya Oh. Interesting.
By the way, which Desktop Environment do you use @terdon?
08:54
Cinnamon
oh yes with Mint
GTK+
 
2 hours later…
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
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
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?
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!

« first day (1973 days earlier)      last day (3275 days later) »