Hacker News new | comments | show | ask | jobs | submit login

Can someone explain to me what exactly is wrong with the OS X terminal?

For me it was a combination of things. For one, I use emacs and a Norwegian keyboard layout, and Apple handily ensures that '\' is only possible to type using both shift, option and 7. Now, since I'm an emacs user, typing meta+\ should mean command+option+shift+7. As if that wasn't bad enough, I never found a way to configure neither Terminal.app nor iTerm2 or whatever it's called such that I could get both option functionality and a meta key (perhaps this has been fixed later? been a couple years), so when ssh-ing I had to use esc, then option+shift+7.

Combine this with how difficult it is to get a real dev environment set up, on debian-based systems you just apt-get install build-essential etc., similarly on Arch Linux, whereas on a Mac it was installing that whole XCode from a CD which included a bunch of stuff I never needed, then waiting for hours for macports to compile gcc etc. (I never understood why macports didn't go with precompiled binaries, mac's are so uniform compared to linuxes it should be _easier_, shouldn't it?). And then waiting for hours every time gcc etc. got an update, thinking "I thought I did this already, what is this, gentoo?" And the annoyance of having to install GNU sed and ensure it was before OS X sed in PATH because OS X sed was horribly slow on certain regexes (I think they had a \1 in them, can't remember), it felt so … inelegant.

And most of the projects I use and like working on just seemed to have better Linux support; of course I could rant about how OS X is a POSIX too and they should support it just as well as Linux, but, well, I chose convenience. For the sake of my fingers and my patience.

use an english keyboard, problem solved :o). I know, there are special keys ( I am german and we have special keys too). But that is solved with a handy tool named ukelele, that allows to change keyboard profiles. Very useful. Have you ever seen such a thing on linux?

It's been a while since I used it, but off the top of my head:

- colors never worked right, you can certainly enable them but themes like solarized are impossible to get working.

- it took forever to open. as in, a terminal on my machine is just a keypress away and it took the terminal on my osx machine a couple seconds to open a window, and even longer to show me a prompt

- somehow they borked mouse input, so clicking the line you want to edit from within a vim session, for example, is a no-go.

- this is a lion problem but terminal interacts with it especially badly, there's no easy way to open a second terminal window. I usually have tons of the things open and it's impossible to manage them properly.

Re: Delay on terminal - Yes, well known (and annoying) problem in OS X. It isn't actually a terminal issue but a log processing PITA. See: http://osxdaily.com/2010/05/06/speed-up-a-slow-terminal-by-c...

But, basically, sudo rm -rf /private/var/log/asl/*.asl fixes it.

I live in Terminal.app - usually have 15-20 tabs open all day long - so little tweaks like that (saving 2 seconds each time you open a new window) makes a big difference.

Hmm I faced some of the same problems:

- Colors work perfect with the tomorrow theme, kinda similar to solarized (https://github.com/chriskempson/tomorrow-theme/tree/master/O...)

- I think I changed my shell to /bin/bash in the preferences, which fixed it

- Haven't encountered this

- Haven't encountered this

It's my understanding that bash has been the default shell in OSX for quite some time now, though I can't imagine tcsh started noticeably slower than it back when it was the default. On my incredibly underpowered machine the difference between the two is around 0.05s.

Might i suggest trying iterm 2


Problem #2 can be addressed with this.

touch ~/.hushlogin

Yeah - I've tried that in the past:

  mbf041:~ shephard$ ls -lart ~/.hushlogin
  -rw-r--r--  1 shephard  staff  0 Apr 23 21:36  /Users/shephard/.hushlogin
  mbf041:~ shephard$ 
But it still didn't help. I ended up having to sudo rm -rf /private/var/log/asl/*.asl to fix it on my system.

Never seen any of these.

One thing I don't like is you can't completely clear the scrollback, only the visible portion. I often use 'tput reset' when doing new build/test runs and it is nice when the scrollback only contains this time's output.

Cmd + k clears scrollback how you want. If you want to script it, you can use osascript: http://apple.stackexchange.com/questions/31872/how-do-i-rese... Yeah, it's hacky.

It's a usability trade-off. Defaulting to allow scripts to erase all your scrollback would be pretty annoying in a lot of cases. Ideally there would be a checkbox for this behavior, but Apple doesn't like config options.

One thing I wish terminals had was a "scroll up to the last place I typed something." I think that would solve your problem as well.

They are my scripts and I don't need "protection" from myself. Users don't use the command line so it isn't particular relevant to them - this is relevant to developers.

I fully agree it shouldn't be an option, and that generally being highly configurable is a way of abdicating responsibility for making the right choices in the first place, and ensures that not everything is tested (there will be too many combinations of settings).

In this particular case I just think Apple chose the wrong behaviour.

The few times I had to use it, I could not figure out how to turn off the chrome, though I suppose that is more of a general OSX complaint.

Otherwise, color support at least used to be dreadful. I believe this has been fixed recently though?

I think it still doesn't have proper mouse support though. Seems like a silly thing to have/want, but I find it very nice for resizing/focusing tmux panes/Vim windows, and scrolling in both.

Terminal.app often feels sort of clunky to me. I use iTerm2 instead--being able to split panes is really nice (no, I don't want to use tmux).

The default userland is kind of annoying, in that a lot of utilities are BSD ones and aren't compatible with my imported-from-Linux scripts, aliases, etc., but that's just an install of coreutils away.

By the way, if you want to get the benefits of tmux with respect to attach, detach, but want to manage splits and tabs using the Terminal, iTerm2 has you covered:


It does, but I'm still not a fan. I find its attach/detach on remote servers a little wonky.

Yeah, I get annoyed too when people use Linuxisms in scripts because they don't ever run right on FreeBSD.

"ls --color=auto" is not what I consider a "Linuxism", it's what I consider "basic functionality" (and yes I'm quite aware of BSD ls's -G, but it doesn't honor my other custom settings). I have no interest in rewriting all of my rc files and scripts to support BSD tools because doing so is a significant investment of time better spent elsewhere, moreso because of the simpler, easier option of installing GNU coreutils and findutils.

I'm glad you could migrate your snark from Reddit, but it doesn't do a lot for a real conversation.

So what's wrong with it is that it feels clunky to you...

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact