14

With the bash shell, you can install a trap on the synthetic DEBUG signal. This is useful and will execute your function or bit of code on every shell command. For example:

$ trap 'logger -t shell "${BASH_COMMAND}"' DEBUG

The idea here is to install the trap in a file dropped in, for instance, /etc/profile.d/bash-logger and have any user shell session commands logged automatically to syslog whenever they happen. This is also useful to easily trace remote commands.

Looking at the dash shell source code, I seem to understand there's no such DEBUG signal available.

Are there any workarounds or alternatives to achieve the same result with the dash shell?

7
  • 1
    What about while read -r line; do logger -t shell "$line"; command "$line"; done < myscript.sh ? If it works I may add some line more in an answer.
    – Hastur
    Commented Apr 7, 2017 at 16:11
  • @Hastur I think you mean eval "$line"
    – Zombo
    Commented Apr 9, 2017 at 3:02
  • 1
    @StevenPenny Yes, I was writing eval <command> and I cancel the wrong part, it happens... of course always if you do not want to force your script to use commands on disk instead of the alias/function ones...◉‿◉
    – Hastur
    Commented Apr 10, 2017 at 14:16
  • Sorry but that's not helping very much. The idea here is to install the trap in a file dropped in, for instance, /etc/profile.d/bash-logger and have any user shell session commands logged automatically to syslog.
    – Cosimo
    Commented Apr 11, 2017 at 14:49
  • 2
    This is not really the right site for this question. I wont be adding any more bounties if this one does not work. You should consider deleting this and reposting on unix.stackexchange.com
    – Zombo
    Commented Apr 17, 2017 at 19:28

1 Answer 1

0

The most thorough approach would be to re-compile the shell with syslog support enabled. That also gets around shells that (for whatever reason) don't load ~/.whatever-profile or ~/.whatever-rc.

This is included as an option in the standard source for Bash, but for other shells you might need to find or write a patch.

I would hesitate to recommend reading and evaling line-by-line, because commands can span multiple lines and eval of half a command will either fail, or do the wrong thing. Affected command types include: pipelines and conditional commands (where each line ends with &&, || or |), compound commands (including bracketed groups), lines continued with backslashes, multi-line quoted strings, and << here-docs. (There are probably more than I haven't thought of.)

For limited cases you may find set -v or set -x useful, combined with redirecting stderr into a pipe to logger. However it's imperfect as also redirects stderr from the programs you run. (In Bash you can choose a different filedescriptor for set -x to write to, which solves that problem.)

I would point out that if you go ssh host some_command then there's no interactive or login shell involved, so your rc files don't get loaded, which would bypass your logging.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .