Live data from Hacker News

OS X Command Line Utilities

mitchchn.me

191–200 of 243 posts

Re: OS X Command Line Utilities

#191

This was supposed to be few lines of remarks. It expanded quickly in relation with my enthusiasm for this topic. I've been investing some time in the command line on my Mac. I am moving from a dilettante going to the shell on a per-need basis to a more seasoned terminal native. It pays off handesomely! It's hard to convey how nice it to have to have a keyboard-based unified environment instead of a series of disjoine…

I have my current git branch display as part of my command prompt when I'm in a project directory. parse_git_branch() { git branch 2> /dev/null | sed -e '/^[^ ]/d' -e 's/ \(.*\)/(\1)/' } export PS1="\u@\h \[\033[32m\]\$(parse_git_branch)\[\033[00m\] \W $ "

You might want __git_ps1. Similar idea, but more functionality & maintained by someone else!

Re: OS X Command Line Utilities

#192
post #178
post #157

Earlier quoted context omitted.

It doesn't seem to work properly. It doesn't pick up my .bashrc, it doesn't have colors, etc.

Where did you find a GUI Emacs that doesn't have colors? I use http://emacsforosx.com . To set a color theme: M-x customize-themes. You might want/need to install more themes, you can do that with the package manager (M-x package-list-packages) If you want your ~/.profile to be sourced, a quick fix is to open the GUI app from the command line. Apps launched by finder don't source your profile.

my emacs does have colors. It's M-x shell that doesn't have colors.

And this goes to the point of why emacs users like myself use iTerm. Because it works. The only thing I had to setup in iTerm was my color scheme. And even that wasn't required! (iTerm is launched by finder and finds my profile just fine.)

Re: OS X Command Line Utilities

#193
Why the hell would someone change the title from "Eight Terminal Utilities Every OS X Command Line User Should Know" to "OS X Command Line Utilities".

The original title is clearly more accurate / useful / canonical. The overwritten title is ambiguous. This is indeed not a list of every OS X command line utility.

Re: OS X Command Line Utilities

#194
post #90

Earlier quoted context omitted.

> Go fullscreen. Not so much for the real estate but for the mental switch. Fullscreen mode is a way to immerse yourself into your productive development world. No browser, no mail, no application notification. Only code. This is an excellent point and one that's not nearly as appreciated as it should be. Fullscreen mode was written off in Lion as an example of Apple dumbing down the platform and making it more like…

I use sizeup[1] to maximize the terminal (or any other app) with a keystroke, instead of native full screen. It works across all applications that allow window resizing, and has handy shortcuts for "half" full screen, which is great to position, say, a browser and editor next to each other across the whole screen. Which reminds me, I really will go and pay my 13 bucks for it now, it's more than worth it. But the free…

Sounds very similar to Spectacle [1] which is open-source with a github repo [2].

[1] http://spectacleapp.com/ [2] https://github.com/eczarny/spectacle

Re: OS X Command Line Utilities

#195
post #73

This was supposed to be few lines of remarks. It expanded quickly in relation with my enthusiasm for this topic. I've been investing some time in the command line on my Mac. I am moving from a dilettante going to the shell on a per-need basis to a more seasoned terminal native. It pays off handesomely! It's hard to convey how nice it to have to have a keyboard-based unified environment instead of a series of disjoine…

Don't need symlinks. Just set the CDPATH environment variable! Also set up case insensitive completion, saves the extra shift press for all those Mac paths.

Be careful with CDPATH, it can result in some mind-boggling build script bugs.

Re: OS X Command Line Utilities

#196

Earlier quoted context omitted.

Look into getting Emacs in one of its native OS X incarnations rather than using it in the terminal. Emacs is going to have a lot more options for colors (font locking is the Emacs-speak, I think) in its own app than when it's boxed into a terminal. You also get support for multiple "frames" (windows); Vim can't do this at all and I still miss that from Emacs. I use Linux rather than OS X but if you are parked in Ema…

unless you are remote, then the terminal emacs + tmux are a good combo.

emacs in daemon mode can manage both tty and window manager sessions, and lately, it's started working on OS X! I build git HEAD every week or so and this feature is fantastic. I can ssh into my main work machine and be right back in ENSIME where I was when I left off.

Re: OS X Command Line Utilities

#197

Earlier quoted context omitted.

Ctrl + Shift + Eject or Ctrl + Shift + Power (on MacBook Pro's that don't have an eject key) Cmd + Shift + Eject doesn't do anything.

This sleeps/suspends rather than just locking. Equivalent to closing your MacBook.

Doesn't change the fact that cmd+shift+eject doesn't actually do anything (unless it's on an older version of OSX)

Re: OS X Command Line Utilities

#199
post #158

Earlier quoted context omitted.

A frame in Emacs terminology is actually a top-level window.

So MacVim does have this functionality then, yes? You can have multiple top-level windows, each having multiple tabs, each having multiple splits.

I was curious so i just tested this to see if it did. It does not. Yes you can have multiple tabs and splits, but in emacs each frame shares the same buffer list as well.

Re: OS X Command Line Utilities

#200

Earlier quoted context omitted.

Vim can absolutely do multiple "frames". They're called splits.

No, it cannot. An Emacs "frame" is a separate editor window, managed by the window manager. Different Emacs frames running the same Emacs session talk to each other--they share the buffer list, etc. Within the Emacs "frame" you can have split "windows". One Vim session can live only in one window that is managed by the system window manager. You cannot have multiple windows that talk to each other. You can split a si…

Although it is not exactly the same, what you can do is start a `screen' session (which can be split with ^a S), and then split your `vi' instances.
Post reply on HN