I write a lot of non-interactive scripts where I would like all output to go to a log file and have nothing appear on-screen.To solve this, I've been using:#!/bin/bashexec &> logfileecho Step One:/some/command/oneecho Step Two:/some/command/twoI want to make sure this is a sane method.  Are there any significant drawbacks or issues I'm going to encounter if I move forward with this methodology?  If so, what are they and how best can they be mitigated (including by changing my methodology).
exec redirects in bash
bash;shell script;output
As Janis mentioned, redirecting command output to a log file is standardpractice. Many of my shell scripts begin with:exec 1>>logfileexec 2>&1Note the use of >> to append to the log file. Also, the redirection works with any POSIX compatible shell.Redirection while running an interactive shellIn my experience, the only downside to using exec to redirect standardoutput and standard error is that you can lose your shell session:You can easily redirect standard output to a file while in aninteractive shell.  After running exec 1>outfile, all future commands printtheir output to outfile instead of to the terminal.After running exec 2>errorfile, the standard error produced by any furthercommands is written to the redirected error file  as expected. However, the problem is that from now on, the shell (Bash in this case) prints its prompt to this file andany text typed as a command is also redirected to this file.  For the rest ofthe shell session, youre essentially working blind as nothing at all issent to the terminal which obviously makes it very difficult to continueinteracting with the shell.As Orion points out, you can store a reference to the default stdout andstderr file descriptors before trying any such experiments using exec 3>&1 andexec 4>&2, respectively. When youve finished your experiments, you canrestore printing to standard error by running exec 2>&4 and restoreprinting to standard output with exec 1>&3.