Useful wrappers for apt-get, apt-source and apt-file
Link: https://github.com/blueyed/oh-my-zsh/blob/master/plugins/apt/apt.plugin.zsh
I've finally started to manage the setup of my dotfiles (configuration files) for shell, editor etc.
It is based on the popular dotfiles repository of ryanb and my fork can be found at github:blueyed/dotfiles.
While I'm still in the process of setting this up, I've just added the apt-* helpers I wrote some years ago:
They provide neat things like asrc -g hardy hello to get the version of the "hello" package from hardy (via "apt-get source" and the version number grepped from "apt-cache madison" - so you need to have it in your apt sources list, of course).
Also, ashow -g testing hello will show the package from Debian testing.
Apart from that these are mostly aliases, like "aup" for "sudo apt-get update" and some of them support shell completion (of package names) for e.g. "ainst" ("sudo apt-get install"). Shell completion works in both zsh and bash (at least).
You can get the file (to be sourced in a shell) from:
https://github.com/blueyed/oh-my-zsh/blob/master/plugins/apt/apt.plugin.zsh.
Feedback is very welcome and I am sure some of this is in packages like debian-goodies already (actually, there's nothing like that in _that_ package, but..).
Does it make sense to add (parts of) it to some package for easy installation across Debian/Ubuntu?
7 comments
My update command is just "update"my sudo apt-get upgrade command is "upgrade".
My sudo apt-get install command is "install". Have you EVER used the other install binary yourself? Me neither.
I don't understand what people have against a usable command line.
sudo shutdown -r now?
restart
Seriously. Shouldn't matter what distro I'm on, I don't care about the software I just want it to do what I want it to do.
And whoever took the 'o' and 'r' out of the 'password' command, I know you're out there... You took away an hour of my life I will never get back. Really? Two letters? Get a better keyboard layout. 
Better contribute that to wajig 
Nice -- good idea. My own aliases tend towards even more economy:
alias au='sudo apt-get update'
alias aug='sudo apt-get upgrade'
alias an='sudo apt-get install'
alias ai='sudo apt-get install -s'
alias arr='sudo apt-get remove'
alias as='apt-cache show'
alias se='apt-cache search'
alias scan='egrep -v "^#|^$"' # scan config files, removing whitespace and comments for display
alias scanh='egrep -v "^ \*|^\/\*|^$" ' # scan file to remove C-style comments
On some of my systems, I also use apt-fast, so I use apt-fast instead of apt get for aliases, as in:
alias an='sudo apt-fast install'
Where would the aliases go in your design?
I've been putting these in /etc/bash.bashrc for multiple user use. Don't know if this is the ideal approach.
With that, I also include:
alias brc='sudo vi /etc/bash.bashrc && . /etc/bash.bashrc'
Thanks for your feedback, vevel.The main point are not the aliases though - but rather the functions, especially the "-g" argument, allowing to get easily the source package of a specific distribution (very useful when working on Ubuntu bugs).
I am currently in the process of reorganizing my main dotfiles (like I've said already), and I have just moved aliased to a ~/.sh/aliases.
I will switch to zsh now, but this is really shell agnostic, therefore the ".sh" dir/prefix.
I have mixed system wide and local settings/aliases before, but will now centralize those - and use them via the home directory.
Worst case scenario is having to install my dotfiles twice for $USER and root on some setups.
Allows me to override any system wide setup though anytime - and there are setups where you can control the user relevant files only anyway.
Thanks for the reply. Yes, re. the source package features: I should have made it more clear that this was the "good idea" I was referring to.That is very nice, very useful -- would have used this earlier in the week had I seen your post.
Thanks....
And I probably should look at wajig, since I have seen that mentioned a couple of times....
You know, after looking at wajig, my only concern is that it is a tool that isn't installed by default. Kind of like the old 'vi' argument -- learn vi, because it is installed everywhere. It is hard to do phone support (in my case, informal support for family members etc.) for package management if the first step is to find and install wajig for the distro in question. Probably not insurmountable. 
Comment feed for this post
![[FSF Associate Member]](/media/users/daniel/icons/fsfmem80x15.png){kind=icon}