Maybe I missed it, is there no love for the piping to an external command?
I set a mark, move to somewhere else, then save the area between where I am and the mark: ma(assign mark "a" to position), jjj(move three lines away), |a(pipe from current-position to the "a" mark then a ! prompt appears so enter...) cat >somefile (which dumps the selected text, cur-pos to mark "a", into somefile).
That was great for saving snippets of news or emails.
Also, the -j setting. Sets the line position for searches so context is available, eg using -j8 means the search is 8 lines from the top of the screen.
I use the piping feature of less to add some interactivity to git-log.
When a commit is "selected" (at the top line of the screen), usually after a series of n/N, I can press a shortcut that invokes an action on this commit.
Currently, I use it for two things:
1. Running git-show on a commit I'm interested in. The cool thing is that once I quit the git-show's less, I'm back to where I was in git-log's less. They stack.
2. fixup-ing a commit, after verifying with the command from 1. that it really is the one I want. I've had enough problems with git-absorb and git-fixup that I prefer to do it myself.
I detect when a particular command is running[1] and set up keyboard shortcuts that send key sequences to less and ultimately lead to the top line of the screen being piped to a short script of mine that extracts the commit hash and does something with it.
[1]: via a debug trap in bash, which sets the terminal title, which, in turn, is detected by keyd-application-mapper; other setups are possible, I used to use tmux for that.
I've been led to believe those video thumbprints exist, but I know the hash of the perceived audio is often all that is needed for a match of what is currently being presented (movie, commercial advert, music-as-music-not-background, ...).
This is why a lot of series uploaded to YouTube will be sped up, slowed down, or have their audio’s pitch changed; if the uploader doesn’t do this, it gets recognized by YouTube as infringing content.
Cash-only here. I have not (generally) accepted pennies since the mid 1980's.
Many of the local places (Seattle - Belltown & the Market) are cool with rounding transactions to the nearest dollar, so that helps. It might also be part of being an active participant in the local society.
I've read, from a few separate sources that were not research papers, something similar that claimed the development was a result of existing in semi-aquatic environments such as home on land but swimming for food/safety. I neither agree or disagree (not my field, I don't possess appropriate background/information), but I do think of it when evolution of vocal cords is mentioned.
I don't recall the sources ATM, possibly something out of CoEvolution Quarterly or Bucky Fuller. Again, not research papers.
Semi-aquatic environments make sense if you look at our brains dependency on DHA (seafood is a rich source) and the hypothesis that our fingers get wrinkly in water after a while to improve grip.
Aren't we a lot more evolved for hunting animals on foot? The whole thing with us losing our fur and sweating with the whole body, adaptations to running and throwing stuff, all of this makes us better hunters, but not necessarilly fushermen.
The two go together. Living with water requires control of breathing. Hunting animals on land requires strong endurance and probably also an ability to carry water.
Nicely put (oof!). I believe it also enforced a minimal color depth, which none of our machines could directly support on their own hardware, forcing the use of remote X11 displays.
It's time for me to re-read the man page for bash. I was not aware of BASH_REMATCH, wow. It's in the first snippet on the linked page, and would save the hassle of using multiple var expansions of the %% and ## et al sort.
Bash is slower than other POSIX compatible shells but once you start running external commands for any substring or replace operation you loose much of this performance edge since forking is comparable slow.
One reason why I personally prefer to use Bashisms like ${x//str/replace} or [[ $value =~ $pattern ]] instead of doing the common x=$(echo $x | sed s/str/replace/) which has to launch two processes just for the sake of avoiding Bashism. (or grep -oP ... which is nice but a BASH_REMATCH is often simpler)
If the script does a lot of unstreamable replacements, you're right. But there are still ways out of bash.
I prefer no fork, no bashism, reusable functions:
set -euf
replace () {
local t=
REPLY=$1
t="${REPLY#*"$2"}"
test "$t" != "$REPLY" || return
REPLY="${REPLY%"$2$t"}$3$t"
}
replace_all () {
REPLY=$1
shift
while replace "$REPLY" "$@"; do :; done
}
input="foo bar foo baz"
replace_all "$input" "foo" "HELLO"
echo $REPLY
Not exactly easy to write, but now that they're functions, it doesn't matter since I can reuse them.
Regarding performance, it is slower than bash, but not significantly.
Times for 1000 calls:
9.908s -- sed (one fork per replacement)
0.015s -- bash x//str/replace
0.088s -- sh replace_all
Times for 50.000 calls:
0.351s -- bash x//str/replace
0.631s -- sh replace_all
Also, you can get further performance by inlining replace inside replace_all instead of making one call another.
Note that I could have done several replacements inside a single sed pipe, but I decided to count the performance for doing it like you suggested x=$(echo $x | sed s/str/replace/). The same goes for my functions, one invokation per replacement (in fact, they are tuned for that scenario).
sed can absoltely beat the shell in scenarios where you can make one fork do lots and lots of replacements. It depends on the scenario, and how proficient you are in writing sed (which can do branching, keep state, all sorts of things portably).
--
From an architectural point of view, it makes sense to have a simpler `sh` and keep a sort of standard library of functions, instead of feature creeping the interpreter with weird arcana. It makes shells like dash easier to maintain, easier to debug, easier to port and safer.
The reason Bash has so many features is that doing these things natively in the shell is faster and more convenient. After all, these features weren't just added randomly.
These features were added slowly, randomly, as time passed. The weird syntaxes for all of these are a clear sign of this.
Practically all shell interpreters suffer from decades of feature creep since the original bourne shell. They're full of weird arcana, hard to maintain and debug.
Many people tried to replace bash and died on the hill because of these weird features, or ended up creating a replacement that is even slower, or ended up rediscovering what perl is.
Oh yeah! I was unaware too! Nowadays I quickly jump to python instead of using Bash even for the simplest of scripts , but this could help creating tiny and easy to understand scripts for some integrations...
> I quickly jump to python instead of using Bash even for the simplest of scripts
You don't seem to respect the old, venerable, well-tested adage: "once your shell script becomes too complex, switch to a real programming language like python".
Or, the zen version (formally equivalent, but with quite a different tone): "once your program becomes sufficiently simple, turn it into a beautiful shell script".
The true power of shell script is to coordinate programs. Once you find yourself altering data with the shell constructs, that's the sign to use $LISP instead.
> The true power of shell script is to coordinate programs. Once you find yourself altering data with the shell constructs, that's the sign to use $LISP instead.
one might awk how much logic one can bash into a script before leaving the beloved shell
I set a mark, move to somewhere else, then save the area between where I am and the mark: ma(assign mark "a" to position), jjj(move three lines away), |a(pipe from current-position to the "a" mark then a ! prompt appears so enter...) cat >somefile (which dumps the selected text, cur-pos to mark "a", into somefile).
That was great for saving snippets of news or emails.
Also, the -j setting. Sets the line position for searches so context is available, eg using -j8 means the search is 8 lines from the top of the screen.
reply