no love for macport?
I'm pretty sure that homebrew is to MacPorts as git is to svn.
OS X Command Line Utilities
101–110 of 243 posts
Re: OS X Command Line Utilities
#102no love for macport?
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.
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.
Re: OS X Command Line Utilities
#103'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. [0]: http://f5n.org/blog/2013/default-browser-li…
xdg-open works for me with the GNOME-configured default application.
Re: OS X Command Line Utilities
#104What 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.
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 (
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.Re: OS X Command Line Utilities
#105Earlier 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 wish fullscreen mode didn't switch to a different desktop. Tabbing out causes this weird "whoosh" animation to play which is so annoying.
Re: OS X Command Line Utilities
#106What 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.
setopt autopushd
to have cd work like pushd.And
setopt pushdignoredups
is probably helpful too as it will not push the same directory multiple times on the stack.Re: OS X Command Line Utilities
#107After 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…
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.
Re: OS X Command Line Utilities
#108This 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…
Re: OS X Command Line Utilities
#109My favorite command is 'say'. You can do all kinds of silly voices. Try this out: say hello -v Good
Re: OS X Command Line Utilities
#110no love for macport?