echo commands in BASH script to STDOUT

tospo · 11-02-2010, 08:23 AM

Hi,

I'm looking for a good way of printing certain commands from a BASH script to STDOUT. This is going into a log file in the end. I don't want every command to be in there, just a few critical ones.
I know about

Code:

#!/usr/bin/bash -x

for echoing every command to the screen and also that I can do

Code:

set -x
some_command
set +x

to switch on the debugger for a single command.
The latter is what I'm using now but it produces a lot of annoying "+ set+x" lines in the output, because it will echo both, "some_command" and the next "set" command.
I would like to get rid of the redundant "+ set +x" lines.
My question: is there a better way of echoing commands to STDOUT then -x?

Thanks for your help!

druuna · 11-02-2010, 08:58 AM

Hi,

Why not add 1>$LOGFILE 2>&1 (or alike) to the critical commands instead of using set -/+x?

This will also give you the possibility to put output into different logfiles and you can split normal output (stdout) from errors (stderr).

Example:

Code:

#!/bin/bash

LOG_COMMANDS="/path/to/commands.log"
LOG_NORMAL="/path/to/logfile"

some_command 1>$LOG_NORMAL 2>$LOG_COMMANDS

other_command 1>$LOG_COMMANDS 2>&1

Also have a look at the tee command, which gives you the opportunity print output to screen and to a logfile.

Hope this helps.

tospo · 11-02-2010, 10:23 AM

thanks druuna, but that's not quite what I meant.

Redirection would only give me the STDERR and/or STDOUT of the command but I want to log the actual command itself (sorry if that was unclear).

So if my script contains the line

Code:

ls ${cwd}/thefiles_*

then I want the log to show something like

Code:

ls working_dir/thefiles_*

not the result of that command.

druuna · 11-02-2010, 10:53 AM

Hi,

Ok, clear.

Only thing that comes to mind: echo the command(s):

Code:

#!/bin/bash

echo "ls ${cwd}/thefiles_*"
ls ${cwd}/thefiles_*

I still believe you might want to have a look at the tee command (in combination with the echo command). This way you can see what is happening as the script runs _and_ have a log file to check later on.

Hope this helps.

tospo · 11-02-2010, 01:43 PM

Thanks again druuna.
Yes, that can be done and I also used to do it like that but there are two problems:
1) duplication: it is very easy to change the command but forget to change the echo statment and the log will be wrong
2) to avoid 1, you would need to put the command into a variable and then use the variable to run the command. That works but I find myself in escape-and-quote hell very quickly, especially if you have longer commands where quoting and escaping is already a challange sometimes.

I guess the set -x option is probably the best for now. It works and I guess I might have to live with all those "set +x" lines in my log file for now.

catkin · 11-02-2010, 02:15 PM

Here are Greg's thoughts on the subject. I've tried using the array technique but it gets cumbersome; implementing it in a function would be tidier. AFAIK there's no way to use command history to get what you want.

tospo · 11-03-2010, 04:27 AM

Thanks a lot catkin, that blog post was exactly what I was looking for!
OK, from that I gather that set -/+x is the best solution already and I guess I have to live with those pesky "set +x" lines in my log and maybe remove them afterwards with grep. I think that's still better than copy/pasting the command, forgetting to update the echo statement and then wondering later why that command lead to that error where it was really a different command that caused it.

catkin · 11-03-2010, 08:40 AM

Quote:

Originally Posted by tospo

Thanks a lot catkin, that blog post was exactly what I was looking for!
OK, from that I gather that set -/+x is the best solution already and I guess I have to live with those pesky "set +x" lines in my log and maybe remove them afterwards with grep. I think that's still better than copy/pasting the command, forgetting to update the echo statement and then wondering later why that command lead to that error where it was really a different command that caused it.

Greg's WIKI is a great bash resource.

I can't think of a better solution than you have described. Not pretty but the best we can do with bash (until someone finds out differently -- there's always something to learn with bash

)

colucix · 11-03-2010, 09:24 AM

Why not write a function that echoes the command before its execution? In this case if you change the command in a later revision of the script, the function will take care of recording the changes. Example:

Code:

function echo_cmd () {
  echo "$PS4$@" 1>&2
  "$@"
}

The only (not sure about this) caveat is to call the function for every command inside a piped chain, i.e.

Code:

$ echo_cmd echo string | echo_cmd cut -c 1-3
+ cut -c 1-3
+ echo string
str

which is exactly the same output as that one produced by set -x. Regarding redirection, it will be processed in the usual way and similarly to set -x the echoed command will be sent to standard error.

Edit: ok... found another caveat: command substitution is not treated as set -x, since it is performed by the invoking shell, not inside the function. Hmm... maybe this is not a good approach!

catkin · 11-03-2010, 10:12 AM

colucix's solution works for bare commands but not for command substitution (as he has already mentioned) or for I/O redirection or for pipelines. It would be difficult to write a function that did deal with these; how would it deal with the apparently innocuous echo "|" foo or echo '$( ls ) > /tmp/ls.output' ? The function would have no way, passed a series of words that make up a command, to know if they were simply strings or if they had special meaning for command execution. Any sequence of characters are possible so no "escaping" to tell the function that "this word has a special meaning for command execution" is robustly possible and, even it it were "good enough" it would be messy for the calling code.

All-in-all, stripping the "set +x"s out of the log is simpler!