Does bash have a hook that is run before executing a command

bashcommand linehook

In bash, can I arrange for a function to be executed just before running a command?

There is $PROMPT_COMMAND, which is executed before showing a prompt, i.e., just after running a command.

Bash's $PROMPT_COMMAND is analogous to zsh's precmd function; so what I'm looking for is a bash equivalent to zsh's preexec.

Example applications: set your terminal title to the command being executed; automatically add time before every command.

Best Answer

Not natively, but it can be hacked up using the DEBUG trap. This code sets up preexec and precmd functions similar to zsh. The command line is passed as a single argument to preexec.

Here is a simplified version of the code to set up a precmd function that is executed before running each command.

preexec () { :; }
preexec_invoke_exec () {
    [ -n "$COMP_LINE" ] && return  # do nothing if completing
    [ "$BASH_COMMAND" = "$PROMPT_COMMAND" ] && return # don't cause a preexec for $PROMPT_COMMAND
    local this_command=`HISTTIMEFORMAT= history 1 | sed -e "s/^[ ]*[0-9]*[ ]*//"`;
    preexec "$this_command"
}
trap 'preexec_invoke_exec' DEBUG

This trick is due to Glyph Lefkowitz; thanks to bcat for locating the original author.

Edit. An updated version of Glyph's hack can be found here: https://github.com/rcaloras/bash-preexec

Simple test:

You can test this quite easily by opening one elevated and one non-elevated command prompt. Run the command notepad.exe in both, and try saving a blank text file to C:\Windows. One will save, one will throw a permissions error.

Thorough test:

If that's not enough to confirm it for you (it didn't really satisfy me) you can use AccessChk from SysInternals. You'll need to run this from an elevated command prompt.

Lets start by checking out the two Notepad processes that are running:

Notepad: (`accesschk.exe -v -p notepad`)

[11140] notepad.exe
  Medium Mandatory Level [No-Write-Up, No-Read-Up]
  RW DOMAIN\Tannerf
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[11004] notepad.exe
  High Mandatory Level [No-Write-Up, No-Read-Up]
  RW BUILTIN\Administrators
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS

One is running under my domain username, the other is running under the Administrators built-in group. It also has a high mandatory level. You can also run with the -f flag for a breakdown of the privileges and tokens.

MSIExec and MSI files

I thought things might get a little more complicated when running msiexec. I have a Google Chrome standalone installer that was handy to test.

msiexec.exe launching Chrome installer from elevated prompt:

D:\Users\tannerf>accesschk.exe -p msiexec.exe

[10540] msiexec.exe
  RW BUILTIN\Administrators
  RW NT AUTHORITY\SYSTEM

chrome_installer.exe spawned by MSI:

D:\Users\tannerf>accesschk.exe -p chrome_installer.exe

[5552] chrome_installer.exe
     NT AUTHORITY\SYSTEM
     OWNER RIGHTS
  RW NT SERVICE\msiserver

Not so cut and dry anymore! Looks like a chrome_installer.exe processes was run through the MSIServer service.

This makes me wonder what behavior other installers might have, so I ran an Evernote.msi I had handy:

Elevated msiexec.exe launching an Evernote installer:

[6916] msiexec.exe
  High Mandatory Level [No-Write-Up, No-Read-Up]
  RW BUILTIN\Administrators
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[4652] msiexec.exe
  System Mandatory Level [No-Write-Up, No-Read-Up]
  R  BUILTIN\Administrators
        PROCESS_QUERY_INFORMATION
        PROCESS_QUERY_LIMITED_INFORMATION

Interesting; there's an msiexec.exe that's run under system level this time. I used Process Monitor to find that the actual install window that pops up comes from the system level msiexec process. Killing the high mandatory level also killed the system level process.

Non-elevated msiexec.exe launching an Evernote installer:

[7472] msiexec.exe
  Medium Mandatory Level [No-Write-Up, No-Read-Up]
  RW DOMAIN\Tannerf
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[4404] msiexec.exe
  System Mandatory Level [No-Write-Up, No-Read-Up]
  R  BUILTIN\Administrators
        PROCESS_QUERY_INFORMATION
        PROCESS_QUERY_LIMITED_INFORMATION

Looks like Evernote will get system level access either way. Double-clicking the installer has the same result.

Conclusion:

I think it's pretty well demonstrated that a processes will inherit permissions unless otherwise specified. That doesn't guarantee msiexec SomeProgram.msi will run with a high mandatory level across all processes processes; it could run under system level or under MSIServer. Your mileage may vary, and I wouldn't be surprised to see many instances where these rules seem to be "broken".

Bash Command-Line – Command to Print New Prompt String and Redraw Current Line

Use redraw-current-line function of bind builtin. First check if it's already bound maybe:

bind -q redraw-current-line

I've never seen it bound by default, so you will probably need to bind it. Pick a key combination, let's say Ctrl+Y. Check if it's already taken:

bind -p | grep -F '"\C-y'

Empty output means the combination is unused. If so, let's bind redraw-current-line to it:

bind "\C-y":redraw-current-line

Now, whenever a background process messes with your command line, hit Ctrl+Y. Then your prompt will be redrawn along with whatever command you have just partially typed (if any), so you can continue as if nothing happened.

To make the binding permanent you could add the above command to your ~/.bashrc, but don't. The right approach is to modify ~/.inputrc (for user) or /etc/inputrc (system-wide). This way any program that uses readline(3) library will obey. The line to add to either file looks like this:

"\C-y":redraw-current-line

But if you create ~/.inputrc anew, make sure its first line says $include /etc/inputrc. This is because up to this point readline has used /etc/inputrc and maybe your workflow relies on what's in this file. From now on, the library will use your ~/.inputrc instead; the line $include /etc/inputrc makes it parse the system-wide file as well.

For more info see help bind and man 3 readline.