Sl: a mirror version of ls
gir.st
gir.st
It's better to learn and remember the exact commands. If you find yourself typing the same long command over and over again, the task should probably be automated or scripted as part of a separate pipeline.
Assuming you are successful with aliasing and don't accidentally do something unexpected and catastrophic to your system, the moment you login to another system you will be lost and unable to remember any of the original and core commands.
I find `alias gcr="git clone --recursive"` to be very productive for me. I never forget what it stands for, it saves me time, and I never have to go fetch all submodules if the repo uses them. `alias lt=ls -tor` is helpful, as it shows me extra information about files in reverse sorted order, so that the most recently modified files are at the bottom.
I don't run any risk of forgetting either of these because of their mnemonic nature, and they're not something I can script.
So I started using Terraform. A lot. Day in, day out, I would type terrafrom, teraform, terrafomr. And I'm a good typist! But something about that word just makes it hard to get out right. (I have a similar issue with 'infrastructure'.)
Finally replacing it with a 'tf' alias saved me a lot of frustration.
Why do you have to "type" terraform? Are you running terraform from your own machine? Don't. Setup a Jenkins pipeline or what have you. Unless you happen to work alone – and I'd argue even then.
Moving Terraform to Jenkins was the second best thing we have ever done – first thing was moving tfstate to remote storage.
You can provide any required parameters (or jenkins can fetch for you), run terraform init, plan, ask for confirmation, apply (and even perform retries). And then run any post steps. Even managers can use terraform now (and we have a pretty complicated setup).
I guess only Terraform Enterprise might beat this, but I have little experience with that.
How many thousands of times should you type "terraform" in full before you're comfortable with all of the nuances of syntax and command-line arguments? (Or kubectl --namespace=kube-system get pods, or git pull --rebase origin master for that matter)
And if these managers who couldn't use Terraform before, can use it now, but also require someone to set up a Jenkins job for them...
I'd just be sorta worried that they might get the idea this tool could only be run with adult (Root-type) supervision, because I've seen it happen like this so many times.
(I'm sure it's better than the alternative, which is a world in which managers can't or won't ever learn to run this tool at all, simply because it requires use of a command-line.)
Just curious do you use Terragrunt or something like it? Or does the fact that Jenkins only allows a single job to run once concurrently actually obviate the need for that... I'm not using Terraform (but wish I was) although I've got a basic Jenkins setup for some CI things on my less than 10-person product team.
To be fair I think you may have just convinced me that I need to be able to do this too. I actually have a Jenkins server and we use it for CI to run our product's test suite by hand, but not much else. We have a team that provisions EC2 resources, we have a team that handles security rules, and everyone is a competent professional but sometimes as a developer the appearance from the outside of that group is that a left hand does not know what the right hand is doing.
I guess with Jenkins and a remote tfstate, you make it very easy to know who owns what resources, and to see who has done what, or even specifically which locks are actually open and what resource is currently in motion.
It might surprise you, but there are cases where you might not want to run Terraform in a pipeline.
:+100:
Here's a direct link to the awspec tests for one of the repositories: https://bitbucket.org/geoscienceaustralia/webserver/src/ab6f...
An alias is only going to be available to the current shell and it's going to be stored in memory. A script is going to be accessible to the entire system and stored on disk.
In the majority of my use-cases I require shipping software to production systems and my scripts are used to manage production services. The last thing I want to do is having to manage aliases on multiple systems ( some of which I do not own ).
My basic philosophical disagreement is with the idea of avoiding interactive command shortcuts. This essentially limits you to only using command line features you can memorize, or be willing to look them up every single time. There are too many commands, with totally inconsistent argument styles, for this to be practical.
The result is that you're only going to use a small subset of the command line's power if you limit yourself in this way.
RANT: Yes, I agree alias ll="ls -l" is a crutch. But why does 'sort' use -t for separator and -f for field, while 'cut' uses -d and -k? The famously composable Unix tools really aren't very consistent. Radically improved tab completion and documentation (vs man pages and Info) might be a start, but in the end you have to evolve new syntax.
I'd agree with the concept of memorizing it in theory but I'm with you that it becomes a bit too much when the tooling differences in switches from command to command can be even minimally different (something as simple as scp "-P" vs ssh "-p" is easy to forget in the moment). Yeah, I can memorize that example but everything has flags for everything and they can be vastly different (like you mentioned sort vs. cut)
-o fieldseparator=,
-o fieldkeys=2,1,3
which could be used by any program whose capabilities require such a specifier, could be parsed from config files and environment variables, and aliased for reduced verbosity.
Aliases I only use as direct abbreviations of the underlying command.
But, for your main tools, if dot files can make a difference then you should make an exception.
Vim without my .vimrc is almost a different apps, and I'm way less efficient without it!
I'm not using Vim, but I do keep configuration files for my local text editor.
Sarcasm aside, you are correct but it’s better to learn things first. But after a while, those aliases and dotfiles are just shortcuts. I’ve had my dotfile repo with things I need for something like 8 years and hasn’t changed much beside vim plug-in updates and I could just whip up the same setup manually but it would take a half a day to get everything to how I prefer things. They just save time and sanity.
Now what would be really nice is to have config forwarding built into ssh, similar to how ssh key agent forwarding works.
But if you can ssh in, you could just tramp on your local emacs to edit files remotely. It's quite magical.
I turned all of them into two-letter aliases.
It’s perfect!
Here is a direct link to the line in question of my bashrc:
https://github.com/ctsrc/dotfiles/blob/a2c87d22a4de7486dadfe...
I recently put my dotfiles on GitHub. As you can see from the above linked file, my bashrc is short and sweet.
Thes dotfiles were, counter to what one might think given how few and short they are, not thrown together in short time.
These dotfiles reflect the specific workflow I’ve developed for myself over years of using FreeBSD, Linux and another couple of Unices.
In the beginning my dotfiles were long and messy and they accumulated a lot of cruft that I never used. That’s why I didn’t use to have them on GitHub. But over time I cut them down to only the things I actually used. The end result was that my entire bashrc is authored by myself for myself with nothing copy-pasted from the Internet.
That’s the secret to successful aliases as well IMO — make aliases where it really matters. Then you’ll only have a few, which in turn makes it easy to navigate systems where you don’t have your full set of dotfiles.
My git aliases are very important to me, but since there are only a handful of them and I almost don’t alias anything else, I can easily type them onto new systems by hand if need be.
The first thing I do on a new machine is tweak my profile to alias 'cp', 'mv' and 'rm' to prompt me before performing destructive operations, and to be verbose about what they're doing. Doing this has saved me from myself several times. While I'm there I usually also set 'ls' to use colored output, since I like to have an easy at-a-glance way to know what it's showing me.
The second thing I do is tweak the prompt to include the current time, so I can scroll back and find out when I did things, or see how long things took without having to use explicit timing commands. Doing this has also been helpful on multiple occasions.
After that I go set EDITOR, set HISTCONTROL how I want it, and usually set up a couple other files which get sourced by the main profile, in order to set up tool- or API-specific env stuff.
This does end up producing a fair bit of stuff in those "dotfiles" you dislike, but I find it to be a quite useful approach.
However there is stuff like this:
alias ec2ls='aws ec2 describe-instances --query '\''Reservations[].Instances[].[Tags[?Key==`Name`].Value|[0],State.Name,InstanceId,PrivateIpAddress,PublicIpAddress]'\'' --output text | column -t | sort'
I could try to remember it and type every time. But why? Sometimes all I want to do is list instances and grep for something quickly. If I can 'ls' for files, why would 'ls' for AWS (or openstack or what have you) be any different?
alias sl=ls
and have productivity reach unseen levels! alias grpe=grep
alias gerp=grep alias fuck='sudo $(fc -nl -1)'
Be very careful with this.I looked at thefuck but it didn't seem to do anything I needed.
shopt -s histverify histreedit
Bash will let you then confirm the actual command it's going to run: sudo !! function fuckgit
rm -rf /tmp/fuckgit/
git clone --no-checkout (git config --get remote.origin.url) /tmp/fuckgit/
rm -rf .git/
mv /tmp/fuckgit/.git .
rm -rf /tmp/fuckgit/
end alias gti='/usr/local/bin/git'
alias gut='/usr/local/bin/git'Every. Single. Time. Sometimes I even typo it many times in a row.
There must be //something// in that combination of letters, because I don't recall ever having that many mistakes with any other commands.
Do you use regular dvorak or programmer dvorak?
alias l="tree --dirsfirst -ChFL 1"
alias l2="tree --dirsfirst -ChFL 2"
alias l3="tree --dirsfirst -ChFL 3"
alias l4="tree --dirsfirst -ChFL 4"
alias l5="tree --dirsfirst -ChFL 5"
( or https://github.com/ogham/exa in tree mode ) alias ls='ls -lah --color="auto"'
alias l='ls -lah --color="auto"'
alias ll='ls -lah --color="auto"'
alias sl='ls -lah --color="auto"'"What the...why is my screen blac--is that a train-AW DAMMIT".
That person was me. The guy who installed the damn thing.
The progression from confusion, to curiosity, to realization that I had in fact...just played myself was kind of amusing in the moment.
Faced with the choice of punishing myself for making a mistake vs. adapting my environment to accommodate me, I'll always choose the latter.
(Plus, since you use `ls` so frequently, just make `l` an alias of it, especially if you have difficulty typing "ls"! Using a computer doesn't have to be some weird, punishing, bondage and discipline experience.)
alias -- -='cd -'
alias ..='cd ..'
alias ...='cd ../..'
alias ....='cd ../../..'
alias .....='cd ../../../..'
alias ......='cd ../../../../..'
alias l=ls
alias la='ls -a'
alias ll='ls -l'
alias lla='ls -la' function up {
local ups="."
for((i=0;i<${1:-1};i++)); do
ups="${ups}/.."
done
cd "$ups"
}A while ago when I was bored I was thinking of golfing those aliases to say (pseudocode):
for i in 2..6:
alias '.'*i=cd '../'*i
but I didn't know all the shell needed and just wound up leaving it as is.Edit: turns out Zsh has a 'repeat' built-in:
alias $(repeat 7 echo -n '.')="cd $(repeat 7 echo -n '../')"
Still, non-portable, less clear, not worth changing the aliases. # Quick ../../.. from https://github.com/blueyed/oh-my-zsh
resolve-alias() {
# Recursively resolve aliases and echo the command.
typeset -a cmd
cmd=(${(z)1})
while (( ${+aliases[$cmd[1]]} )) \
&& [[ ${aliases[$cmd[1]]} != $cmd ]]; do
cmd=(${(z)aliases[${cmd[1]}]})
done
echo $cmd
}
rationalise-dot() {
# Auto-expand "..." to "../..", "...." to "../../.." etc.
# It skips certain commands (git, tig, p4).
#
# resolve-alias is defined in a separate function.
local MATCH # keep the regex match from leaking to the environment.
# Skip pasted text.
if (( PENDING > 0 )); then
zle self-insert
return
fi
if [[ $LBUFFER =~ '(^|/| ||'$'\n''|\||;|&)\.\.$' ]] \
&& ! [[ $(resolve-alias $LBUFFER) =~ '(git|tig|p4)' ]]; then
LBUFFER+=/
zle self-insert
zle self-insert
else
zle self-insert
fi
}
zle -N rationalise-dot
bindkey . rationalise-dot
bindkey -M isearch . self-insert 2>/dev/null
For doing "cd ../.." I type "cd ...", each extra "." adds a "/.." to the argument.It works for any command, cp/mv/whatever.
There may be nicer versions, certainly shorter versions are there if I search "rationalise-dot" in Google.
alias .=cd
alias ,=pushd
alias ,,=popd
alias ,.='dirs -v'
No need to alias .. as in zsh you can use a dir name as a command to cd to it. Setting cdpath can further cut down on typing. For example cdpath=(. .. ~/go/src ~/src ~)I come to this idea because I am left-handed and if I have made this mistake, it has happened infrequently enough that I can recall neither a particular event nor the fact of such events having occurred. I would be curious about the handedness of people who make this mistake frequently (enough) and those who believe they do not.
body {
max-width: 50em;
margin: auto;
padding: 1em;
line-height: 1.5em;
}
pre {
overflow-x: auto;
}By all means, type however you want to type, but if you never ever make a mistake, then you could push yourself harder.
In my experience, the primary factor limiting my typing speed is the rate of errors. It's generally around 1-2%, but the time noticing and fixing those errors takes a disproportionate amount of time.
In other words, to type fast, learn to type accurately and gradually speed up while maintaining your accuracy.
# some common typos
alias grpe grep
alias gpre grep
alias mroe more
alias mreo more
alias rmeo morehttps://gist.github.com/richardkiss/4fba0c6bd27eb39a9eb56074...
is this actually valid? Does it mean the code _is_ GPLv3 licensed or not?
> 4. Conveying Verbatim Copies.
> You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.
If you want to redistribute it you have to go to your own efforts to give everyone you distribute it to a copy of the GPLv3 text.
alias sl='/bin/ls -l | tac | rev | column -t'