| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|
|
|
| |
Trying again
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<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
|
| |
|
| |
|
|
|
|
| |
less(1) gets upset if it's not a regular file, because reasons.
|
|
|
|
|
|
| |
I made the incorrect assumption that it was safe not to do this;
expansions that include glob characters, for example, can cause
problems.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
No manual page yet
|
| |
|
| |
|
|
|
|
| |
No manual page yet
|
|
|
|
| |
Very ugly, and no manual pages yet.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
I'm having a lot of fun with this.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out GNU sed doesn't support POSIX word boundaries
[[:<:]],[[:>:]]. This leaves me with no compatible way to denote a word
boundary. I shouldn't really be surprised.
I've worked around this by padding the start and end of each line with a
tilde, and then removing it again at the end of the script, which is
not great but will have to do. It's preferable to having two-three
versions of each of the word-boundary rules to support ^ and $
anchoring.
This is probably the weirdest way anyone has ever learned sed.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Not worth the extra dependency just for slightly nicer command presence
checking
|
|
|
|
|
|
| |
Because Amazon tells me to go away when I use the default user agent. I
don't really feel sorry for it, because it throws a misleading 503 error
too.
|
| |
|
| |
|
|
|
|
| |
Include it in the sendemail section of the Git config, too
|
| |
|
| |
|
|
|
|
|
|
|
| |
Doing this in preference to relying on GIT_* environment variables.
I don't like the default values in the Makefile very much; I'll need to
figure out something nicer at some point.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
I'm using this script on a machine that doesn't have a C.UTF-8 locale.
|
| |
|
| |
|