Love Your Terminal(blog.andrewhays.net)
blog.andrewhays.net
Love Your Terminal
http://blog.andrewhays.net/love-your-terminal
136 comments
YA post about making fancy prompts - at least its not about how to make a ssh tunnel ;-)
Personally I'm never using anything, or adding any fancy setting, if it doesn't serve any direct purpose and/or is not clear, simple and efficient.
It's not because I believe "simple" and "efficient" are "cool" or "better". It's just because it's always what made _me_ efficient. I don't lose much time digging configs either, and I scan man's pretty quickly every time I need something.
In the end that means my shell looks boring. White on black. Username, host, current directory, VCS info if any. Colored output for tools that support it in a sane fashion. Merged shell history. That's it.
Defaults are in general sane. That's why they're defaults after all. Oh and redoing my dotfile is ~ 2min from memory and work everywhere obviously. I don't need to care if I'm going to spin a VM, it'll work the way I expect it without having to copy stuff and tinker around.
I do the same for the gui so i generally just run KDE or MATE. Tinkering 3 days with awesomewm or using someone's "super cool" but useless configs.. nope, not my thing ;-)
Personally I'm never using anything, or adding any fancy setting, if it doesn't serve any direct purpose and/or is not clear, simple and efficient.
It's not because I believe "simple" and "efficient" are "cool" or "better". It's just because it's always what made _me_ efficient. I don't lose much time digging configs either, and I scan man's pretty quickly every time I need something.
In the end that means my shell looks boring. White on black. Username, host, current directory, VCS info if any. Colored output for tools that support it in a sane fashion. Merged shell history. That's it.
Defaults are in general sane. That's why they're defaults after all. Oh and redoing my dotfile is ~ 2min from memory and work everywhere obviously. I don't need to care if I'm going to spin a VM, it'll work the way I expect it without having to copy stuff and tinker around.
I do the same for the gui so i generally just run KDE or MATE. Tinkering 3 days with awesomewm or using someone's "super cool" but useless configs.. nope, not my thing ;-)
Yup. Everybody and their dog want fancy prompts with lots and lots of info, and I never understood why. Most of the time I don't need any information on my bloody prompt. I just need it to sit there and alert me if something is unusual, maybe, but not to get into my hair otherwise.
A couple of years ago I settled on one minimalist prompt, and I've used it ever since. I've even written my own post about fancy prompts[1] … I guess everybody has to have one!
[1] http://a-dimit.blogspot.de/2010/12/perfect-prompt.html
A couple of years ago I settled on one minimalist prompt, and I've used it ever since. I've even written my own post about fancy prompts[1] … I guess everybody has to have one!
[1] http://a-dimit.blogspot.de/2010/12/perfect-prompt.html
I agree. In fact, reading your post, I'd nearly call your prompt fancy, mine just tells me user, and directory, everything else I'll runn a command for.
I'm largely the same. The only terminal app I did play around with the configs for was tmux because I really hated the defaults on that. And as I only ever need to run tmux from my client PC (it's a bit pointless running tmux inside of tmux), i don't have to arse about with copying config files about.
Cool guide. For beginners I'd also suggest restraint with your dotfiles. It's easy to rush into installing oh-my-zsh and using vim with every plugin you can find, but I found that made for a really confusing learning experience, especially if your config ever breaks.
I went from Vim and shell beginner a couple of years ago to a serious user, and built up a nice set of dotfiles along the way.
Janus and oh-my-zsh were big for me, but I never actually installed either one.
Instead, those were my Vim and Zsh department stores.
I'd get the itch to try something new, so I'd "go shopping" at those projects, find something new to pull into my config, and I'd learn to use that plugin or make sure I knew what that shell option was now doing for me.
Then, eventually, I'd get the itch and go shopping again.
Over time, I built up my dotfiles. As I learned, I naturally found myself ditching some of the plugins I pulled in along the way, and modifying or replacing some of the shell config with my own creation. But those projects we're great sources of some early "wins".
Janus and oh-my-zsh were big for me, but I never actually installed either one.
Instead, those were my Vim and Zsh department stores.
I'd get the itch to try something new, so I'd "go shopping" at those projects, find something new to pull into my config, and I'd learn to use that plugin or make sure I knew what that shell option was now doing for me.
Then, eventually, I'd get the itch and go shopping again.
Over time, I built up my dotfiles. As I learned, I naturally found myself ditching some of the plugins I pulled in along the way, and modifying or replacing some of the shell config with my own creation. But those projects we're great sources of some early "wins".
That's actually why I stopped tweaking things to hell and back, losing my config's was too painful. I usually just go for basic colour tweaks these days. It also makes me more portable and productive when I am using a new or someone else's machine.
I used to be all about portability, too. Worse, I was worried that other people needed to be able to work on my computer. So no Vim or Emacs, and always keep things simple.
You know what? I don't care any more. My computer is my computer. It does not need to work for other people and I don't need to work on other people's computers much. My Emacs loads many plugins, my Visual Studio is using ViEmu, I replaced my Finder and I remapped some keys on the keyboard.
This makes for a crazy confusing experience for anyone who sits down at my computer, but it works for me. And as far as compatibility is concerned, my Emacs init.el will automatically download and install all plugins it finds missing, so setting up a new computer is about as complex as copying one file.
You know what? I don't care any more. My computer is my computer. It does not need to work for other people and I don't need to work on other people's computers much. My Emacs loads many plugins, my Visual Studio is using ViEmu, I replaced my Finder and I remapped some keys on the keyboard.
This makes for a crazy confusing experience for anyone who sits down at my computer, but it works for me. And as far as compatibility is concerned, my Emacs init.el will automatically download and install all plugins it finds missing, so setting up a new computer is about as complex as copying one file.
Its not so much about others as I don't want to spend 3 hours setting up e very machine I touch, ie servers, borrowed machine etc.... I'm just as productive now (after a month of adjustment) but without the setup time.
I carry Emacs in Linux and Windows versions, along with xmodmap scripts to make caps lock a control key and switch it back again, on a flash drive just for that reason --- then I have the necessities available on every machine I sit down in front of.
Servers are a different story, but the ones I work with are all running Linux and have vi, which will do.
Servers are a different story, but the ones I work with are all running Linux and have vi, which will do.
Setup time got you down? There are plethora of dotfiles projects on github that already have easy scripted installation.
http://dotfiles.github.com/
http://dotfiles.github.com/
Homesick is another good one
https://github.com/technicalpickles/homesick
https://github.com/technicalpickles/homesick
> Its not so much about others as I don't want to spend 3 hours setting up e very machine I touch,
Most of the configurations just need to be copied. Just copy your .vim folder and you are setup with everything. Copy your .screenrc and that's that. I sync my dotfiles and then run a small script to set symlinks. That hardly takes 2 minutes.
Most of the configurations just need to be copied. Just copy your .vim folder and you are setup with everything. Copy your .screenrc and that's that. I sync my dotfiles and then run a small script to set symlinks. That hardly takes 2 minutes.
I used to take this approach. One day I found I had no choice but to remap CapsLock as a second Ctrl key because my little finger was in constant agony otherwise.
I've never had a second's trouble from the finger since then, but you should see me try to type on other peoples' computers now. I TEND TO WRITE IN ALL-CAPS A LOT BY ACCIDENT!
So for me there's no longer much point in caring about portability, and I have aliases and keyboard shortcuts and fancy PS1s to spare.
I've never had a second's trouble from the finger since then, but you should see me try to type on other peoples' computers now. I TEND TO WRITE IN ALL-CAPS A LOT BY ACCIDENT!
So for me there's no longer much point in caring about portability, and I have aliases and keyboard shortcuts and fancy PS1s to spare.
Yea, CapsLock must die and reborn as third Ctrl. Not only because of all caps, but some folks tend to map it to keyboard layout switching only because it gives them LED indication of the language being used.
It also makes your keyboard habits more portable, as laptop keyboards have different order of Ctrl and Fn.
I've run into the same issues. My solution is to reach a sort of balance between portability and usability.
My xmodmap + XMonad config is designed to be reproducible on Windows via AutoHotkey and OS X via SizeUp + PCKeyboardHack, that way I'm always in my home environment no matter the OS!
My xmodmap + XMonad config is designed to be reproducible on Windows via AutoHotkey and OS X via SizeUp + PCKeyboardHack, that way I'm always in my home environment no matter the OS!
How do you handle window-switching on OSX? I haven't found anything that satisfactorily reproduces the simple mod-j/k keys of xmonad.
I'm not on a Mac at the moment so I can't tell you the exact wording of the preference, but I just set it up through the hotkeys section of the keyboard system preferences pane.
One of the options allows switching window focus, and another allows switching through windows in the active application. There's no option for switching backwards, however. The way I deal with that is to separate any xmonad specific functionality behind a prefix-key submap in my XMonad config.
Any hotkeys that don't take the prefix I can use on any OS, the ones that do are xmoand specific. To me this keeps things nice and organized, while still letting me exploit the xmonad-contrib stuff to the full extent.
For example, instead of mod-j/mod-k, I use the window navigation extension behind the prefix so I get finer control over focus navigation, and this makes xmonad function precisely like tmux just with a different prefix key.
Can you tell I hate context switching?
One of the options allows switching window focus, and another allows switching through windows in the active application. There's no option for switching backwards, however. The way I deal with that is to separate any xmonad specific functionality behind a prefix-key submap in my XMonad config.
Any hotkeys that don't take the prefix I can use on any OS, the ones that do are xmoand specific. To me this keeps things nice and organized, while still letting me exploit the xmonad-contrib stuff to the full extent.
For example, instead of mod-j/mod-k, I use the window navigation extension behind the prefix so I get finer control over focus navigation, and this makes xmonad function precisely like tmux just with a different prefix key.
Can you tell I hate context switching?
Actually that's the only config that usually comes with me. I too suffered emacs pinkie for a while before doing this.
> losing my config's was too painful.
How do you lose your configs? Store them in github/dropbox and sync.
> It also makes me more portable and productive when I am using a new or someone else's machine.
With dedicated work and personal laptops, using a new or someone else's machine isn't a commonly occurring event. I would rather optimize for what I have 99% of the time.
How do you lose your configs? Store them in github/dropbox and sync.
> It also makes me more portable and productive when I am using a new or someone else's machine.
With dedicated work and personal laptops, using a new or someone else's machine isn't a commonly occurring event. I would rather optimize for what I have 99% of the time.
Being lazy usually. Also a mixture of devices and machines long before dropbox. So I became used to the defaults before there was a good solution to sync.
You don't do much work in large corporations I guess. When issued equipment and not having to much control you find it easier to just adapt, which is what I did.
You don't do much work in large corporations I guess. When issued equipment and not having to much control you find it easier to just adapt, which is what I did.
> You don't do much work in large corporations I guess.
I used to work for one. I still do but now I use my own laptop. But that's not the point. The point is if you have a machine, you don't need special privileges to write to your own home directory. If your org stops you from pulling things from the internet, well, that's a different story.
I used to work for one. I still do but now I use my own laptop. But that's not the point. The point is if you have a machine, you don't need special privileges to write to your own home directory. If your org stops you from pulling things from the internet, well, that's a different story.
Yes, so much easier to use your own machine for development just because you have control over everything. I'm sure some people need specialized machines, but for most... sticking to one laptop or ssh server really simplifies everything.
How do you lose your configs? Laptops mean you always have your machine, github (and like) means you have your configs even when you don't, and of course backups mean never losing data.
+1 for this. I tend to leave everything as vanilla as possible. My .vimrc has 3 lines, .profile pulls in a local JDK and that is about it.
That's a good tip. I try to keep my .vimrc down to about 20 lines and a couple of plugins (NERDTree and solarized, mostly). My .zshrc is probably a bit more dense, but I actually have it orgnized into separate files, and just source them from .zshrc.
If you're using git, I suggest fixing up your prompts so it doesn't display the sign for Mercury when in a git repo.
So much junk in a prompt... I clicked on the link to Steve Losh's page and had a heck of a time figuring out what commands he had actually typed.
The bash defaults are pretty reasonable: show your working directory, maybe your username, and a $ to end the prompt. If you're root, you get a # instead. It stays out of the way; if you want to get fancy, colorize it so lines you entered stand out. These days, I even turn off ls's colorizing half the time; then again, I always thought wibbley-wobbley 3d windows with glowing buttons were a little silly compared to, say, FVWM or i3.
So much junk in a prompt... I clicked on the link to Steve Losh's page and had a heck of a time figuring out what commands he had actually typed.
The bash defaults are pretty reasonable: show your working directory, maybe your username, and a $ to end the prompt. If you're root, you get a # instead. It stays out of the way; if you want to get fancy, colorize it so lines you entered stand out. These days, I even turn off ls's colorizing half the time; then again, I always thought wibbley-wobbley 3d windows with glowing buttons were a little silly compared to, say, FVWM or i3.
> So much junk in a prompt... I clicked on the link to Steve Losh's page and had a heck of a time figuring out what commands he had actually typed
The point of configuring your prompt is it has to be easy for you to read. Whether someone else finds it readable or not is a non issue. Though not as verbose as Steve Losh's, I use a similar prompt which looks like this:
Of course why do I need rahul@mean-machine - I can run 'who' and 'hostname', why do I need working directory - it's not like 'pwd' hasn't been invented yet; why would I need the branch name - 'git branch' is where it is at. But "if there is this painful long way you can do it, why would you do it the easy way" doesn't make sense to me.
> These days, I even turn off ls's colorizing half the time;
I am curious. What purpose that solves? Colorizing it helps me differentiate directories, files, executables, broken links.
> then again, I always thought wibbley-wobbley 3d windows with glowing buttons were a little silly compared to, say, FVWM or i3.
I don't think 'ls --color=auto' is comparable to woobly window.
The point of configuring your prompt is it has to be easy for you to read. Whether someone else finds it readable or not is a non issue. Though not as verbose as Steve Losh's, I use a similar prompt which looks like this:
rahul@mean-machine: ~/musings (git::master)
± $
Of course why do I need rahul@mean-machine - I can run 'who' and 'hostname', why do I need working directory - it's not like 'pwd' hasn't been invented yet; why would I need the branch name - 'git branch' is where it is at. But "if there is this painful long way you can do it, why would you do it the easy way" doesn't make sense to me.
> These days, I even turn off ls's colorizing half the time;
I am curious. What purpose that solves? Colorizing it helps me differentiate directories, files, executables, broken links.
> then again, I always thought wibbley-wobbley 3d windows with glowing buttons were a little silly compared to, say, FVWM or i3.
I don't think 'ls --color=auto' is comparable to woobly window.
A whole extra line above the working prompt? That just seems unnecessary.
If you need that info at any particular moment, make a command. I used to have one called wi (short for Where am I?) that threw out similar info. But displayed constantly? Yuck!
If you need that info at any particular moment, make a command. I used to have one called wi (short for Where am I?) that threw out similar info. But displayed constantly? Yuck!
> A whole extra line above the working prompt?
Because it's frequently useful, and thus the tradeoff of a bit of space for simplicity, speed and familiarity is worth it.
> If you need that info at any particular moment, make a command.
Right, so your prompt is composed of nothing but the hardcoded character `>`? (you obviously don't need the $/# toggle as you can use `whoami`, and you don't need the previous command's status as that's what `$?` is for)
Because it's frequently useful, and thus the tradeoff of a bit of space for simplicity, speed and familiarity is worth it.
> If you need that info at any particular moment, make a command.
Right, so your prompt is composed of nothing but the hardcoded character `>`? (you obviously don't need the $/# toggle as you can use `whoami`, and you don't need the previous command's status as that's what `$?` is for)
Setting your prompt to ";" can be useful, because then if you want to select a command with the mouse and paste it into another window, it's still valid even if you select the whole line--you don't have to worry about stopping at the prompt character, just triple-click the line (in X).
> Right, so your prompt is composed of nothing but the hardcoded character `>`
Hey that's what mine is! Actually it is simply the ')' character. I went from full on prompt-porn to nothing. For the most part this was just to see how much of the prompt I really needed on a daily basis (how often do I really type git branch because I don't know what branch I'm on, how often do I type pwd... stuff like that). Turns out I rarely use those commands, but to each their own.
Hey that's what mine is! Actually it is simply the ')' character. I went from full on prompt-porn to nothing. For the most part this was just to see how much of the prompt I really needed on a daily basis (how often do I really type git branch because I don't know what branch I'm on, how often do I type pwd... stuff like that). Turns out I rarely use those commands, but to each their own.
It's an interesting approach! I want to try it in combination with some custom 1-or 2-letter command that would display all this 'prompt-porn' in a single line on demand.
Maybe a 1 or 2-letter indicator on what host I am (e.g. nothing for local, P for production, C for cluster head...), got confused too often.
And, of course, fuzzy completions of zsh.
Maybe a 1 or 2-letter indicator on what host I am (e.g. nothing for local, P for production, C for cluster head...), got confused too often.
And, of course, fuzzy completions of zsh.
My prompt is usually the system default, because I work across multiple systems, some of which don't even have bash (let alone zsh), and changing it seems unnecessary. 'wi' is just there to remind me where I am once in a while.
My general philosophy is to deal with whatever is the default and not become reliant on customisations because other systems I'll be required to use won't have any of them set up.
My general philosophy is to deal with whatever is the default and not become reliant on customisations because other systems I'll be required to use won't have any of them set up.
> My prompt is usually the system default, because I work across multiple systems,
Unless you get new systems everyday, multiple systems just mean copying ssh keys followed by scp of dotfiles.
> some of which don't even have bash (let alone zsh),
If it has bash, .bashrc gets executed. If it has neither, I use the system default. Just because sometimes there won't be a shell I use or configure(1%) doesn't mean I am going to put up with whatever the system throws at me(99%).
> 'wi' is just there to remind me where I am once in a while.
Any my "once in a while" is frequent. Multiple machines, multiple projects, multiple branches.
> My general philosophy is to deal with whatever is the default and not become reliant on customisations because other systems I'll be required to use won't have any of them set up.
If I have customized my vim to hell, it generally means I am familiar enough with vim to understand how vim works. Same goes for bash, screen, zsh, what have you. It isn't like when once in an eternity, I am forced to use a machine where I have to type "git branch" instead of "gitb", I am going to forget it.
Unless you get new systems everyday, multiple systems just mean copying ssh keys followed by scp of dotfiles.
> some of which don't even have bash (let alone zsh),
If it has bash, .bashrc gets executed. If it has neither, I use the system default. Just because sometimes there won't be a shell I use or configure(1%) doesn't mean I am going to put up with whatever the system throws at me(99%).
> 'wi' is just there to remind me where I am once in a while.
Any my "once in a while" is frequent. Multiple machines, multiple projects, multiple branches.
> My general philosophy is to deal with whatever is the default and not become reliant on customisations because other systems I'll be required to use won't have any of them set up.
If I have customized my vim to hell, it generally means I am familiar enough with vim to understand how vim works. Same goes for bash, screen, zsh, what have you. It isn't like when once in an eternity, I am forced to use a machine where I have to type "git branch" instead of "gitb", I am going to forget it.
Everything is unnecessary. Some things are nice. Some of the nicest things are those which reduce cognitive load. Anything that makes it easier for my brain to "lex" the wall of text in front of my face is very nice indeed.
The fact that my prompt shows additional information is a secondary thing. (It's sometimes nice to scroll back through output and be able to see what directory I was in.) The _important_ thing is that the color and extra space make it exceedingly easy to visually chunk commands and output.
The fact that my prompt shows additional information is a secondary thing. (It's sometimes nice to scroll back through output and be able to see what directory I was in.) The _important_ thing is that the color and extra space make it exceedingly easy to visually chunk commands and output.
How did wi differ from the built-in pwd? I've never found myself wishing for more than that.
Not by much, it was only four things - pwd, hostname, username and (when I was working in clearcase a lot) clearcase view name.
Just something I could run if I switched back to a shell and kinda forgot what or where it was.
Just something I could run if I switched back to a shell and kinda forgot what or where it was.
A friend of mine has an extremely simple prompt. It just shows as $ or # (for root) and has a single field before that - the exit status of the previous command.
Still way too complex, simplicity means subscribing to the ed school of prompts: neither `$` nor `#`, just `?` when the previous command returned a non-zero status.
I understand using that because it was what you had, but why would you choose to strip your prompt of useful information? (I'm not trying to degrade the idea here, just wondering what use case it provides. It could have a very good one.)
I've never had a difficult time telling the difference between where my prompt ends and where the result begins. I think too much grows absurd quickly, but a little bit of information is nice, I think.
I've never had a difficult time telling the difference between where my prompt ends and where the result begins. I think too much grows absurd quickly, but a little bit of information is nice, I think.
This seems like a good place to once again plug fish[1]. Exactly those goodies I want in a shell and the autocomplete is so convenient I no longer know how I lived without it.
And there's all the other cruft removal.
[1] http://ridiculousfish.com/shell/
And there's all the other cruft removal.
[1] http://ridiculousfish.com/shell/
I've just installed fish and it doesn't support bang (!) history nor some basic scripting tools (eg $?) which makes it pretty useless for power users.
I can see how the colours and suggestions are great to those who are new to the command line though and there were some cool features (eg highlight search phrases from grep). But most of that stuff is just emphasising stuff you'd learn to spot anyway, after using the CLI for years.
So as cool as it is, I really would find it more of a hindrance than a help.
I can see how the colours and suggestions are great to those who are new to the command line though and there were some cool features (eg highlight search phrases from grep). But most of that stuff is just emphasising stuff you'd learn to spot anyway, after using the CLI for years.
So as cool as it is, I really would find it more of a hindrance than a help.
Fish is not a POSIX shell. For example, instead of $? there is $status.
I'm not familiar with fish, but highlighting search phrases from grep is a standard grep option (`--color`, or `--color=auto`)
You can get fish syntax highlighting in zsh by installing zsh-syntax-highlighting ( https://github.com/zsh-users/zsh-syntax-highlighting ). I prefer just enabling it in prezto though (which is a fork of oh-my-zsh that is a lot lighter weight and more modular https://github.com/sorin-ionescu/prezto )
I'd just like to second this. Though bear in mind that many things assume you're running bash on OS X, e.g. the homebrew installation one-liner doesn't work with fish.
Also, note that you can easily copy across your bash settings using:
/usr/local/share/fish/tools/import_bash_settings.py < ~/.bashrc
(from http://ridiculousfish.com/shell/faq.html )
Also, note that you can easily copy across your bash settings using:
/usr/local/share/fish/tools/import_bash_settings.py < ~/.bashrc
(from http://ridiculousfish.com/shell/faq.html )
Yet another article proclaiming bash as garbage and zsh as the best thing since sliced bread.
He did put it in a 'mild enough' way though.
What shell are you using? Probably bash, right? Well, stop it. Or don’t. Just know why you’re using the shell that you have.
I'm a bash user myself. I've tried zshell but didn't stick with it.
What shell are you using? Probably bash, right? Well, stop it. Or don’t. Just know why you’re using the shell that you have.
I'm a bash user myself. I've tried zshell but didn't stick with it.
I used bash for years, I was just forced into zsh at work and loved it.
Bash is fine, but I didn't know any of its intricacies. I'm not saying don't use bash. I'm saying don't use bash without learning about how to make it work for you (and probably trying other things).
Bash is fine, but I didn't know any of its intricacies. I'm not saying don't use bash. I'm saying don't use bash without learning about how to make it work for you (and probably trying other things).
Bash is ugly and horrible but I know it well and have bad Stockholm syndrome so it's too late.
Meh. I use bash on my laptop and zsh on my VM, and barely notice a difference between the two other than my different prompt. That tells me I'm not getting the most out of it, but it also tells me that the out-of-the-box improvements are pretty minimal. Given how many machines I need to attempt to keep my customizations in sync across (git is barely an option, let alone something like dropbox - this is inside a PCI Level 1 environment), stuff that requires a ton of plugins to really be useful is typically more trouble than its worth. Simply managing my SSH keys is bad enough.
I'm in exactly the same boat as you (except we're at PCI level 2).
tmux on my local machine does me fine. And as loading tmux inside of tmux is pointless, I don't need to copy configs across.
though what I do have is a number of cheat sheets for each type of server, so I have copy and paste code (most of it is simple enough stuff, but sometimes having a visual reminder is helpful when you're up against tight, stressful, deadlines)
tmux on my local machine does me fine. And as loading tmux inside of tmux is pointless, I don't need to copy configs across.
though what I do have is a number of cheat sheets for each type of server, so I have copy and paste code (most of it is simple enough stuff, but sometimes having a visual reminder is helpful when you're up against tight, stressful, deadlines)
My thoughts exactly. Everything mentioned there is just as doable in bash.
He referred readers to the Wikipedia comparison page, so I went there and duly compared bash to zsh in all the comparison tables.
A couple of minor differences, otherwise exactly the same...
A couple of minor differences, otherwise exactly the same...
The biggest features I use from zsh is awesome tab completion. For example, partial tab completion:
$ ls
./
../
project-foo/
project-bar/
$ cd foo <tab> ----> cd project-foo
$ cd /ho/wti/Drop <tab> ----> cd /home/wting/Dropbox
$ cd /tpm/blh <tab> ----> cd /tmp/blah
The prompt style I use was invented, IIRC, by one of the Bell Labs Unix guys in the early days of windowing terminals.
: text;
Why? Because you can select entire lines (triple-click in most terminal emulators) and paste them directly into another shell. “:” is equivalent to true(1), and it ignores its arguments, the text.
(In my case, the text is the base of the host name, but anything compatible with shell quoting rules will work.)
: text;
Why? Because you can select entire lines (triple-click in most terminal emulators) and paste them directly into another shell. “:” is equivalent to true(1), and it ignores its arguments, the text.
(In my case, the text is the base of the host name, but anything compatible with shell quoting rules will work.)
> The prompt style I use was invented, IIRC, by one of the Bell Labs Unix guys in the early days of windowing terminals.
: text;
My prompt is two lines. The first line is info line followed by $ prompt on the next line. If I were so inclined, I would simply change the $ to ; or blank. I don't have to choose only one of them, but if that were the case, the verbose prompt would have stayed and ; would have gotten the boot.
My prompt is two lines. The first line is info line followed by $ prompt on the next line. If I were so inclined, I would simply change the $ to ; or blank. I don't have to choose only one of them, but if that were the case, the verbose prompt would have stayed and ; would have gotten the boot.
This is the best post in the thread so far. I use ";" as a prompt sometimes, because it makes copy-paste easy (like you mention, just triple-click), but I often like to keep track of what directory I'm in. I typically just leave my prompt alone because I work on so many different machines, but this is pretty slick and simple.
That's another neat trick I found useful - add a seperator between your commands: http://lifehacker.com/5840450/add-a-handy-separator-between-...
Anyone have something similar for zsh? I can't seem to get it to work with my current prompt.
http://pastie.org/5456546
http://pastie.org/5456546
Just spent some time putting some Star Wars in my terminal greeting. In case anyone is interested, I threw a .sh and .txt up at github :)
https://github.com/loeschg/ascii-art
https://github.com/loeschg/ascii-art
You could kick that up a notch with something I just threw together. http://npmjs.org/motd :)
This is more of a git tip... but you should probably change your "ggpnp" alias to use "pull --rebase" instead of "pull" to avoid an unnecessary merge commit in your history.
I also spend most of my time in the terminal, but actually quit little in the shell.
Most of my time I'm in Vim, editing code, so most of the configuration is there (though I keep it down to ~ 50 lines), minor tweaks now and then.
my vimrc: http://ubuntuone.com/4wmrwsU64KEgj9S0zEH3Ct
My latest configuration add-on is syncing my config files when they change. I just do a hardlink (same inode) to my Ubuntu One folder (on system setup). Now if I change a configuration, it get's synced to my all my other devices when they are next online.
I found that quite useful. Syncing vimrc, gitconfig, vimprojects and some other. Basically only use my machines as cache. With this I can get up to be productive with a new installation very quickly and work with several machines without configuration miss-match headache.
For sources I use git push to a remote server (+ U1 for convenience, but it's inconsistent while syncing multiple files, so bad for push target).
Most of my time I'm in Vim, editing code, so most of the configuration is there (though I keep it down to ~ 50 lines), minor tweaks now and then.
my vimrc: http://ubuntuone.com/4wmrwsU64KEgj9S0zEH3Ct
My latest configuration add-on is syncing my config files when they change. I just do a hardlink (same inode) to my Ubuntu One folder (on system setup). Now if I change a configuration, it get's synced to my all my other devices when they are next online.
I found that quite useful. Syncing vimrc, gitconfig, vimprojects and some other. Basically only use my machines as cache. With this I can get up to be productive with a new installation very quickly and work with several machines without configuration miss-match headache.
For sources I use git push to a remote server (+ U1 for convenience, but it's inconsistent while syncing multiple files, so bad for push target).
Whatever the terminal you are using, configure it so that it doesn't eat your alt/ctrl key and then learn readline bindings.
Kinda weird that the author mentions Ctrl-R but not readline. History searching actually works for everything that supports readline, e.g. bash, ipython, psql, henplus, etc, although personally I use page-up / page-down with:
"\e[5~": history-search-backward
"\e[6~": history-search-forward
> I use page-up / page-down with
I use ctrl-r because it is easier to type.
> experience becomes crappy when there is no readline support, e.g. everything on Windows, sqlplus, db2, etc.
If you have rlwrap, you can generally do `rlwrap -r app-that-doesn't-play-well`
I use ctrl-r because it is easier to type.
> experience becomes crappy when there is no readline support, e.g. everything on Windows, sqlplus, db2, etc.
If you have rlwrap, you can generally do `rlwrap -r app-that-doesn't-play-well`
In my scenario, I have to work on several tabs and splits for one topic/work (say it's Python work), and I usually have 2-3 topics in a day (office related, playing around, and maybe side-project stuff). I'm using tmux, and I tend to have 2-3 tabs for each topic, using only tmux to manage them is painful and ugly: there's too many tabs in the current display, and the default gnome terminal doesn't mix with the looks of everything else. So I'm using urxvt to manage the tabs, it's fast (sometimes I love verbosity), it can handle tabs beautifully, highly customizable, and the default shortcuts are good.
> using only tmux to manage them is painful and ugly:
How is using tmux to manage them is painful?
How is using tmux to manage them is painful?
I'm wondering that too. Tmux enables a hell of a lot more than just panes/windows, and looks pretty spiffy while doing it I think. A terminal with no menubars or chrome with tmux inside it is the most elegant, adaptable, and capable configuration I've ever had the pleasure to use.
If say I have 2 topics with 3 tabs each, and I want to switch to different topic, I need to move to the 4th tab either by switching tab few times, or knowing the index of the tab to get a faster shortcut. Both, in my opinion, are not simple.
If I combine tmux with urxvt, I can have 3 tmux tabs in a urxvt tab, and another 3 tmux tabs in second urxvt tab, and I can switch context just by pressit shift+left/right, I can also easily realign context with ctrl+left/right.
tmux is awesome, but in my case, it's not so awesome when I have to handle many tabs with totally different context, which is why I combined it with urxvt.
If I combine tmux with urxvt, I can have 3 tmux tabs in a urxvt tab, and another 3 tmux tabs in second urxvt tab, and I can switch context just by pressit shift+left/right, I can also easily realign context with ctrl+left/right.
tmux is awesome, but in my case, it's not so awesome when I have to handle many tabs with totally different context, which is why I combined it with urxvt.
> If I combine tmux with urxvt, I can have 3 tmux tabs in a urxvt tab, and another 3 tmux tabs in second urxvt tab, and I can switch context just by pressit shift+left/right, I can also easily realign context with ctrl+left/right.
I see what you mean. Generally I open a new urxvt/terminator for a new grouping. A rails project is in its own terminal, a django project in another.
> I need to move to the 4th tab either by switching tab few times, or knowing the index of the tab to get a faster shortcut. Both, in my opinion, are not simple.
I have this in my conf:
unbind '"' bind '"' choose-window
I generally have more than 10 tmux windows open. Either I know which index is which(rails project - 0 is vim, 1 is server, 2 is console, 3 is dbconsole, 4 is tail logs, 5 is for running tests...), or I select the windows. Switching tabs few times isn't an ideal way to switch to the desired window.
> which is why I combined it with urxvt.
urxvt has tabs? Mine doesn't. Anyway I have moved to terminator. I find it easier to configure(the pains I took to configure urxvt for copy-paste), performant and standard compliant.
I see what you mean. Generally I open a new urxvt/terminator for a new grouping. A rails project is in its own terminal, a django project in another.
> I need to move to the 4th tab either by switching tab few times, or knowing the index of the tab to get a faster shortcut. Both, in my opinion, are not simple.
I have this in my conf:
unbind '"' bind '"' choose-window
I generally have more than 10 tmux windows open. Either I know which index is which(rails project - 0 is vim, 1 is server, 2 is console, 3 is dbconsole, 4 is tail logs, 5 is for running tests...), or I select the windows. Switching tabs few times isn't an ideal way to switch to the desired window.
> which is why I combined it with urxvt.
urxvt has tabs? Mine doesn't. Anyway I have moved to terminator. I find it easier to configure(the pains I took to configure urxvt for copy-paste), performant and standard compliant.
tmux turns scrollback from "pretty simple" on a stock xterm or other terminal, to "absolute goddamn bullshit". That, combined with the fact that I quite like using "^b" to move my cursor around, means I don't use tmux as much as I possibly should. Yes, I know I could fix the ^b problem in a config file, but as I've said elsewhere, I work on about 6 different machines on a regular basis and don't have the patience to mess around syncing my configs.
> tmux turns scrollback from "pretty simple" on a stock xterm or other terminal, to "absolute goddamn bullshit"
tmux(and screen) scrollback is absolutely fantastic. Navigate with keyboard(and not just page-up page-down), have vim or emacs bindings, search backward...
> I work on about 6 different machines on a regular basis and don't have the patience to mess around syncing my configs.
As I said elsewhere, it takes about 2 minutes to copy ssh keys and scp dotfiles.
tmux(and screen) scrollback is absolutely fantastic. Navigate with keyboard(and not just page-up page-down), have vim or emacs bindings, search backward...
> I work on about 6 different machines on a regular basis and don't have the patience to mess around syncing my configs.
As I said elsewhere, it takes about 2 minutes to copy ssh keys and scp dotfiles.
I wrote a little script to display the battery status (in a nice format) that should work on Bash & ZSH. I use it on my Tmux bar too...
Check it out :)
https://github.com/Goles/Battery
Check it out :)
https://github.com/Goles/Battery
Would have loved it, if worked on linux too.
You can always pull request on it.
Linux support is on the roadmap, I would need some beta-testers though
Linux support is on the roadmap, I would need some beta-testers though
You can check Linux battery status by just reading from a certain file somewhere under /proc; being Linux, I'm certain there's an equivalent buried somewhere in /sys as well. You just read the file, it gives you back ASCII text, you're all set.
Will add Linux support asap :)
There's also `acpi -b`, which I think is available on most linux distros.
It's not necessarily installed by default, though. If your Linux system can read the battery with acpi, it will show up in /sys. Although the 'acpi' program is convenient, it adds another dependency. Also, if you run 'acpi' under strace, you'll see that it just opens up /sys/class/power_supply and parses files under that.
I'm going to plug a small CLI program I maintain -- autojump: https://github.com/joelthelion/autojump/#name
It tracks which directories used most often so you can simply use `j <dir>` to jump to that directory rather than type / tab-complete the full path name. It also does some fuzzy matching for mistyped names. For example:
It tracks which directories used most often so you can simply use `j <dir>` to jump to that directory rather than type / tab-complete the full path name. It also does some fuzzy matching for mistyped names. For example:
~ $ j au
~/code/autojump $ j donw
~/Download $ j scra
/scratch/03158/wting $This plugin is great. I'd definitely recommend others to check it out. It's been a boon to my productivity since I've discovered it.
"Art for Art’s sake is an empty phrase. Art for the sake of code, art for the sake of the terminal and the OS, that is the faith I am searching for." - Salvador Dali
"While $HISTORY is great, it only retails a certain amount of data."
Unless you have HISTSIZE=100000000; SAVEHIST=100000000 or some such nonsense (-hides-). Using Ctrl-R for history doesn't seem to be slowed down at all by my huge histfile. There are privacy implications if you're hacked/subpoenaed, but it's hella convenient.
Unless you have HISTSIZE=100000000; SAVEHIST=100000000 or some such nonsense (-hides-). Using Ctrl-R for history doesn't seem to be slowed down at all by my huge histfile. There are privacy implications if you're hacked/subpoenaed, but it's hella convenient.
You're probably aware of it, but anyway... Put
http://serverfault.com/q/48769
http://serverfault.com/q/241154
HISTCONTROL='ignoreboth:erasedups'
http://serverfault.com/q/48769
http://serverfault.com/q/241154
Mine is set _somewhat_ ridiculously large. Just not that large. And it seems like it just gets to be obscene at some point.
I'm maniac with this so called system configuration. Just take a look on my _.vimrc_, for example. :)
https://github.com/daGrevis/Dotfiles
P.S. If you start to change dotfiles yourself, you won't be able to stop.
https://github.com/daGrevis/Dotfiles
P.S. If you start to change dotfiles yourself, you won't be able to stop.
Nice guide.
For those on Windows, just move to Powershell if you are still using the plain old terminal.
Sure it can be a bit verbose, but it is surely way better, specially for the cases when doing Windows specific projects.
For those on Windows, just move to Powershell if you are still using the plain old terminal.
Sure it can be a bit verbose, but it is surely way better, specially for the cases when doing Windows specific projects.
Second to this, I don't recommend using the built-in script editor. It's slow as all hell and not that helpful when learning how to write your first scripts. Instead, I recommend the Script Editor that comes with PowerGUI. It has IntelliSense (sort of), which is kind of a crutch in the beginning but displays the sheer amount of power Powershell has.
prezto [1] is a nice alternative to oh-my-zsh. I find it to be faster and it's more modular.
[1] - https://github.com/sorin-ionescu/prezto
[1] - https://github.com/sorin-ionescu/prezto
Is it working properly now? Last time I've tried it I had to go back to oh-my-zsh because prezto screwed my terminal.
By the way, one of these days debugging the slow startup time of oh-my-zsh I found the culprit, virtualenvwrapper. Again I didn't have the time to good deep into that, so I just edited out that line from my .zshrc.
By the way, one of these days debugging the slow startup time of oh-my-zsh I found the culprit, virtualenvwrapper. Again I didn't have the time to good deep into that, so I just edited out that line from my .zshrc.
Seems to be using properly for me. I've been using it for a month now and I didn't have any issues with it. But that may be because I'm only using the basic plugins which are enabled by default, nothing fancy.
EDIT: I'm using urxvt btw
EDIT: I'm using urxvt btw
Be sure to read the documentation when installing zprezto on OSX. If you don't run the following, your PATH will be screwed up.
sudo chmod ugo-x /usr/libexec/path_helper
sudo chmod ugo-x /usr/libexec/path_helper
I typically SSH into my boxes, but it isn't really a shell - you don't have dynamic fonts/colors per application and stuck to 256 colors.
Maybe I will have to run a linux distro in order to share the love.
Maybe I will have to run a linux distro in order to share the love.
Actually, applications can control colors in the same way over SSH as they can on a local distro.
So, would my SSH client just map the colors to the closest available one in its' palette?
I'm kind of naive - I figured every application run within command line (not terminal) was restricted to a specific 256 palette.
I'm kind of naive - I figured every application run within command line (not terminal) was restricted to a specific 256 palette.
SSH doesn't care about colours. You can use the colours of whatever terminal emulator you're using.
I am just starting out and what to learn how to get the most out of my terminal. I have zsh installed what is the best site/book in learning how to unlock its full power?
I would recommend getting used to BASH first if you're just starting out. Some people here are zsh zealots, but if you plan to work on remote systems, you're going to encounter BASH. You'll also appreciate whatever fancy benefits zsh offers more.
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html
A good start for leveraging common bash features. You'll find a lot of the ckncepts , if not syntax, useful in any *sh
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html
A good start for leveraging common bash features. You'll find a lot of the ckncepts , if not syntax, useful in any *sh
brilliant. Thank you
Get crazy with your colors too, random and fashionable vim/emacs/textmate themes here:
http://sweyla.com/themes/
The best prompt I've found for zsh is agnoster. I highly recommend it: https://gist.github.com/3712874
Here's a fun tip: If you want to have an awesome lightening bolt (⚡) instead of a boring $ in your prompt, put this in your PS1 environment variable:
`echo -e "\xE2\x9A\xA1\x03"`
`echo -e "\xE2\x9A\xA1\x03"`
I am curious what terminal people use on Windows. I find MSYS to be very good, since it lets me work just as I would on Linux with Emacs-style editing.
Besides Console2 mentioned in another comment, there is also ConEmu (https://code.google.com/p/conemu-maximus5/), which incidentally has support for Clink (again mentioned in another comment!)
PS: There is also a somewhat extended version of Console2 here by a different author: https://github.com/cbucher/console which I like.
PS: There is also a somewhat extended version of Console2 here by a different author: https://github.com/cbucher/console which I like.
I'm using Console2 (http://www.hanselman.com/blog/Console2ABetterWindowsCommandP...) and Powershell. Not as nice as a real Linux environment, but Console2 has tabs which makes it bearable.
Cygwin, with mintty and all the trimmings.
Or Clink - https://code.google.com/p/clink/
Or Clink - https://code.google.com/p/clink/
I use cygwin with screen (no tmux on windows sadly), vim, and a smattering of grep/sed/awk/etc.
I so dearly wish I didn't have to.
use tmux for multiple screens and ditch that xorg garbage.
Calling Xorg garbage is naive.
Even if you only use terminals, and you have to have a framebuffer that supports that native resolution of your screen, you'll find that Xorg is nearly always more performant.
If you have issues with X11's security model that's a different story, I'd suggest trying http://wayland.freedesktop.org/
Even if you only use terminals, and you have to have a framebuffer that supports that native resolution of your screen, you'll find that Xorg is nearly always more performant.
If you have issues with X11's security model that's a different story, I'd suggest trying http://wayland.freedesktop.org/
Could someone elaborate how x11/xterm compares to iTerm2? I've been using tmux in iTerm. After reading this discussion, i installed x11 and quartz-wm. Why would I switch to X11 ?
(I do notice that within tmux on iterm, i can use the mouse for selection (using Alt), but the mouse does not work in tmux in xterm.)
(I do notice that within tmux on iterm, i can use the mouse for selection (using Alt), but the mouse does not work in tmux in xterm.)
Using tmux in an X terminal emulator really gets you the best of all worlds. Good mouse support, performant as you mention, and if X really starts to give you hassle for some reason you can always seamlessly continue working in a VT or with putty if you really want to.
> use tmux for multiple screens and ditch that xorg garbage.
tmux for multiple screens instead of Xorg garbage? I think you don't know what Xorg is.
That doesn't make any sense. If you are referring to the screenshot, that's gnome-terminal's tabs.
tmux for multiple screens instead of Xorg garbage? I think you don't know what Xorg is.
That doesn't make any sense. If you are referring to the screenshot, that's gnome-terminal's tabs.
These days II mostly use tmux windows/panes instead of yakuake, but yakuake is still useful)terminal dropdown/retract or when my copy/paste breaks in tmux again(doesn't work well with mouse options).
I don't understand why I'd want to use tmux locally. I'm a huge believer in tmux on remote machines though. Why would I want to use it on my local laptop?
In addition to the obvious multiplexing/windowing/paning, I find it great for creating named "work sessions". I have a short script that creates or attaches (with zsh autocompletion in the case of attaching) tmux sessions while creating a standardized filesystem tree that I use for units of "work", checking out things I need, etc.
This allows me to basically just type at any point `work foobar` and I'll either have a clean slate to start working on foobar, or I will be dropped into an existing tmux session 'foobar' that is exactly where I left off last time. Same 'tail -f'/'watch'es, same Vim sessions, same everything.
Besides regular units of work I usually keep a tmux session around just for database connections or the like, and another for messing around with environment stuff (dotfiles, ~/bin/, etc).
Most of this organization is stuff I used to do with virtual desktops, but I find tmux is wildly better suited for it.
This allows me to basically just type at any point `work foobar` and I'll either have a clean slate to start working on foobar, or I will be dropped into an existing tmux session 'foobar' that is exactly where I left off last time. Same 'tail -f'/'watch'es, same Vim sessions, same everything.
Besides regular units of work I usually keep a tmux session around just for database connections or the like, and another for messing around with environment stuff (dotfiles, ~/bin/, etc).
Most of this organization is stuff I used to do with virtual desktops, but I find tmux is wildly better suited for it.
Assuming you spend a lot of time in terminals, you can use it to group your tasks. For example I have tmux sessions for my bachelor's thesis which contains two windows, either of which contains two split panes. The left pane is for vim (which are split further) and the right pane are for ghci and terminal. If I change from writing the thesis to for example doing work I can just change the tmux session. The layout and content are just like I left them.
Say I am working on a rails project. I need vim open with root; I need rails server, console, dbconsole; I need one window at project root for misc task; and I prefer not to navigate with the mouse to different tabs. Personally, I vastly prefer tmux terminal multiplexing over terminal tabs.
Also, it doesn't happen frequently, but I have closed terminals which I didn't mean to. tmux/screen means that causes only minor inconvenience, compared to closing the terminal, opening it again, opening all tabs, dealing with swap files, re-running servers, dbconsoles etc.
Also, it doesn't happen frequently, but I have closed terminals which I didn't mean to. tmux/screen means that causes only minor inconvenience, compared to closing the terminal, opening it again, opening all tabs, dealing with swap files, re-running servers, dbconsoles etc.
I've only ever seen people advocate for tmux locally who can't (or don't want to) run something like xmonad as their window manager.
I would recommend a primarily tmux-based workflow unless you use a number of graphical programs that benefit greatly from the tiling paradigm.
I used to use Xmonad with tmux (and still do sometimes). I primarily use Unity with tmux now. I came to the realization that tmux had nearly nullified my need for a tiling window manager after I switched from gVim to terminal vim and noticing how much easier it made my workflow. My "ah ha" moment was the discovery of the distinction between sessions, windows, and panes and how each could interact with (or sometimes transform into) the each other.
I used to use Xmonad with tmux (and still do sometimes). I primarily use Unity with tmux now. I came to the realization that tmux had nearly nullified my need for a tiling window manager after I switched from gVim to terminal vim and noticing how much easier it made my workflow. My "ah ha" moment was the discovery of the distinction between sessions, windows, and panes and how each could interact with (or sometimes transform into) the each other.
I'm a xmonad user and I use tmux. I agree that they both provide similar benefits, but the killer benefit for tmux is the persistence. I can have n sessions open and it's still easy to switch between them. Just disconnect the old one and attach to the new one. With xmonad you would either need to have many topic spaces (and recompile config when you want new one) or close the old ones
It can be useful to be able to open vertical splits running things like "watch jslint" or "watch rspec" while you code.
that first screenshot is actually just pulled from the internet. the third one (it was broken at first, then I fixed it) is from my laptop.
My desktop, however, doesn't use tmux right now. May be something that I look into in the near future because it looks interesting.
My desktop, however, doesn't use tmux right now. May be something that I look into in the near future because it looks interesting.
Since you're on osx, you might look into iTerm2, which wraps tmux nicely and brings a few bells and whistles to the table.
tmux and Xorg don't even begin to attempt to try to solve the same kinds of problems.
This particular post is about getting my terminal perfect for me. I've been using these settings for about a week and I can feel everything getting easier. Most of my work that isn't answering emails and going to meetings involves me using a terminal. Between vim and a set of zsh commands, my terminal becomes my best friend.