Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OS X Command Line Utilities

mitchchn.me

Post reply on HN
Print view View original

221–230 of 243 posts

Re: OS X Command Line Utilities

#221

Post by dilap »

nmc wrote: post #12

/usr/local is the default location for user-installed stuff, but I personally like to have my package manager do its stuff in a separate directory. I like the way Fink [1] uses the /sw (software) directory. Does anyone have a valuable opinion on the comparison between Fink and Homebrew — or maybe MacPorts? [1] http://www.finkproject.org

I've used portage on Gentoo (a long, long time ago), yum a little bit on Fedora, apt-get a fair amount on debian (a long time ago) and on Ubuntu (a tiny bit, recently), the Cygwin gui package manager on windows (a medium-amount of time ago; shudder), and fink and macports on OS X (a medium-amount of time ago), and I will say this...

Homebrew is, by far, the most pleasant package manager I have ever used.

I couldn't even tell you why, but it's just nicely designed, and shit just tends to work. Part of it is that it targets a very well-defined system (MacOS), and it has an explicit aim to integrate with that system as well as possible. (I guess this could be true of e.g. apt on ubuntu, but ha ha ha.)

As an example, most package managers have some funky, one-off , more-or-less shitty way to update the packages list. Homebrew has...git! Which works great.

I highly recommend checking it out.

Another example: Most package managers say, "you're installing random software off the internet? Better give it root access!" Homebrew installs as the current user, no root access. Much saner default policy, IMO.

Or maybe you want to see a list of installed packages? "brew list". Oh, you wanted one-per-line, that's "brew list -1", just like ls.

Or maybe you want to install some software from a 3rd party repo? "brew tap $somewhere; brew install $something".

It's just a very thoughtful, well-made piece of software. Strongly recommend checking it out.

Re: OS X Command Line Utilities

#222

Post by dunham »

yangyang wrote: post #206
massysett wrote: post #187

Earlier quoted context omitted.

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…

You can also run Emacs as a daemon, and connect to it from both graphical and tty sessions. So you could ssh into your desktop and (with emacsclient), work with the same instance running on your X desktop.

I did this back in college with XEmacs (90's). I'd leave gnus running at school and open a new frame from home to check mail and news. (You can use this to have two people editing at once too, but you have to avoid avoid opening a minibuffer.)

Re: OS X Command Line Utilities

#223

Post by shurcooL »

If you do Go development, you can do this to quickly get to root folder of any Go package:

  function gocd {
      cd `go list -f '{{.Dir}}' $1`
  }
It uses the same syntax as go list to specify packages, so you can do, e.g.:

  ~ $ gocd .../markdownfmt
  markdownfmt $ pwd
  /Users/Dmitri/Dropbox/Work/2013/GoLand/src/github.com/shurcooL/markdownfmt
  markdownfmt $ _
So nice.

Re: OS X Command Line Utilities

#224

Post by pikachu_is_cool »

enneff wrote: post #63
pikachu_is_cool wrote: post #47

Earlier quoted context omitted.

On your Mac: ssh -R 19999:localhost:22 remote_host On the remote host: command_that_prints_stuff | ssh localhost -p 19999 pbcopy ________ The first command routes the port 19999 on the remote host to port 22 on the computer you're using. ssh part on the second command connects to 19999 (and thus 22 on your computer) and runs the pbcopy command in the current shell (which is the pipe from command_that_prints_stuff)

Why not just ssh remote_host command_that_prints_stuff | pbcopy ?

Depends on the situation, if you want to run a quick script then yours would be better. If you're spending a lot of time in remote_host then mine might make more sense.

Re: OS X Command Line Utilities

#225

Post by X-Istence »

AdamGibbins wrote: post #188
X-Istence wrote: post #176

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.

If you have your Mac set to never sleep/are using Caffeine for instance, then it simply puts the display to sleep, the rest of the computer keeps on humming along.

Not entirely equivalent to closing your MacBook.

Re: OS X Command Line Utilities

#226

Post by wilmoore »

Monkeyget wrote: post #54

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…

> Make a few symlinks from your home directory to the directories you use frequently. Instead of doing cd this/that/code/python/project/ you just do cd ~/project

If you are using ZSH, you can just append paths to the $cdpath environment variable. This will allow you to "cd name-of-project" (assuming you've added your project directory to $cdpath). No need for a mess of symlinks in this case.

Re: OS X Command Line Utilities

#227

Post by wilmoore »

Monkeyget wrote: post #116
gradstudent wrote: post #95

Earlier quoted context omitted.

Why split your terminal if you have screen / tmux?

iterm has special integration with tmux. The big advantage is that you can quickly scroll the history with the mouse which is way faster and more convenient that going back up screen by screen with a shortcut. Also with some work you can synchronize the OSX clipboard with tmux's one.

> The big advantage is that you can quickly scroll the history with the mouse...

I've not found that to be faster than or . Same keys as in vim. I haven't found the value in using iTerm over terminal + tmux (same could be said for those that are more comfortable in screen).

Re: OS X Command Line Utilities

#229

Post by wilmoore »

trusche wrote: post #90
mitchchn wrote: post #66

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…

+1 to this. I use CTRL+ALT+CMD+M many times per day.

Re: OS X Command Line Utilities

#230

Post by tlitd »

wilmoore wrote: post #226
Monkeyget wrote: post #54

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…

> Make a few symlinks from your home directory to the directories you use frequently. Instead of doing cd this/that/code/python/project/ you just do cd ~/project If you are using ZSH, you can just append paths to the $cdpath environment variable. This will allow you to "cd name-of-project" (assuming you've added your project directory to $cdpath). No need for a mess of symlinks in this case.

Or you can use "cdargs" [1], available in Homebrew [2]

[1] http://www.skamphausen.de/cgi-bin/ska/CDargs

[2] brew install cdargs

Post reply on HN