Didnt know about disown. Great, no more nohup
Shell Tricks That Make Life Easier (and Save Your Sanity)
271–280 of 287 posts
Re: Shell Tricks That Make Life Easier (and Save Your Sanity)
#272One trick I use all the time: You're typing a long command, then before running it you remember you have to do some stuff first. Instead of Ctrl-C to cancel it, you push it to history in a disabled form. Prepend the line with # to comment it, run the commented line so it gets added to history, do whatever it is you remembered, then up arrow to retrieve the first command. $ long_command $ #long_command $ stuff_1 $ stu…
Ctrl+q in zsh is much better, I don't remember if bash has it.
You write a command, you remember that you need to do something else first, press ctrl+q/the lines gets cleared, write a different command and after you press enter to run it the old command appears again :)
Re: Shell Tricks That Make Life Easier (and Save Your Sanity)
#273I just open, agent in tui, and ask it to do what I want and make a plan, i read the plan edit it and run it. Simple, no need to learn any commandline these days. I used to use arch and all, and managed many big projects. I find little value in learning new tools anymore, just feed it docs and it generated working plan most of the time Now I've moved to coding in Haskell, which i find suits me better than wasting my t…
There is no value gained if you never learn.
Re: Shell Tricks That Make Life Easier (and Save Your Sanity)
#274One thing I find life-changing is to remap the up arrow so that it does not iterates through all commands, but only those starting with the characters I have already written. So e.g. I can type `tar -`, then the up arrow, and get the tar parameters that worked last time. In zsh this is configured with bindkey "^[OA" up-line-or-beginning-search # Up bindkey "^[OB" down-line-or-beginning-search # Down
That's a nice one. One thing I do is configure my keyboard so that "modifier+{ijkl}" mimicks the inverted T arrows key cluster. So there's never a need for me to reach for the arrow keys. And {ijk} makes more sense than vi's {hjkl} and is faster/more logical/less key fingers travel. The nice thing is: as I do this at the keyboard level, this works in every single map. "modifier" in my case is "an easily reachable key…
I did the same, starting with Ergo Mode in Emacs many years ago, and ending up today with a programmable split keyboard with those keys as arrows on a layer. For when I'm on a laptop without the keyboard, I have a mishmash of solutions that bind to Alt+{ijkl}
Re: Shell Tricks That Make Life Easier (and Save Your Sanity)
#275`set -e` is almost never what you want in your scripts. It means "silently exit immediately if there are any u handled non-zero exit codes". The thing that trips most people up on that is subshells when your trying to catch output into a variable, if it gets a non-zero exit code your entire script suddenly exits.
`set -e` really only makes sense if you setup a trap to also print what line you exited on, and even then only for debugging (e g. `trap 'echo "ERROR: Line $LINENO" ERR'`)
Conversely, `set -o pipefail` should be set in every script. It makes scripts with pipelines do what you expect, and the whole string of pipeline commands gets set to an error if any of the commands inside of it exit with an error. Default behavior for historical reasons is still to ignore all exit codes except the last command in a pipeline.
Re: Shell Tricks That Make Life Easier (and Save Your Sanity)
#276Maybe not a shell trick per-se but I have been a very big fan of zoxide. It can jump around your common directories. If you have a ~/workspace/projects and you are anywhere and type `cd projects` it will take you to that directory. I never realized how much I got hooked onto it, until I used a system without it.
For me I find I never have any reason to jump between directories based on frecency. Like ever. If I'm jumping between a few directories they're almost always named very similarly and that causes problems with the frecency ordering, especially when they're deep paths that get truncated.
If I really happen to be jumping back and forth a lot, I use `pushd ...`, and then I can reference my other directory with `~1/` and toggle between the two with a bare `pushd`.
Re: Shell Tricks That Make Life Easier (and Save Your Sanity)
#277My header on top of every script #!/usr/bin/env bash set -eEuo pipefail # shellcheck disable=SC2034 DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" #######################################################
If you're using `set -e` you almost always want a trap on ERR to print where you suddenly exited from your program. Otherwise there's no way to tell.
Also worth mentioning, but not including permanently, is `set -x` which will print every command to stderr with a `+ ` prefix before running it.
For `DIR` I usually pick a name less likely to conflict with one randomly selected in my script, like `SCRIPT_DIR`.
You also need to think about symlinks and how you want to handle them. Your current `DIR` resolution gives you the directory name without any symlinks resolved. If you're possibly a script that got symlinked to by someone, this may not be the directory of your actual script anymore, but the directory containing the symlink. As long as you want that it's fine, but a lot of the time you want the script to see it's resolved folder so it can call scripts in the real folder with it instead
Re: Shell Tricks That Make Life Easier (and Save Your Sanity)
#278My header on top of every script #!/usr/bin/env bash set -eEuo pipefail # shellcheck disable=SC2034 DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" #######################################################
Wait... Most of my shell scripts have zero unused variables: I prefer to comment them if I may need them later on. Why do you disable SC2034? I don't think not having unused variables prevent me from doing things in my scripts!? I understand if it's a preference but SC2034 is basically one of my biggest timesavers: in my case unused variables are typically a bug. Except, maybe, ANSI coloring variables at the top of t…
It depends too on whether you use shellcheck as a primary tool or not. I prefer to have no shellcheck errors/warnings by default so when they do appear it's very obvious. But having a consistent opening block on a bunch of scripts is often more important, so setting a shellcheck disable on that one variable that may or may not be used is a better solution.
Re: Shell Tricks That Make Life Easier (and Save Your Sanity)
#279My favourite shell trick is to comment my code: $ some_long_command -with -args -easily -forgotten # thatspecialthing ... Some weeks later .. $ CTRL-R .. finds: $ some_long_command -with -args -easily -forgotten # thatspecialthing Need to see all the special things you've done this week/whenever? $ history | grep "\#" ... Makes for a definite return of sanity ..
One of the peer comments alludes to this and mentions that it's bash only. Doesn't work in zsh by default apparently.
Re: Shell Tricks That Make Life Easier (and Save Your Sanity)
#280Its almost ironical that we still use the Terminal - and many use it like in the eighties using Bash - and seem to have forgotten that we should invent a better terminal & shell than doing all the workarounds to handle the quirks of the current systems.
You can install whatever shell you want on your system, and there are tons of better alternatives out there. Where it's actually sticky is in the lowest-common-denominator cases, when you need to throw together a quick series of commands that need to be run on a semi-arbitrary system. In that case there are VERY few options because you have to use whatever is already on the system. Sometimes you're lucky enough you can safely assume bash is present, but in many cases you have to assume only sh. Unfortunately both are a difficult/footgun enough language that it greatly helps to start out using it daily to get familiar, and that's where most people end up peaking. Additionally you may need to manually jump into that semi-arbitrary system and do things manually. You're limited by the minimal tools already there, so you better be familiar enough with them already. This is the very reason I've learned some basic Vi commands as well, even though I would never even consider using it otherwise.
In my experience Power shell is actually a terrible replacement because you have to learn not only every command, but the structured return and available input formats of every command in order to do anything. The design of almost all shells is specifically to avoid that and reduce to a common universal input/output format. Powershell could certainly be useful as an intermediate choice between a full blown language and shell scripting though, if you needed more power but not so much to make it worth the load of a real language, but would also require it to be ubiquitous already (which it's not).