Live data from Hacker News

OS X Command Line Utilities

mitchchn.me

231–240 of 243 posts

Re: OS X Command Line Utilities

#231
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 agree about staying out of /usr/local. I install stuff there -- I don't want my package manager taking it over. That's kept me away from Homebrew.

> I don't want my package manager taking it over. That's kept me away from Homebrew

That was an early blocker for me as well; however, when I discovered that I could just install homebrew at ~/.homebrew, that made it all work out.

I created https://github.com/wilmoore/homebrew-home to automate this; however, you technically don't need this install script as you could do it yourself if you really wanted to. I like it because I no longer have to think about it.

Re: OS X Command Line Utilities

#232

Notably the screen capture terminal command, while neat, is sold as "more flexible". I think the author is unaware of Command+shift+4 followed by tapping the spacebar. It'll give you the window capture. Otherwise good article.

If you have Cloudup installed, that command sequence will also upload the screenshot automatically.

https://cloudup.com/about

Re: OS X Command Line Utilities

#233

Another thing you can do to improve speed is learn the keybindings for readline. They are the same keybindings as emacs, and lots of other things use readline too like python shell, sqlite, etc. A very useful set of keys to have in your muscle memory. See the readline manual: http://tiswww.case.edu/php/chet/readline/rluserman.html#SEC3

if your a vi/vim user in you're .inputrc set: set editing-mode vi set keymap vi-command see more settings @ https://github.com/shawndumas/dotfiles/blob/master/readline/...

This won't work for some standard stuff that OS X ships with, for instance Python (when started as a command-line interpreter). That's because .inputrc is read by the GNU readline utilities, and Apple links with the BSD equivalent.

To make this work for Python:

Add a file called .editrc with the following content:

bind -v

Add a file called .pythonrc with the following lines:

import rlcompleter import readline

Add a line to your .bashrc which makes Python run .pythonrc when it starts interactively:

export PYTHONSTARTUP="$HOME/.pythonrc"

Now Python will understand your vi keystrokes :-)

Re: OS X Command Line Utilities

#235

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.

I changed it. The HN guidelines call for taking linkbait out of titles ("every user should know") and for not having arbitrary numbers in titles—which are also a form of linkbait. Taking those things out as well as the redundancies (terminal/command-line, utilities/users) yields something pretty close to "OS X Command Line Utilities".

I don't see any ambiguity. The article is precisely about OS X Command Line Utilities; it doesn't matter how many there are in the list. Nor is it misleading. There's no implication of completeness.

Re: OS X Command Line Utilities

#236
post #210
post #120

Could you imagine Apple would have gone for BeOS or a custom developed kernel with no significant terminal-based userland when making OS X? It would probably still be used by many casual users or those doing graphical work, but I doubt it would be used by hackers at all.

Didn't BeOS ship with bash and everything?

Whoops. Yes it did. Haiku still does: http://www.haiku-os.org/docs/userguide/en/bash-scripting.htm...

Re: OS X Command Line Utilities

#238

Earlier quoted context omitted.

No, case-insensitive auto-completion doesn't work by default on OS X. For example, `cd /appli ` does nothing by default (it's not finding `/Applications/`) even though my disk is formatted case-insensitive. However, after adding `set completion-ignore-case on` to my `~/.inputrc` file, I can now type `cd /appli ` and it will auto-complete to `cd /Applications/`.

Any idea why Apple has it set up that way? I don't spend much time in the terminal, but case sensitive auto-complete just doesn't sound helpful.

By default OSX's HFS+ volume is configured to be case-insensitive, but case-preserving. So, the filenames will preserve the case, but the filesystem doesn't distinguish based on case. It makes for interesting bugs.

Re: OS X Command Line Utilities

#239
post #87

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…

Another trick I learned from an older HN comment is to create a .marks directory in your home directory and then add the following to your .zshrc export MARKPATH=$HOME/.marks function jump { cd -P $MARKPATH/$1 2>/dev/null || echo "No such mark: $1" } function mark { mkdir -p $MARKPATH; ln -s $(pwd) $MARKPATH/$1 } function unmark { rm -if "$MARKPATH/$1" } function marks { ls -l $MARKPATH | sed 's/ / /g' | cut -d' ' -f…

I prefer using z, which is purely written in bash.

https://github.com/rupa/z

Re: OS X Command Line Utilities

#240
post #70

Earlier quoted context omitted.

Pandoc and multimarkdown are the greatest. I've never found a way to fit textutil into that workflow, though. Is there anything it can do that pandoc can't by itself?

Textutil handles a couple of apple-specific file formats (rtfd, webarchive) that do an embrace-and-extend on open(ish) standards. (Annoyingly it doesn't provide a way to get at the guts of Apple's own Pages files. Which sucks because the only tools for transcoding Pages are Pages itself, and icloud.com.)

Thanks! I played with this last night and wrote about it in my followup: http://www.mitchchn.me/2014/and-eight-hundred-more/
Post reply on HN