cleaning up output from mysql command in shell script


If i had a shell script which ran a mysql command like so

/usr/bin/mysql -u user -ppassword database_name < /path/file.sql

and the sql file contained an update command, what would happen to the 'number of rows affected' output? Where would it go?

I've seen it cleaned up like this before

> /dev/null

What would happen if dev/null was full?

What would happen if the job running the script did not have permission to access /dev/null? Is this possible?

Who is Participating?
woolmilkporcConnect With a Mentor Commented:
When running a job in the background without output redirection you're at risk to get a ENOTTY error, or at least to see (with longer running jobs) out-of-the-blue text messages arriving at your terminal now and then, so it's good practice to redirect the output, be it stdout or stderr, to a logfile or to the said "special" file /dev/null.
It's not at all mandatory to use /dev/null for background jobs, regular log files will do as well.

A particular case is "nohup". When a process is started in the background prepended with "nohup" and the output is not redirected then "nohup" will capture it on its own and redirect it to a file named "nohup.out".
"nohup" is meant to let your job survive even when its parent shell dies.
The output goes to the "stdout" stream which is by default associated with your terminal.

/dev/null (the null device) is a special file which cannot get full. Everything redirected to it is immediately discarded.

/dev/null is world-writeable.
andiejeAuthor Commented:
what if it was running in the background? is that why it is sent to /dev/null
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.