Protip: don't create aliases that override common commands (e.g. alias cp='cp -r'). Months down the road, you'll try to copy/paste some long piped command, and be confused as to why it works on everyone else's machine but not yours
Instead, create alternative commands, like alias lsl='ls -lah', and put in the work to make it the default thing you type.
uhh, hmm. For thirty years or so I've lived by these two (shell immaterial):
mv='mv -i'
rm='rm -i'
simple enough to add /bin/ to the command if I really mean it. That fixes the pipe issue too. I've had new to linux new hires go 'uh well I shoulda done that thanks I've done it now' more than once.
> Alias: rm
> Command: rm -r
Purpose: Because when I type "rm" I don't want to always have to specify "-r" for a directory.
Alias: cp
Command: cp -r
Purpose: Same as above. When I say "copy this" I always want it to copy whatever I'm specifying, even if it's a directory.
What I mean is: a precept of command-line fluency is to be able to drop onto arbitrary systems and change them in ways predictable to the next sysadmin. ‘gio’ is a vague entry point to a library, and even if the next sysadmin doesn’t know about gnome, the files you trashed end up in a common recycling bin.
On the other hand, KDE has a syntax that deserves an alias.
Do this in important directories for added safety:
$ touch -- - i
This creates a file called "-i" which will add the interactive flag, prompting you before deleting every file that rm was going to delete.
Agree. (I actually feel the same way about aliasing rm to “rm -i“).
I depend on the out of box behavior of rm. I’ll run “rm *” in a directory that has subdirectories I want to preserve, but where I want to erase the files.
alias ..='cd ..'
alias ...='cd ../..'
alias ....='cd ../../..'
alias .....='cd ../../../..'
alias ......='cd ../../../../..'
alias .......='cd ../../../../../..'
I think it's a terrible idea, because one day you'll try to enter a directory that shares its name with a command you don't know, and it will execute this command instead
That seems potentially unpredictable versus building the string and calling cd once. For example, if you use direnv-type tools there may be side-effects along the route¹. zsh users could have state changing via the chpwd functions too, although that could be mitigated with "cd -q" at least.
Obviously, it might not be an issue for your use, but just noting a potential gotcha if I were to lift it for example.
[ Golf-y zsh, because vacation time and AoC has finished: ..() { cd ../${(pj:/:)${@/*/..}} } ]
¹ even just expensive setup/teardown delays would feel odd*
# -i: Cause mv to write a prompt to standard error before
moving a file that would overwrite an existing file. If
the response from stdin begins with 'y’ or ‘Y’, the move
is attempted. (-i overrides any previous -f or -n)
alias mv='mv -i'
# -I: Request confirmation once if more than three files are
being removed or if a directory is being recursively removed.
This is a far less intrusive option than -i
There are few more general solutions to this interaction pattern(that also don't involve redundant history entries if you're OCD).
* bash has a glob-expand-word function which will perform inplace expansion of patterns, it is bound to C-x* out of the box. Using it will expand the pattern before point. Depending on the keymap you're using it is available via the same binding or the expand-word function in zsh too.
* C-xg (the glob-list-expansions function) will simply dump the expansion but retain the pattern in the command, if you'd prefer it didn't get added to history fully expanded for example. Again depending on keymap in zsh it is bound to the same key and calls the list-expand function.
* You can recall combinations of arguments from any line in history, so in your example 'rm !*' would recall all the args to previous command. The main reason this is useful is that you can also apply substitutions to fix incorrect results, and also because you can target other lines not just the previous one. You can even tack a modifier on to print the result without executing to double-double-check things, should you be feeling super careful(rm !*:p). zsh supports the same syntax, but has advanced more advanced modification options.
Helpfully modern ssh, at least 7.x IIRC, can handle Include statements in the main config. You need to put includes before any host configs you have in the main config file lest it think the include is part of a host's configuration. But this makes managing cloud host configs for instance much easier.
I have aliases for zsh to quickly edit all my configs, it's pretty neat :
declare -x -A configs
configs=(
gdb "$XDG_CONFIG_HOME/gdb/gdbinit"
git "$XDG_CONFIG_HOME/git/config"
vim "$HOME/.vimrc"
wezterm "$XDG_CONFIG_HOME/wezterm"
zsh "$HOME/.zshrc"
)
for key value in ${(kv)configs}; do
if [[ $key == "zsh" ]]
then
alias ${key}config="$EDITOR $value && source $value && echo
$configs[zsh] has been sourced"
else
alias ${key}config="$EDITOR $value"
fi
done
Just use zshconfig now if you need to add a new config file to the array and get a new alias
I use a variation of this to enable my conda environments - I always name the conda env the same as the top level git folder and can then quickly enable my env with an alias
I have almost the exact same but with "--restrict-filename" lest you end up with emojis and other Unicode characters you do t necessarily want on your file system.
I came up with this alias for xargs, I find it quite handy,
# f# like |> pipelining, example `echo "~/.bashrc" |: vim _`
# sed here is removing the last newline of the output
alias ::='sed "$ s/\n$//" | xargs -I_ --'
Usage example, where `_` is a marker `::` (xargs) uses to swap in the pipe'd value
sudo docker ps -a | skip 1 | col 1 |:: sudo docker rm _
skip, col are other aliases/functions,
function col {
eval "awk '{ print \$$1 }'"
}
function skip {
tail -n +$(($1 + 1))
}
function take {
head -n $1
}
function mkcd {
command mkdir -p "$1" && \
command cd "$1" && \
pwd
}
I'm thinking of writing one for git clone, `git clonecd` or something, to cd into a cloned directory. Note that having an executable named `git-foo` in your $PATH lets you call it like a git subcommand, `git foo`
> I also have another alias which will SSH into my shared hosting, shortening ~70 characters down to just `sshchuck`.
You can also accomplish this by adding `chuck` to your `~/.ssh/config`. IMO it's better to do it that way because you don't break tab completion. Indeed, if your shell is setup for it you should be able to tab complete any entry in your SSH config.
I have a bunch of directories I always go to, and instead of cd-ing on a relative path from where I am, I prefer using an interactive way to select where to go (I’ve aliased this script as “c”):
I rely on zsh and its search. Basically just type cd and follow it by enough characters to narrow down your search, then up arrow. History search has always surprised me seeing how I am mostly always doing the same thing. Things actually work before even needing to search manually since the history will suggest commands. (These use fairly well known plugins. I never use oh-my-zsh or any kind of plugin manager)
I use this zsh function and define my git alias in my git config.
# No arguments: `git status`
# With arguments: acts like `git`
function g() {
if [[ $# > 0 ]]; then
git $@
else
git st
fi
}
# Complete g like git
compdef g=git
For git aliases you should definitely checkout alises[1] you can define in your global git config, ~/.gitconfig, and the fact git will let you define custom subcommand if you create a `git-foo` executable in your PATH, for example, create a executable shell file called, `git-foo` somewhere in your PATH and you can run it like `git foo`.
Instead, create alternative commands, like alias lsl='ls -lah', and put in the work to make it the default thing you type.