my big bad "#%&"!

[Basher52]

I checked the rc.local again(for the 711th time) and now i saw that i missed the parm that tells the teamspeak to start...lol
i need no log since the only output that comes is one row telling that the process has started as process #xxxx
(the line AFTER the teamspeak-line is run since the 'screen' daemon starts, so that gotta mean the rc.local keeps running and dont hang)

Another thing...the first '>' character u wrote in ur example, this one i know is for putting the output into a file, but the next things:
'2>&1 &' i dont know

i think i know that the last '&' means to start the daemon as backgrouns process, right? but what about the '2>&1'

B52

[Void Main]

Another thing...the first '>' character u wrote in ur example, this one i know is for putting the output into a file, but the next things:
'2>&1 &' i dont know :(

i think i know that the last '&' means to start the daemon as backgrouns process, right? but what about the '2>&1'

'>' redirects STDOUT
"2>' redirects STDERR
'2>&1' redirects STDERR to STDOUT
'&' starts a process in the background and returns control to the command line

Did you ever run a command and try and pipe it into the "more" (or less) command annoyingly only to find out that "more" seemed to have no effect (page the output)? An example might be to type this:

Code: Select all

xset


Since you didn't give xset a parameter it just spit out a help screen. Well, the help screen probably scrolled off of your screen so normally one would pipe it into "more" so you can read what scrolled by one page at a time like so:

Code: Select all

xset | more


Hmmm, "more" didn't seem to work huh? That's because the "xset" command printed it's help page out to the STDERR channel and not STDOUT like most programs do it and more is only readong STDIN. So what you can do is redirect the STDERR channel to STDOUT and then pipe it to more like so:

Code: Select all

xset 2>&1 | more


Now more can page it.

Having two channels like this is very useful because you can send messages (maybe error messages) out the STDERR channel and send normal messages out the STDOUT channel and have them go to two different places. Maybe you want to redirect STDOUT to a file but have any error messages go to your screen:

Code: Select all

somecommand > somefile.log


Or maybe you want normal output to go to one file and errors go to another file:

Code: Select all

somecommand > somefile.log 2> somefile.err


Or maybe you just want both normal messages and error messages to go to the same file:

Code: Select all

somecommand > somefile.log 2>&1


which is usually what I do when starting commands in the background. If you do not redirect the output when you background a command the command can hang up if it does have to send a message as it no longer has a place to go (if you background it and log off that is). Most good programmers (and some not so good, like me) make good use of both STDOUT and STDERR.

[Basher52]

very informative...thx Void
gotta save this at a safe place...thx

[Void Main]

It's all in the bash man page under the section titled "REDIRECTION". In fact I just realized there is an easier way to redirect both STDOUT and STDERR to the same file. Instead of:

Code: Select all

$ somecommand > /somedir/somecmd.log 2>&1


you could just:

Code: Select all

$ somecommand &> /somedir/somecmd.log


which appears to be equivalent according to the man page.

[Basher52]

k..thnx

so i think i better sit down and start reading the man page on bash.

B52

[Void Main]

Well, there's a lot in the man page. Basic redirection, pipes, and job control are good to know though. There's a lot to know about bash. A good place to go to pick up on a lot of the basics, in probably a much more fun way would be to browse around this site:

http://www.linuxrefresher.com/

or if you want more in depth, here are 500 online pages on programming in bash:

http://tldp.org/LDP/abs/html/

the redirection section:

http://tldp.org/LDP/abs/html/io-redirection.html