-
Notifications
You must be signed in to change notification settings - Fork 0
Scope of functions
This .bashrc actually consists of not just one, but several files. On the one hand the actual .bashrc and on the other hand a few files that contain certain settings, functions, and other stuff (see below).
In principle, the contents of these files could also be written directly to the .bashrc, but it is a bit cleaner this way.
These additional files must live in the ~/.shellcfg/ directory for full functionality.
There are a few functions and aliases as well as color definitions in the corresponding files. To take full advantage, be sure to check out these files.
However, be aware that things can get messed up very quickly if something is modified in the wrong way (see section Automated Backup).
Aliases in ~/.shellcfg/alias
Way to much to mention all here. Most of them are explained in the file, but currently mostly in German. (see todo list)
Functions in ~/.shellcfg/functions
| Name | Usage | Description |
|---|---|---|
| __add_command_replace_alias | will be invoked automatically | This function checks if certain applications are installed and defines aliases in case of. This will not remove the application. But if you call it the usual way the more sophisticated version will be used, e.g. 'htop' instead of 'top'. Source: https/github.com/slomkowski/bash-full-of-colors/bash_aliases.sh |
| allcolors | allcolors | It will show you color codes that can be used when prettifying your prompt, whereby the name "allcolors" promises more than it delivers. Basically, there are 16 colors + variants that are output.[^1] Before you fiddle around with color codes just have a look at the file ~/.shellcfg/colors. There is a chance your desired color has already a human-readable equivalent. |
| command not found | will be invoked automatically | This is available in most distributions, but not necessarily installed. It should actually be called in /etc/bash.bashrc for the function to be available globally, but it doesn't hurt if it lives there either. Under Arch Linux, line 10 in this file must also be commented out (#source /usr/share/doc/pkgfile/command-not-found.bash) and should be processed before the function will be declared, otherwise the whole thing won't work in this distribution. Other non-Debian-/Ubuntu-based distributions may have similar requirements. |
| extract | extract <filename> | extracts all formats of archive files (credits: urukrama, Ubuntuforums.org) |
| ff (find file) | ff <filename> | Yep, it finds files. |
| wtfis | wtfis <arg> | Like which but exposes much more info.<arg> has to be the name of a program, function, or alias that can be found on your system, e.g. wtfis man. ❗Be patient! This function takes some time to collect all the information.❗ Source: 'https://raw.githubusercontent.com/janmoesen/tilde/master/.bash/commands' |
The idea that came up with the what_shell file was to make it accessible to other shells as well and if possible, to prevent that any user-side changes to the files are necessary for it to work - apart from renaming the .bashrc file. For now, this query (and I am talking here only about this query, read below) should work in the following environments:
- Bourne-Again Shell (bash)
- Bourne Shell (sh)
- Korn-Shell (ksh)
- and maybe Z-Shell (zsh)
- Debian-Almqist-Shell (dash)
- When using dash as an interactive shell it is recommended, to check that all scripts that don't have the
#!/bin/bashdirective in their shebang are fully POSIX compliant.
- When using dash as an interactive shell it is recommended, to check that all scripts that don't have the
- Yet Another Shell (yash), and Process Offloed Shell (posh) are also recognized
However, there is another tiny problem: Different shells have different filenames and especially different features and functions. Also, the commands may vary depending on which shell is used and whether that is also the default shell or possibly called from another shell, which can lead to different results. This may require different queries. Therefore, the file ~/.shellcfg/what_shell is currently only safe to use in in the Bourne Again Shell (bash) and Bourne Shell (sh) and should not cause any problems here, but may work within Korn-Shell as well, perhaps even within the Z-Shell. But as I said, all the shells mentioned are initially recognized. However, whether the rest will also work is not certain at the moment.
In principle, a - more or less simple - query is sufficient to find out the name of the shell. As usual in Linux, there is more than one way to achieve a goal. To check which shell is being used, the following commands can be used:
-
$SHELL- the easiest way and the most commonly used, and displays the default shell for the system (or user), which is usually (but not necessarily) the shell actually being used at any given time -
ps -cp "$$" -o command=""- shows the actual shell currently in use, but that wouldn't always work everywhere, e.g. in Tenex-C-Shell (tcsh) it will not
But the standard output for $SHELL is ugly: /bin/bash
ps -cp "$$" -o command="" isn't much better either: bash
Yes it's functional and yes it's ugly. Because of this, I wrote a few lines to change the displayed information. That's why the terminal says i.e. "Bourne Again Shell (bash) - Version version-nr" and not "bash Version version-nr".
The version query should also work in other shells (sh, bash, ksh, zsh, posh and yash). This does not apply to dash as dash has no information about its version for historical reasons.
| ❗ | I can't stress this enough: If you use these files in shells other than bash, I strongly recommend checking the contents for compatibility. |
|---|
| ❗ | There is absolutely no warranty, that these files work. They may damage your system. USE IT AT YOUR OWN RISK! |
|---|---|
| ❗ | If you want to use these files in shells other than bash, the code must be adapted for other shells. |