Basically it's a command-line front end to Apple's TextKit file import/export library. Works with a bunch of rich text/word processor formats, including OpenDoc, RTF, HTML 5, and MS Word. Critically, the HTML it emits is vastly better than the bloated crap that comes out of Microsoft Word or LibreOffice when you save as HTML ...
Install pandoc and multimarkdown as well and you've got the three pillars of a powerful, easy-to-use multiformat text processing system.
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.)
What always surprises me is that so many don't know or use the directory stack commands, pushd and popd. I'll admit I was also ignorant of them until something like 2005, but once I learned of them I switched and never looked back. Now I can't see someone write or type "cd" without a little bit of a cringe.
When i first found out about pushd and popd, i loved them, and used them all the time. These days, i never use them.
The way i work now is that i have a bunch of terminal tabs open. Each tab has a shell which pretty much just sits in a single directory. If i need to switch to a different directory, i switch tabs. A nice effect of this is that each tab builds up a recent shell history specific to the directory it sits in; the shell in the source directory has a history full of build commands, the shell in the installation directory has a history full of start and stop commands, and so on.
This works because i generally use a fairly small (<10) set of different directories, and i don't move between directories much as part of a single task. Partly, this is because i use qualified paths rather than cd'ing around everywhere. I am happy writing (mostly, tab-completing):
vi lib/awesomeapp/dns/client.rb
Whereas a colleague of mine would always do:
cd lib
cd awesomeapp
cd dns
vi client.rb
He might get a lot of mileage out of pushd/popd. But for me, it just optimises something i don't spend a lot of time doing.
I have the same workflow for switching between tabs, although on Mac the default keyboard shortcut for switching Terminal tabs (Cmd + Shift + '[' or ']') was a little too cumbersome. I swapped it out with (Cmd + '[') which by default will take you to the next Terminal, not tab. I move left to right more, so it made more sense for me.
Easy enough to change in system preferences, though. And with using Vim NERDtree, or some other directory plugin, it makes sitting at the top level directory of your project, with multiple projects in multiple tabs, pretty easy.
Are you on Mac? If so, have you done anything to make tab-switching easier/faster? I'm interested because I only recently set mine up this way, and am always open to more efficient methods.
A related trick is to use parentheses to create a subshell, in the case where you have a fixed command sequence you want to execute in another directory but you don't want to stay there:
Many people love them, but I never got the hang of pushd and popd. These days, I use a CDPATH and z[1]. I also use zsh, which supports handy little things such as cd - (cd to previous directory).
If you haven't tried it, I highly recommend z. It's impossible to Google for, but it's oh-so-convenient.
cd is a shell built-in, not an external command. It has to be, since it changes the directory of the shell process, which can't be done by a child process. So shells do have to implement this specially.
I tend to use "cd -" instead, which goes to the previous directory. Coupled with searching the command line history (C-r in the default emacs-like mode of bash, ESC-/ if you have set vi-like mode with "set -o vi") you can move around quite fast and with little thought.
uhh... I have known pushd and popd for quite a long time, but never realized that pushd can be used in place of cd. So what I have been doing all the time is:
I've always just relied on zsh to deal with my pushd stack automatically. I don't frequently need to pushd (thanks to tmux's vertical splits), but when I do, it's inevitably something I don't think about until after I've swapped directories.
I didn't know about `screencapture`. That's a fun one.
The Linux equivalent of `open` is `xdg-open`. I usually alias it to `op`, since `/bin/open` exists.
Another bit of terminal-sugar for OS X users:
alias lock='/System/Library/CoreServices/"Menu Extras"/User.menu/Contents/Resources/CGSession -suspend'
And most Linux users:
alias lock='gnome-screensaver-command -l'
If you find yourself accidentally triggering hot corners, the lock command is your savior.
I've sorta-documented this stuff over the years, but only for my own memory. https://gist.github.com/ggreer/3251885 contains some of my notes for what I do with a clean install of OS X. Some of the utility links are dated, but fixing the animation times really improves my quality of life.
Additional, Linux equivalents of pbcopy/pbpaste are available in a number of competing utilities such as xcut, xclip and xset. Unfortunately none of these are installed by default on standard installations, at least not on any common distribution I've ever seen.
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.
These are awesome. I didn't know about many of them.
One tiny thing though, at the bottom it says
> Recall that OS X apps are not true executables, but actually special directories (bundles) with the extension .app. open is the only way to launch these programs from the command line.
Actually, you can launch them in other ways. Example
Will start a new instance of Chrome with it's own datastore in ~/temp/delmechrome. add some URL to the end to have it auto launch some webpage. Delete ~/temp/delmechrome to start over.
Although this technically works, in some cases it may lead to strange bits of misbehavior. (Depending on where you do it, the app may end up in the wrong audit session or mach namespace, and it may also be missing some environment variables that it was expecting).
The open command does allow you to specify command-line arguments to pass to the application (via --args), which is generally a safer way to do things.
But the open command doesn't allow you to pass the environment, and Apple seems hellbent on breaking every workaround they've implemented over the years (e.g. ~/.MacOSX/environment.plist).
So, doing Foo.app/Contents/MacOS/Foo is often the only way to launch a GUI app while inheriting the full environment that you have on the command line.
I often have to do this to launch various developer tools, and have them be able to inherent important environment variables, e.g. database credentials or secrets,
> But the open command doesn't allow you to pass the environment
Uh? I’ve been using open to pass NSZombieEnabled and other debugging stuff to apps all the time and it works.
From man open(1):
Opened applications inherit environment variables just
as if you had launched the application directly through
its full path. This behavior was also present in Tiger.
What?! Awesome! I would swear that was once not the case... (checks man page)
Opened applications inherit environment variables just
as if you had launched the application directly through
its full path. This behavior was also present in *Tiger*.
Integrates with keychain meaning you can have a passworded private key without having to play around with ssh-agent and shells and profiles. Put keychain access in the menu bar and you can lock the keychain on demand as well. Integration of ssh into the OSX workflow is absolutely awesome.
That and some of the examples in that article really make it a killer platform for Unix bits.
'open' is on of the things I long for most as a Linux user.
There are several ways to achieve something that are all inferior or downright broken. Usually you don't have a huge problem, until you have. xdg-open for example could've solved this, if it was universally working.
I wrote related rant once[0] when I tried to debug an issue of a misconfigured default browser.
While xdg-open also works well for me with KDE's default applications, when I used to use Openbox or LXDE, it was much less successful. The breadth of the group of tools that respond correctly to KDE settings as opposed to the less-common environments has been one of the reasons I've been so happy to switch.
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.
I work on pkgsrc which is another alternative. Its main advantages are:
* A large number of pre-built binary packages with an apt-get style command (pkgin) to install them. Over 10,000 packages are available for OSX in the most recent release (2014Q1).
* It is cross-platform to over 20 different platforms. At Joyent we provide binary packages for SmartOS/illumos, OSX, and Linux, so you can use identical packaging tools across multiple platforms, rather than having to use different tools on each OS. It is the default package manager on SmartOS, with over 12,000 binary packages available for that platform.
* As the 'src' in 'pkgsrc' implies, it's very easy to build from source too if you want to tweak build options or compiler flags. You can also install into any prefix you desire (we default to /usr/pkg), even as an unprivileged user to your home directory.
Our binary packages are available from http://pkgsrc.joyent.com/installing.html and we'd love to hear feedback on how to improve them or adding support for different platforms.
/usr/local is a wasteland on OS X. Package installers love to dump stuff in there blindly. This leads to fun-to-debug problems where two different things are overwriting files in there and blowing up because of version mismatch problems.
I ended up making a /rr tree ("rwg's root"), building things I care about from scratch, and using GNU stow to manage it.
Homebrew actually uses /usr/local/Cellar for all its installations, and then makes symlinks in the relevant /usr/local/{bin,sbin} directories. Not sure if that's what you meant.
Thanks for the clarification. Still, a quick Google search seems to indicate that this does not solve all related problems (symlinking, overriding, etc.).
I use homebrew in /homebrew for exactly this reason. The homebrew folks make noise about this, but I don't install language specific packages via brew, so I've never had a problem.
> 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.
It does bother me that Homebrew advocates using /usr/local, that is a choice that needs justification and I don't believe they offer anything convincing.
That said, you can configure homebrew to use any path (check the wiki), you just have to set other environment variables as needed (eg, PATH). For example I'm currently using /opt/homebrew.
(note: a large downside to this is that you have to compile everything and cannot take advantage of Homebrew's pre-compiled "bottles" for some packages)
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.
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 disjoined mouse-based GUI experiences.
Here are some recommendations pertaining to mastering the command line on a Mac specifically:
-You can make the terminal start instantaneously instead of it taking several seconds. Remove the .asl files in /private/var/log/asl/. Also remove the file /users/<username>/Library/Preferences/com.apple.terminal.plist
-Make your terminal look gorgeous. It may sound superficial but it actually is important when you spend expanded period of time in the terminal. You go from this http://i.imgur.com/cx3zZL8.png to this http://i.imgur.com/MQbx8yK.png . You become eager to go to your terminal instead of reluctant. Pick a nice color scheme https://code.google.com/p/iterm2/wiki/ColorGallery . Use a nice font (Monaco, Source Code Pro, Inconsolata are popular). Make it anti aliased.
-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.
-Install Alfred. It's the command line for the GUI/Apple part of your system. Since I installed it I stopped using the dock and Spotlight. Press ⌘+space then type what you want and it comes up. In just a few keystrokes you can open an application, open gmail/twitter/imdb/..., make a webs search, find a file (by name, by text content), open a directory,... It's difficult to describe how empowering it is to being able to go from 'I want to check something out in the directory x which is somewhere deep deep in my dev folders' to having it displayed in 2 seconds flat.
-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.
-Learn the shell. I recommend the (free) book The Linux Command Line: http://linuxcommand.org/tlcl.php . It guides you gently from simple directory navigation all the way up to shell scripting.
-Use tmux. Essential if you want to spend some time in the terminal. You can split the window in multiple independent panes. Your screen will have multiple terminals displayed simultaneously that you can edit independently. For example I'll have the code in one side and on the other side a REPL or a browser. You can also have multiple windows each with its own set of panes and switch from on to the other. With the multiple windows I can switch from one aspect of a project to another instantly. E.g: one window for the front-end dev, a second one for the backend and another for misc file management/git/whatever.
-Pick an editor and work towards mastery. I don't care if you choose vi or emacs. You'll be surprised how simple features can make a big change in how you type. You'll be even more surprised at how good it feels
The terminal is here to stay. It's a skill that bears a lot of fruits and that deprecate slowly. The more you sow the more you reap.
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 Emacs for a long time there's no reason to do it in a terminal. I always used the GTK or the Athena version.
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 single window manager window using ":split" and the like. Vim calls these "windows". You can have multiple tab pages, each of which holding multiple Vim windows, but all these tab pages must reside in a single system window-manager window.
Vim has a help file somewhere saying that Bram Moolenaar knows this is a problem and it's on the todo list.
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.)
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.
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.
What's wrong with the default Terminal application? I use it daily and have been for close to a decade. I never found myself wishing it did anything than what it already does.
> -Use tmux.
Meh. For most people screen works just as well. Perhaps more importantly, you can rely on screen being available pretty much anywhere. Just like vim. Speaking of which: vim is great. Use vim. The world needs more vim.
Been loving vim for several years. Finally decided to learn emacs, partially spurred by interest in clojure.
It seems that as more languages are created that include native repl experiences, emacs becomes more appealing to me because it fits nicely with editor+repl, where in other editors a repl seems more of an afterthought or nice-to-have.
I would say definitely learn vim first, but it's great to know both vim and emacs. It just opens up more doors.
iTerm2 does vertical and horizontal splitting better than Terminal.app.
tmux does vertical and horizontal splitting better than screen.
That's my rationale for using iTerm2 and tmux instead of Terminal.app and screen.
(yes, I'm aware that screen has improved its splitting recently, but I switched to tmux in 2011, after seeing a presentation about it by Nicholas Marriott)
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.
Out of curiosity iTerm or iTerm2? If the latter what is crap about it?
I have one huge gripe that I haven't been able to fix but its not that huge a deal. Every so often the terminal will lose its mind and start displaying mouse escape sequences. Nothing resets it out of this state, have to close whatever window I have open and start anew. Not a huge deal due to tmux but annoying enough to frustrate.
> The big advantage is that you can quickly scroll the history with the mouse...
I've not found that to be faster than <CTRL+F> or <CTRL+B>. 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).
Actually, those two points are related: I started using iterm2 precisely because I also started using tmux, and tmux integration is much better with iterm2 than with the native terminal (and for me at least I find tmux much simpler than using screen). So there are advantages.
> Speaking of which: vim is great. Use vim. The world needs more vim.
I'd add installing zsh+oh-my-zsh. Impressive autocompletion, fuzzy matching, shortcuts, themes (I think agnoster is great), plugins... It's really great and I wouldn't go back to bash. Some resources:
I'd also install autojump https://github.com/joelthelion/autojump to jump quickly between directories instead of using symlinks. Instead of cd ~/project, you just do j project, or maybe j proj is enough for autojump to know where you want to go.
A friend of mine was experiencing multiple-second launches for Terminal. When he looked, he saw that it was occupying about 1 GB of memory.
Turns out the option to maintain ALL HISTORY EVER as scrollback was turned on. So he had the last year of compiler output and whatnot stored in a file somewhere, getting loaded into memory the first time he launched Terminal after a boot, and then eating a big chunk of his laptop's memory. Turning off the option was a major improvement.
It might be parsing through logs to find out last login information.
So, like any unix os, ensure you do this:
touch $HOME/.hushlogin
That will short circuit that stuff. Like you said I've not had issues with terminals opening fast but it can't hurt. I don't give a rats when I last logged in on any unix os I log into.
Does that really not work by default? I would figure it's only an issue if you have your disk formatted as case sensitive, which is usually a bad idea because a lot of devs don't test on it.
No, case-insensitive auto-completion doesn't work by default on OS X. For example, `cd /appli <tab>` 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 <tab>` and it will auto-complete to `cd /Applications/`.
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.
I wholeheartedly agree that it's a good investment to spend time learning your way around the shell. And I've been quite successfully proselytizing it at home: the terminal and the UNIX toolset has been part of my sons' introduction to computing. I actually wrote it down in form of a (free, online) book. It began with my sons in mind, but it soon became a more serious endeavor:
> 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 iOS, but it's the perfect mode for writers, coders--and really just about any kind of creator who needs to focus.
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 version is fully functional with just an occasional nag screen.
I do front-end web development and full-screen doesn't work for me. I never spend that much time just coding. I switch to test in the browser often so switching between full-screen windows is jarring.
Quicksilver used to be great, but then the main developer went to work on some dead end project for Google and abandoned Quicksilver. Is the project still alive?
It's too late for me anyway - I have moved to Alfred, the new kid on the block at the time, and like it much more (much less clutter). Plus, I can't trust the QS developer anymore after he's abandoned the project once.
Thank you very much for this write-up and post. I am in a similar boat you are -- every month that passes as a developer makes me hungry to automate those repetitive tasks I do every time I develop something.
I also think this sentiment will be growing. I think there's a large disconnect between "traditional" UNIX users and people entering from the web / Rails / other kinds of worlds, and that gap is slowly shrinking. That's why we are seeing things like npm tools (bower, grunt) replacing makefiles, Docker replacing traditional sysops, the whole idea of "DevOps" as a thing vs "IT".
I'm very very excited about this transition and want to help be a part of it. I think I'm going to write a similar tutorial outlining my current mac / terminal workflow.
The killer for using iTerm2 is the ability to drop another split in with Cmd+D/Cmd+Shift+D. That's pretty much the only iTerm2 feature that I use with any level of regularity, but it's awesomely handy when you're working.
Being able to save and restore the window arrangement is also awesome. I keep iTerm2 in full-screen mode and I have it split into 4 terminals. If I need to restart iTerm2, I simply choose Window -> Restore Window Arrangement and my split terminals are restored.
> 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.
In practice I find Terminal/tmux/emacs a more pleasant experience to me than GUI emacs/frame and window/shell.
GUI emacs does brings nice features:
-multiple fonts / font sizes at the same time (nice for minimap http://www.emacswiki.org/emacs/MiniMap !)
-more shortcut possibilities with s- added to the usual C- and M--
-more colours
Shell/ansi-term modes don't work well enough. There's always problems with shortcuts/encoding/escape sequences/Ncurse.
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.)
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
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:
I use multiple POSIX environments (OS X at work, Linux Mint and Xubuntu at home), and I find it handy to create common aliases for differently implemented commands to keep the environments consistent.
For example, I set the letter 'o' as an alias for 'open' on OS X, and to "thunar" on Xubuntu and "nemo" on Linux Mint.
I used `say` to read out the cricket scores from a screenscraping bot whilst the TV (which was the radio at the time) was in use for games. Not quite TMS but it had a certain charm.
In Mavericks, selecting Customize from the System Voice dropdown of the Dictation & Speech preferences brings up a list of voices you can download as well. I think Alex was my default, but some of the others seem much better.
After years of living on the command line, OS X specifically, and learning its quirks and tricks, I am actually ready to move on.
Right now I am more interested in creating simple visual interfaces on top of UNIX-y tools, for my own personal use cases. The main benefit of this is the ability to better experiment with and optimize my workflows for different properties as needed through different combinations of single responsibility interfaces and single responsibility programs.
I am sensing that there is great promise in seeing much higher APMs (actions per minute) for many tasks, even compared to the all-powerful command line. Also, there are lots of interesting possibilities for better visual representations of data to improve comprehension and usability.
Why do you think that having a visual interface will make it easier to experiment with your workflow?
This is a genuine question - personally, i find command line interfaces to be far more hackable than graphical ones, so i would expect the opposite to be true, and hence i'm interested in your perspective.
The command line is a textual interface, and both code and data can be represented as text at a low level. It would seem that this is a good thing for efficiency and usability, as it minimizes context switching between interface paradigms, and offers direct access to a low level representation of the system using a high bandwidth input device (a keyboard).
I still think textual interfaces are a great thing for those reasons, but I don't believe they are the best thing in many cases. Yes, they are very capable and customizable, but have serious weaknesses with usability, especially when working with data of higher dimension.
I don't really think of it as text versus graphics, but rather an issue of data being represented in its best form for doing some particular work with it, and having the best interfaces to those different forms and the work. The traditional one-domain/one-application GUI model is unsustainable for this purpose, and has the weakness of constant context shifting. Composable visual interfaces are an anti-application paradigm, and more focused on data flow. To avoid problems with pure visual programming environments, symbols would still be considered the best representation for certain work (like editing text and working with logic).
Not the parent, but personally I can't remember the huge list of available Unix commands. Every time I want to do something outside my normal workflow, I end up in google. For me, "Google + man page + command line" is slower than a nice GUI optimized for specific tasks. The hard part is designing this mythical nice GUI.
It seems like a large portion of HN is less experienced re sysadmin, but is interested in it nonetheless. Perhaps there's room to make a 'codecademy for unix' type course? Curious to see what folks thing.
It does feel I'm retreading ground that's already been covered too many times, but my whole motivation for this blog was more or less what you're observing. There's a huge group of people on the fringes of hacker culture who are looking for a way in and don't know where to start. Definitely a fan of the idea of 'Nixacademy.
Here is a very handy script that takes a screenshot, places it in Dropbox's public directory, shortens the public URL, then puts the short URL in your clipboard. Making for very quick screenshot sharing. It combines a few of these hints. https://gist.github.com/jpb0104/1051544
Great list! Includes all the old favorites with clear explanations.
This is only tangentially related, but I recently wrote a little Automator Service to gather any selected file and folder paths from Finder. I very often need to grab the path of something for programming-related stuff, and doing it from the command line or with the mini-icon drag-and-drop takes way too long. Maybe somebody here will find it useful! http://cl.ly/1a3s3g1u2Q2w
I want "remote pbcopy"! I'd like to be able to log in to any remote host (usually Linux in my case), then tack something onto the command line I'm typing to copy it into the pastebuffer.
ssh somehost
cd /some/dir
grep -lr foo . | remote_pbcopy
I guess something like this is possible with GNU Screen or with Tmux, and perhaps the Tmux/iTerm interaction helps, but I've never figured it out.
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)
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.
Also worth mentioning is dotfiles (not specific to OS X). Basically various well known "power users" share their bash, homebrew, etc settings on github so that they can easily set up a new machine with minimum of fuss.
There are a lot of neat trick in those boilerplate files.
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.
Homebrew is the new hotness. I'm not entirely sure how it's been able to so quickly eclipse Macports, but having used both, I Homebrew tends to stay more out of my way and be friendlier with the stuff I want to use. Maybe that's how, I suppose.
My understanding is that macports is a lot more finicky and hacky, especially when it comes to built-in dependencies. homebrew is specifically designed to avoid such problems.
My understanding is quite the opposite. There are a number of trivial differences between MacPorts and Homebrew - for example, MacPorts recipes are written in Tcl, Homebrew's are written in Ruby, MacPorts puts things in /opt/local, Homebrew puts things in /usr/local/Cellar, MacPorts gets its metadata with rsync, Homebrew uses Git. But there is, as far as i know, only one non-trivial difference: MacPorts links everything against versions of libraries that it has installed, whereas Homebrew links them against the ones supplied by Apple.
The Homebrew maintainers think that linking against Apple's libraries is better, because you need to install less stuff.
The MacPorts maintainers used to agree, several years ago, and used to do just that. Then, Apple released a software update which changed some libraries and broke everyone's MacPorts installations. So then they changed their mind. Now, they think that linking against their own, coherently managed, set of libraries is better, because Apple can't break stuff.
To me, Homebrew just looks like an exercise in reproducing others' work without learning from their experiences. I don't see any advantages to it myself.
Less fundamentally, there's also quite a difference in the number of packages. MacPorts's homepage indicates that they have 18530 ports. An ls|wc in Homebrew's repository indicates that they have 2802 formulae. That said, i suspect that 95% of what people actually need is in the collection that Homebrew has.
I don't think Homebrew was so much reinventing the wheel, as it was trying to create a modern replacement in an era when MacPorts/DarwinPorts was stagnate and Fink was in a similar state of upheaval.
I remember having issues getting Fink and MacPorts to run correctly in the early days of Snow Leopard, which was frustrating if you needed a library. Homebrew came in, was easier to install and had less legacy code issues.
As for tbe package counts, I'd say most of those packages are probably relics from the PPC days. I was hesitant to switch to Homebrew, but in really do think it has a better implementation.
I did try MacPorts for the first time in over a year on a new system recently, and it has improved dramatically.
But really, package management systems are all about reinventing the wheel. I'm glad both projects are active.
I thought like what you describe at first, but after using it, I realized it was just much more productive because of the simplicity. In homebrew, if a linked lib breaks, it's pretty easy to fix by simply reinstalling, and it doesn't happen very often. It's also trivial to change build options. So, basically, it's more disjoint, but because of this, it moves much faster and is way more flexible.
"Select a window using your mouse, then capture its contents without the window’s drop shadow and copy the image to the clipboard:
$ screencapture -c W"
-c captures the cursor, W is not an option. The real command for this is:
The hot keys for screen capture are more useful for daily use. You can paste what you've capture directly into most email clients. Or go to Preview where creating a new file uses what's on your clipboard if its an image.
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.
I don’t use a Mac, but have used espeak-via-ssh to deliver a message to my sister who was near my laptop, from the comfort of my bed… I could have (a) called out, or (b) gotten up, but where would the fun have been in that?
Awesome. I knew about `pbcopy`, but i never knew you could also pipe stuff into it. That saves a lot of time saving script outputs to temporary text files and copying!
Personally, I was surprised that there is not a command line interface to OS X's Notification system. Seems like it would be handy for long running batch jobs.
Basically it's a command-line front end to Apple's TextKit file import/export library. Works with a bunch of rich text/word processor formats, including OpenDoc, RTF, HTML 5, and MS Word. Critically, the HTML it emits is vastly better than the bloated crap that comes out of Microsoft Word or LibreOffice when you save as HTML ...
Install pandoc and multimarkdown as well and you've got the three pillars of a powerful, easy-to-use multiformat text processing system.