| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Check capabilities of wrapped programs at runtime, not declaration time.
Also do away with the silly GREP_COLORS and GREP_OPTS variables.
Considering doing the same with LS_COLORS.
|
|
|
|
|
|
|
|
|
| |
It's stupid to run `grep --help` once per shell (twice for login
shells!) when it's so unlikely to change, and way faster to check for
the presence or absence of hint files rather than pattern-match the
output with the shell.
ls(1) will get the same treatment in a minute.
|
| |
|
|
|
|
|
| |
Does away with the nasty hack around man page discovery, and still
compatible with Bash 2.05a
|
|
|
|
|
| |
GREP_OPTIONS doesn't work if it's not exported, which ought to have been
painfully obvious. Oh well.
|
| |
|
| |
|
|
|
|
|
| |
Shouldn't be exported because it changes the behaviour of grep(1), which
might have unwanted side effects in scripts
|
| |
|
|
|
|
| |
Explicit -n, ! within [[
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Initialisation with an array literal doesn't work in 2.05a
|
|
|
|
|
|
| |
Don't declare integers/arrays, just use them. Also includes a minor
scope fix -- don't need to count number of colors on every call to
prompt(), just for `prompt on`.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Use tput properly and only when found and necessary
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mostly for clarity reasons; using this syntax:
if [ condition ]; then
commands
fi
As opposed to:
if [ condition ]
then
commands
fi
Or:
[ condition ] && command
|
| |
|
|
|
|
| |
Avoiding the use of echo, using builtins whereever possible
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<tyrmored> is this syntax actually problematic?
<tyrmored> function whatever {
<tyrmored> thangs
<tyrmored> }
<zendeavor> !pf function
<greybot> http://mywiki.wooledge.org/BashPitfalls#pf25 -- Don't do this! --
function foo()
<tyrmored> i know it's bashism, but is it bad practice
<tyrmored> yeah i know that much
<tyrmored> (no parens, that is)
<zendeavor> it's not necessarily a bashism, but the function keyword has
implications in other shells
<zendeavor> and, perhaps someday in the future, for bash as well
<tyrmored> hmm, so i should use this syntax even if the scripts are explicitly
bash?
<ffio> hi zendeavor :)
<zendeavor> you should use foo() { echo bar; }
<tyrmored> rightoh
<zendeavor> no surprising behaviour that way, ever
<tyrmored> makes sense
<zendeavor> it won't matter *much* but element of least surprise
|
|
|
|
| |
These are no longer needed after the alias has been established.
|
|
|
|
| |
I was only doing this to work around a Bash syntax highlighting bug
|
| |
|
|
* No longer using .bash_logout
* No longer using .bash_profile, using POSIX-compliant .profile
* instead; in particular, moved most of environment settings into
.profile
* Moved some of the separable functionality of both .profile and
.bashrc into subdirectories (some scripts shared, some not)
* Tidied implementation of ls/grep aliases
* Updated install script to reflect all of the above
|