| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
With an attempt at correct trapping; may still require tweaking
|
| |
|
| |
|
|
|
|
|
|
| |
Reading really large files seems to be slow in Bash in general, but it's
particularly bad in 4.4rc1. I keep encrypted snapshots of my HISTFILE on
my home machine, so it's just a little extra step to search them.
|
| |
|
|
|
|
|
| |
Bash doesn't require it, but there's no real advantage to it and it's a
better habit for complying with e.g. pdksh, which does
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
I don't fully understand why I have to do it this way yet, but if I
don't, calling SSH with a command raises "stdin: not a terminal" because
~/.bashrc was called.
|
| |
|
|
|
|
|
|
|
| |
Have only translated the scripts that translate readily into POSIX sh
for now. More complex stuff like that bd/pd/sd/ud navigation for Bash
doesn't port as easily, mostly because there isn't an analogue for the
"local" keyword in POSIX.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
All of my personal stuff is in Git, so this is only really applicable at
work
|
|
|
|
| |
Just noise
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Checking the output of `git status -z` works, but to be correctly
handled requires using a null delimiter for read. Because I want to port
this to OpenBSD pdksh (which doesn't have the -d option for read), this
seems to be a workable alternative.
It also enables me to remove the process substitution (another thing
pdksh doesn't support), and the array of flags.
I haven't yet tested this for speed.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Since Vim and Fanboy's list both moved to Git, I have no reason to use
it anymore. Also added a note explaining why I've left the SVN stuff in
there (I don't like SVN, but I do need to use it for work)
|
| |
|
| |
|
|
|
|
|
| |
clrd(1) is POSIX sh, but clwr(1) ideally needs Readline, so I've left it
as #!/bin/bash for now.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Add comments, add short-circuit to vared() completion
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Not really justified
|
|
|
|
| |
OpenBSD doesn't have -n
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<http://mywiki.wooledge.org/BashFAQ/100#Default_or_alternate_values>
>Nobody ever uses ${var?word} or ${var:?word}. Please pretend they don't
>exist, just like you pretend set -e and set -u don't exist.
><tejr> from FAQ 100: >Nobody ever uses ${var?word} or ${var:?word}.
><tejr> why is that? just because it's unwieldy, or are there other
>technical reasons?
><ormaaj> tejr: Putting random fatal unhandlable errors into a script is
>generally useless.
><tejr> ormaaj: is it less handleable than a more explicit check, like
>`[[ $var ]] || exit 1` ?
><ormaaj> yes
><ormaaj> # : ; ${_[RANDOM%2]?:you win}
><shbot> ormaaj: no output
><ormaaj> didn't win
><tejr> i was thinking more as a terse means of perhaps asserting a
>variable had a value, like a positional parameter; are you saying if
>you really did just want to write to stderr and exit with failure, it's
>still inappropriate?
><ormaaj> depends on the complexity I suppose but I'd not consider that
>unless it's the global scope in a file you know isn't going to be
>sourced and has no other explicit error handling. Even then it's ugly
>because it bails out in the middle of evaluating parameters that
>technically could have side-effects and such.
><tejr> ahh yes, kinda a separation of concerns
><tejr> that makes more sense now! thank you
> * tejr combs his scripts to see if he's used it anywhere
><ormaaj> tejr: another reason is the type of error is a bash error
>which usually indicates a problem with the script where bash itself
>can't continue. An unset var isn't a " bash error", You can even make
>it print counterintuitive error messages that look like bash internal
>errors.
><tejr> ormaaj: also compelling
><tejr> i've found a few "{@:?}"s in here so i'm fixing them up now
><tejr> thanks for the analysis
|
|
|
|
|
|
| |
I made the incorrect assumption that it was safe not to do this;
expansions that include glob characters, for example, can cause
problems.
|
| |
|
|
|
|
|
|
| |
Allows for terser functions and avoids error-prone local variables; also
nicer to have a single `command` call at the end of the function
(although there are still two at the end of the ed(1) wrapper)
|