UNIX for Beginners Questions & Answers

Well most common use of redirection is more redirecting STDERR to STDOUT:

Code:

 ls -al  . >ls.out 2>&1

I tend to keep both separate specially when using cron, as if in a rush, if you redirect all to error.log you are to read the whole file just to look for a possible issue but if you keep them separate:

Code:

my_cron_job >>my_cron_job.log 2>my_cron_job.err

Now my expectations is to see my_cron_job.err file size = 0 meaning all is well... and no point to look at my_cron_job.log if I am busy as all I will find there are the results of the job that executed correctly as the .err is empty...

I use another form in a way too:-

Code:

echo "This is my debug message" >&2

This way, I can write my own messages to the standard error file (or indeed any other file descriptor I choose to define) which are easier to ignore if called as a function or from another script, e.g.:-

Code:

#!/bin/bash

# Call so_and_so ignoring my errors
so_and_so 3>/dev/null

# Call so_and_so collecting std output & my debug as a variable
my_var=$(so_and_so 3>&1)

These tricks can be useful to put loads of debug info into scripts then ignore them when you are happy without removing them. Of course, you can then see all the useful information you have previously set up quite easily too.




Just my thoughts,
Robin

Isn't >&2 the same as 1>&2 , both of which say "Send <stdout> to where <stderr> is pointed towards (the terminal)?
Or, stated another way, "Send 1 to where 2 is going, which by default goes where 1 goes". If so, I can't understand the point of >&2.

It does not. You need to differentiate between "by default" and "by habit" here. With your interactive sessions, you have both pointing to your terminal by habit. But running a command or script may change that immediately - they may have a different opinion of what their errors should go to. And even more so for system programs, e.g. daemons, which will off the shelf log to log files and print errors to their stderr. And this is what rbatte1 shows: a simple "error log" command for use inside (standalone?) scripts, assuming stdout and stderr have been split when / before calling / running,



echo prints to stdout, so you need to redirect stdout to the stderr file descriptor for the "error log command".




EDIT: LOL - trying to prove my point, I thought I take Xorgas an example, but it has both redirected to /var/log/.../x-0.log Still, many dbus programs have fd 1 pointing to /dev/null and fd 2 to ~/.xsession-errors

Yes, by default stdout and stderr go to the terminal but in different streams.
Each of them can be redirected to an individual target, then they are separatate.
Say you run a script with redirecting stderr to errorfile

Code:

/path/to/script 2> errorfile

Then in the script

Code:

echo "This is my debug message" >&2

goes to errorfile.

You can do all that in the script:

Code:

exec 2>errorfile
echo "error 1" >&2
echo "error 2" >&2

Note that only the "exec" opens the file.
Then each >&2 write goes to the stream, i.e. appends to the file.
Or you can redirect a code block:

Code:

{
echo "error 1" >&2
echo "error 2" >&2
} 2>errorfile
# The code block has ended. The follwoing goes to the original stderr again.
echo "error 3" >&2

Further you can nest code blocks

Code:

{
{
echo "error 1"
echo "error 2"
} >&2
echo "not an error"
echo "error 3" >&2
} 2>errorfile

Last but not least, a if-then-fi or while-do-done or for-do-done or case-in-esac are code blocks.
This often makes sense with a while-do-done loop.

Code:

while read line <&5
do
  echo "$line"
done 5<inputfile

You do not need an explicit block around the while-do-done loop

Code:

{
} 5<inputfile