Here's a conceptual approach that might work.
alias command generates a list of all aliases, each followed by an
= and it's definition. This output could be parsed by extracting the alias name from between the first blank and the first
=. Everything after the first
= would be the definition to be matched against. This sounds like something easily handled using associative arrays in awk.
Two complications to this (that I see):
1) Since the definition can consist of multiple words, you'd have to do something like measuring the length of the definition minus any enclosing quotes and limit your compare against the entered command to that length.
2) Aliases can hold some weird stuff. Here's my weirdest one (and I'm sure they can get a lot weirder):
alias pqp='cd ~/pq;[ -n "$(ls)" ] && mprb * || echo "Print Queue Empty"'
The point here is that aliases can contain (almost?) all the special characters the shell wants to interpret and expand, so it would be best to code this in something else like awk or Python where the two strings you need to compare will be treated as simple character strings.
The next issue is that you want to actually run the command after you're done matching and issuing any messages.
The concern here would be that anything you run from within your program, even if it's just another script, will (normally) be executed in a child process. This means that any (shell-level) side effects of the command will be lost when the command terminates and the subshell closes. The most obvious thing is the return code,
$?, which you would have to capture and reissue as the return code of your utility.
If the alias included an invocation using the
. command, then you'd be pretty much out of luck because running that in a subshell would completely cancel the intended side effects.
Shells contain a number of built-in commands like
cd. Some of these have equivalent programs as does
/usr/bin/test, but some, like
cd don't and, even for those which do, the built-in versions don't always have the identical behavior and options that the external ones do.
The above problems exist because the final command is coming from somewhere other than the standard input of the current shell level and is processed differently because of that. This is where something like AutoKey may be able to help.
AutoKey is a macro processor which can be used to automate various actions in an X (gui) environment. In this context, it could be used to invoke a macro when you press a user defined hotkey. The macro could read and analyse a command line you would type into it, issue any messages (about aliases, etc.), and then retype the command as if you typed it on your keyboard.
The advantage here is that Linux (really your desktop environment/terminal emulator) can't tell it's not you typing the command and everything proceeds in your original, native environment as if AutoKey wasn't there at all.
A second advantage of this approach is that if you just enter a command without first pressing the hotkey, it's business as usual with no overhead, etc.
This bring me to a final point which has been discussed at length in various places on stackexchange and elsewhere.
It's almost always a bad idea to take a normal part of any system and change how it works by default under the hood without that being totally visible to the user (you, in this case).
In brief, if you customize a system to behave in a non-standard way, there are two major consequences.
1) If someone else uses the system (e.g. to help you debug a problem), they will encounter unexpected results which could have any number of unpleasant consequences.
2) You become accustomed to the modified behavior and then (unconsciously) expect it to work when you are using another system which has not been customized in the same way.
The classic example of this is defining an alias such as
alias rm='rm -i'
This sounds like a great idea until you type
rm on another system and the files are immediately deleted when you were expecting to be prompted first.
The way around this is something like:
alias rmi='rm -i'
If you type it, it works, but if you type it on another system, it probably won't do anything other than issue a command not found error.
This is particularly important in the middle of the night when something important is broken, you're not as alert as you'd like to be, and you're under pressure to fix it now. That's when you really don't want any unexpected behaviors or things you have to waste time explaining to people.
It works the same way with doing alias checking with an AutoKey macro activated by a hotkey. If you don't go out of your way to activate the macro by pressing a hotkey, then everything works as anyone would expect it to. A properly chosen hotkey probably won't be pressed by accident and, if pressed on another system by habit, probably won't do anything harmful.