A good example of how function definitions in shell can be used to overlay commands (applications).
The man() shell function in the example, although slick, is terribly inefficient because every time the man(1) command is called, the function will execute multiple printf(1) applications, over and over and over again. If you've ever ran application startup and shutdown at the assembler level in a debugger, it became obvious pretty quickly than running an application involved many, often recursive libc and system function calls, just to be able to set up the environment in order to start and exit the application.
Here, then, is the fix; this runs only once at shell startup, and stores the resulting escape codes in variables; put this in your ~/.profile (not .kshrc, nor .bashrc, nor .bash_profile, but ~/.profile!):
this code is portable and should work on every Bourne-family shell from the original '70's Bourne shell all the way to ksh93 and bash without modification; if it does not, it is a bug in the shell interpreter. Bug your operating system vendor to fix the interpreter program.
it should be noted that this assumes that the terminal (or the terminal emulator) one is using is actually capable of correctly interpreting the escape command sequences, and in addition correctly displaying them. Not all terminal emulators nor all physical terminals are capable of displaying all, some or any of these display modes. The above also assumes that the shell implements \e, which not all shells do (C-shells notably do not).
Finally, a quick crash course on manual pages, manual pages versus info, and why manual pages are orders of magnitude better, and still a standard, because that is bound to come up sooner or later:
The man() shell function in the example, although slick, is terribly inefficient because every time the man(1) command is called, the function will execute multiple printf(1) applications, over and over and over again. If you've ever ran application startup and shutdown at the assembler level in a debugger, it became obvious pretty quickly than running an application involved many, often recursive libc and system function calls, just to be able to set up the environment in order to start and exit the application.
Here, then, is the fix; this runs only once at shell startup, and stores the resulting escape codes in variables; put this in your ~/.profile (not .kshrc, nor .bashrc, nor .bash_profile, but ~/.profile!):
this code is portable and should work on every Bourne-family shell from the original '70's Bourne shell all the way to ksh93 and bash without modification; if it does not, it is a bug in the shell interpreter. Bug your operating system vendor to fix the interpreter program.it should be noted that this assumes that the terminal (or the terminal emulator) one is using is actually capable of correctly interpreting the escape command sequences, and in addition correctly displaying them. Not all terminal emulators nor all physical terminals are capable of displaying all, some or any of these display modes. The above also assumes that the shell implements \e, which not all shells do (C-shells notably do not).
Finally, a quick crash course on manual pages, manual pages versus info, and why manual pages are orders of magnitude better, and still a standard, because that is bound to come up sooner or later:
https://news.ycombinator.com/item?id=11927525