> You should actually 1. run the line starting with echo in your current shell OR copy and paste the line starting with eval into your relevant dotfile.<p>This isn't right. You should be running both commands in your shell. That's what the brew instructions are saying, albeit in a confusing manner.<p>The first command makes future shells have brew in their $PATH, the second command applies it for the current shell.<p>To make things even easier for users, brew could forgo the second command and just ask users to close the current terminal and open a new one. This has the added benefit of confirming the first command.
I think up until recently, homebrew was also recommending incorrect instructions for fish shell users in a similar sounding way. The instructions basically said add "fish_add_path /usr/local/bin" to your config.fish file, but in actual fact you only need to run fish_add_path once and its added permanently to your $PATH for all your future sessions, as well as your current session.<p>I only realised when I finally got fed up with my terminal taking several seconds to start, I dug into why and found that my $PATH had something crazy like >1000 items with the homebrew path taking up pretty much all of them.
Lately I've been getting tired of homebrew. It's not compatible with keeping old versions of software installed. It automatically runs an upgrade of all your installed stuff every so often (when you run brew), which is fundamentally user-hostile behavior.<p>I strongly recommend to consider switching to macports or pkgsrc or nix as your package manager. And/or possibly just using a linux VM as your development environment, such as NixOS.
This is not an error users make. It's an error that Brew makes, as a software: not taking the chance to, you know, <i>work for the user</i> instead of otherwise, as computing should do.<p>Just ask the user if they want the configuration be automatically applied for them. 99% will say "yes, please" and the rest will be the commenters here who (fairly enough) don't want their init scripts touched by an installer.
The eval part of the script is unnecessarily versatile. I think a much simpler (and easier to understand) step is to ask user to relaunch their Terminal.<p>Then the instruction becomes an easy 1 step task.
Ah yes, the instructions should say "Run this in your console (Do not paste into file)" or similar.<p>I really appreciate the quick test to show whether this problem exists for you.
I was a long time homebrew user, but I found as time went on it got increasingly frustrating to use. The one thing that kept biting me was it wanting to update itself and all installed packages each time you install a new package. Having to wait 20 minutes for LLVM to recompile itself just so you can install wget is not fun.<p>I use MacPorts now, since it gets out of your way. It's up to you when you choose to update its index or your packages, which is much more user friendly in my opinion.
at some point I got sufficiently frustrated with all the things that decided they need to add the same various folders to my path over and over that I added this to the end of my .tcshrc (something similar should be possible in most shells)<p><pre><code> # dedupe path
set path = ( `echo $path | tr ' ' '\n' | perl -ne 'print $_ unless $s{$_}++;' | tr '\n' ' '` )</code></pre>
The first line adds the brew setup to your shell startup file. The second line executes the same brew setup steps, but for <i>your current shell</i> so you can you start using brew right away. Both lines should be executed in your shell when you first install homebrew.
Wonder given there is an obvious pattern to it can a script (!) one line and ensure even if copy to the dot file still ok to clean it up … if it is so common why not use computer to check and clean it.
As discussed [1], please don't simply copy shell things without a stop;)<p>[1] <a href="https://news.ycombinator.com/item?id=10554679" rel="nofollow">https://news.ycombinator.com/item?id=10554679</a>
I agree with the other commenter, this is just a blatant ad for a paid product.<p>If you're a CEO of anything, anywhere who ever interacts with Hacker News: do yourself a favor and don't submit anything you have had a hand in. It just feels filthy, and it ruins the integrity of the submissions process. Pieces like this hitting frontpage are the reason I can't trust this site anymore...<p>...Furthermore, I also remember seeing <i>another</i> Fig-related submission earlier in the month. It feels like I'm the target of a hyper-concentrated ad-campaign.