10 ms·

A surprisingly common error users make when installing Brew

201 points by brendanfalk 5y ago

atian 5y ago
Is the http://localhost/fig.io?ref=github http://localhost/fig.io?ref=github link broken?
- brendanfalk 5y ago
  Whoops. Forgot to include the https in the link. That always gets me. Thanks for the heads up
irjustin 5y ago
Ah yes, the instructions should say "Run this in your console (Do not paste into file)" or similar. I really appreciate the quick test to show whether this problem exists for you.
- jandrese 5y ago
  In the old days it was common in documentation to prefix anything you were going to run with the prompt, just to make it obvious that it is a shell command. Like so: % echo 'stuff' >> ~/.zprofile If something had to be run as root the prefix was # instead, just like in Bourne Shell. Of course this makes it more difficult to copy and paste, you have to do each line one at a time.
  - dylan604 5y ago
    this is actually something i never thought about. if you did copy the lines to be run as root with the preceding #, would it be interpreted as a comment and ignored? some sort of built-in safety from running blindly copied commands?
    - bewuethr 5y ago
      I once read that's the reason why the root prompt is #.
      - a1369209993 5y ago
        I can't speak for whoever came up with it originally, but that is the reason I retained that behaviour in my own shell, and it certainly sounds plausible.
    - irjustin 5y ago
      If nothing else, it would simply error.
  - ddalcino 5y ago
    I’ve been involved with two different open source projects where, within the last couple of months, users have opened issues complaining about the shell prompts in the documentation, or PRs removing them, because it makes it too hard to copy-paste commands. The PRs were accepted over my objections. I was taught that you NEVER copy paste anything from the internet into a terminal. You learn what the commands do, and you type them yourself. Am I just old?
    - actually_a_dog 5y ago
      No, you were taught the right thing. You never know what some random JavaScript is gonna do to the contents of your clipboard when copying from a web page. Best practice, IMO, is to open as dumb an editor as you can find and pasting the commands into an editor buffer for inspection before running anything in the shell. And, if you don’t understand what it’s ask you to paste into your shell, don’t do it. Even if you run with JavaScript off entirely, this at least makes you think before you do anything potentially destructive.
    - pope_meat 5y ago
      What we're supposed to do, and what actually happens are different things. Especially in a situation where you're trying to install something just to get some other thing to work.
    - MattGaiser 5y ago
      In theory, yes you are right. In practice, I have deadlines and people wanting things and I often need to get things I don't understand up and running pretty quickly.
    - irjustin 5y ago
      Goals of focus and trust to gain speed. The sentiment makes sense locally, but at some point you either need to trust the thing you're working with or you do it yourself. There's not enough time in a day to "learn the commands yourself" for everything you do, but if you personally choose to learn and type the commands yourself, great! It's also okay to trust others with what you're doing. If you run brew, you literally are trusting other's install scripts not to do something malicious. (Seems ironic to run the brew command, but not trust the copy/paste it tells you to do?) Even if you don't run brew and install/compile the software yourself, you haven't read every line of code that the software is running to know if that's truly safe. It's not ideal, but you need to trust at some level or you're never going to move forward.
herpderperator 5y ago
If people don't even know what those commands mean, why are they even presented as a step? The installer could do both things for them.
- jandrese 5y ago
  I guess people get touchy when you start editing their startup scripts? I agree that it would be pretty easy for the installer to check and add the lines if they are missing.
  - MereInterest 5y ago
    > I guess people get touchy when you start editing their startup scripts? I'm definitely one of those people. The startup script is my personal configuration, under source control and managed to set up an environment exactly how I want it. The very first thing I do on a new computer is clone that repo, so that I have my standard working environment available. It's definitely not a dumping ground for anything that has just been installed. > I agree that it would be pretty easy for the installer to check and add the lines if they are missing. But this is where it gets difficult, because that's in no way an easy thing to check. My .bashrc sources a .bashrc_local, so that I can have some computer-specific settings. It has conditionals, based on what tools are available on the current machine. Heck, some of the commands are generated by a python script, such as coloring the PS1 pseudorandomly based on the hostname, so I can tell at a glance which computer I'm ssh'ed into. (Side note, I definitely need to clean it out at some point, as it has definitely accumulated a lot of cruft over the years.) Determining if a particular script is sourced requires solving the halting problem. Granted, doing a quick grep for the name of the setup script is probably sufficient, but an installer shouldn't be editing my setup script even if it doesn't find anything.
    - pjerem 5y ago
      At least it could ask if you want it to add it for you. I’d answer yes, you’ll answer no and everybody would be happy.
    - 5y ago
herpderperator 5y ago
> 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. 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. The first command makes future shells have brew in their $PATH, the second command applies it for the current shell. 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.
- brendanfalk 5y ago
  Agree! I will update this. Good catch. Thank you!
- deleted 5y ago
  [deleted]
- brendanfalk 5y ago
  But also just to clarify, the intention for this post was how to fix this issue if it had already occurred NOT a "how to install brew correctly" guide. If the issue had occurred, you wouldn't need to run the eval command again, it would have already been run 1,000 times from your .zprofile. Hence I suggest just to delete all references of it then add back one. But I do take your point that my post could also have been seen as ambiguous and hence added in your suggested changes.
evanrelf 5y ago
This feels more like an advertisement for Fig than a genuinely interesting issue?
- forgotmypw17 5y ago
  I think it's about equally both.
  - indigodaddy 5y ago
    Not exactly a great look for the fig employees though is it?
    - herpderperator 5y ago
      Not everyone has to be an expert on the shell to be good at their job.
      - indigodaddy 5y ago
        Shouldn’t a software engineer who lives in the Mac and/or *nix ecosystem, be competent in the shell? I understand that it’s not programming, but it just seems such a core and fundamental/base skill to understand this stuff. I agree the instructions are not clear enough, however. “Run the following two commands, which adds the needful to your profile and current shell” or similar would be a better way to put it.
        beermonster 5y ago
        I know lots of software engineers that don’t even know what a shell is. Sadly.
        sundvor 5y ago
        Or Win10 with WSL2, however I guess that can be covered as *nix . I'll agree and further add that learning about the shell is essential knowledge building, just as touch typing is an essential skill to have, yet it's surprising how far one can get without. Learned early on both of these will just make your life easier as a SWE.
noway421 5y ago
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. Then the instruction becomes an easy 1 step task.
- TheRealPomax 5y ago
  "please lose your entire scroll buffer before this works, even though there's a way to use brew right now without doing that" isn't really going to win anyone favours. In cases like these: just ask the user what they want to do. > For brew to be available as command, brew needs to update your path and [bash/zsh/etc] profile. Please select how you wish to continue: > 1. Please do this for me > 2. Explain what you're about to do first, then ask me again. > 3. No thanks. I'll do this myself. And then you also make sure there's a runtime flag or even env var that can be used to override this, for admins who need to install brew as part of mass deploys.
  - a1369209993 5y ago
    > please lose your entire scroll buffer before this works FWIW, some variation on: $ exec bash ought to work, since what you care about is restarting the shell (.bashrc,PATH,etc), rather than the terminal per se.
- snug 5y ago
  or source your profile $ source ~/.zshrc
  - chisquared 5y ago
    Sorry, but I cringe every time I see someone suggest this. Startup scripts often aren’t idempotent, and it takes work to make sure they are. Please don’t source your startup script unless you know what you’re doing.
    - YetAnotherNick 5y ago
      Any examples of non idempotent script someone is likely to write? Because I can't think of much apart from doing some logging like 'user x logged at time y' which is likely to be fine to be written twice because it would be anyways if you open new terminal.
phendrenad2 5y ago
Solution: instead of that text-based installation instruction, show a link to a URL which guides them the rest of the way, with visuals.
- indigodaddy 5y ago
  That seems a bit overkill. A simple rewording of the instruction to make it clear would suffice. Something like “Run the following two commands, which adds the needful to your profile and current shell”
rubyist5eva 5y ago
The first line adds the brew setup to your shell startup file. The second line executes the same brew setup steps, but for your current shell so you can you start using brew right away. Both lines should be executed in your shell when you first install homebrew.
fouc 5y ago
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. 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.
- na85 5y ago
  > It's not compatible with keeping old versions of software installed. I'm sympathetic to the idea that sometimes software "updates" in fact introduce regressions, but there's a reason that one of the most universal traits among security professionals is "keeping automatic updates enabled". Surely the appropriate course of action is to fork a project rather than to just run outdated versions?
  - fouc 5y ago
    Automatic updates should be something that users make the choice to enable, it shouldn't be a default. Forced & default automatic updates have a long-term consequence of reducing fragmentation of the software landscape, ultimately leading to a reduction in the degrees of freedom for the end user. Developers love this, but on the flip side they're gradually losing personal control over their computers and operating systems and software as a result.
  - totallymike 5y ago
    The main exception being software for dev work, where you may need an older version of Postgres or some such
  - Doctor_Fegg 5y ago
    The problem with Homebrew is this: Let's say there's a small piece of software you want to install. A command-line PDF-processing utility, or something. You use brew to install it. brew decides to update everything. Let's say (not an arbitrary example) this includes OpenSSL. It removes the old OpenSSL. Everything you built which somehow depends on OpenSSL (and that's a lot of stuff) is now broken. If it was just Homebrew installs, that would be fine, because they'd be upgraded too[1]. But it isn't. It's everything you've built from source which linked against the former, Homebrew-installed OpenSSL. You now have to spend the rest of the afternoon rebuilding and reinstalling stuff because Homebrew decided to trash a library that it had previously installed... all because you wanted to install one tiny command-line tool. This has bitten me, and many others, countless times. Here's two examples from a minute's Googling about the OpenSSL issue: https://github.com/kelaberetiv/TagUI/issues/635 https://github.com/kelaberetiv/TagUI/issues/635, https://github.com/kelaberetiv/TagUI/issues/86 https://github.com/kelaberetiv/TagUI/issues/86. But it's far from an isolated case - I've had stuff break on me because brew has decided to upgrade proj, for example, and the newer proj headers aren't backwards-compatible. (Pretty much all open-source geo stuff depends on proj somehow.) In theory you can brew pin stuff. But either I brew pin everything, or I need a crystal ball to decide what brew will break next. OpenSSL? proj? Postgres? I honestly wouldn't have worked those out for myself. I am not installing Homebrew on any Mac I own in the future. [1] In theory. I've had Homebrew make an entire Postgres database unreadable due to an arbitrary, and unwanted, upgrade. Fortunately I was saved by recovering the old data files into Postgres.app, which can run different versions of Postgres.
pwrplus1 5y ago
> A surprisingly common error users make when installing Brew Installing Homebrew.
- beermonster 5y ago
  The alternative options are not without their own shortcomings
femto113 5y ago
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) # dedupe path set path = ( `echo $path | tr ' ' '\n' | perl -ne 'print $_ unless $s{$_}++;' | tr '\n' ' '` )
smoldesu 5y ago
I agree with the other commenter, this is just a blatant ad for a paid product. 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... ...Furthermore, I also remember seeing another Fig-related submission earlier in the month. It feels like I'm the target of a hyper-concentrated ad-campaign.
kms_2021 5y ago
I really appreciate the quick test to show whether this problem exists for you.
nxpnsv 5y ago
It might be a bit of a baity thing for fig, and I've never encountered this problem, but I guess to work as i signed up...
rectangleboy 5y ago
The most common error is installing Brew in the first place.
julienfr112 5y ago
Maybe create a developer licence that is required to launch the terminal ?
philo23 5y ago
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. 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.
j1elo 5y ago
This is not an error users make. It's an error that Brew makes, as a software: not taking the chance to, you know, work for the user instead of otherwise, as computing should do. 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.
- nerdponx 5y ago
  Eh. Conda does this, and it creates its own problems for end users. It's not an ideal solution.
lyptt 5y ago
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. 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.
- YetAnotherNick 5y ago
  > wanting to update itself and all installed packages each time you install a new package Whatt?? It updates itself(which you can stop by ^c and the installation proceeds without updating) which takes around a minute for me but definitely not all the packages only the dependencies. Not sure if the parent or me has something wrong in the configuration that our experience is so different.
  - lyptt 5y ago
    It's always been the case for me that it'll update everything I have installed, and won't let me proceed with installing a package until that finishes. No idea why, but it's obnoxious enough to make me never want to use it again.
icythere 5y ago
As discussed [1], please don't simply copy shell things without a stop;) [1] https://news.ycombinator.com/item?id=10554679 https://news.ycombinator.com/item?id=10554679
ngcc_hk 5y ago
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.
- ngcc_hk 5y ago
  For the job itself I wonder whether you can do a test first … eg instead of reading and analysis of dotfile create one .brewpath if file exist path should be there etc or even have a program to do this test and prompt user to run the script.

201 points by brendanfalk 5y ago

atian 5y ago

Is the http://localhost/fig.io?ref=github http://localhost/fig.io?ref=github link broken?

brendanfalk 5y ago
Whoops. Forgot to include the https in the link. That always gets me. Thanks for the heads up

irjustin 5y ago

Ah yes, the instructions should say "Run this in your console (Do not paste into file)" or similar. I really appreciate the quick test to show whether this problem exists for you.

jandrese 5y ago
In the old days it was common in documentation to prefix anything you were going to run with the prompt, just to make it obvious that it is a shell command. Like so: % echo 'stuff' >> ~/.zprofile If something had to be run as root the prefix was # instead, just like in Bourne Shell. Of course this makes it more difficult to copy and paste, you have to do each line one at a time.
- dylan604 5y ago
  this is actually something i never thought about. if you did copy the lines to be run as root with the preceding #, would it be interpreted as a comment and ignored? some sort of built-in safety from running blindly copied commands?
  - bewuethr 5y ago
    I once read that's the reason why the root prompt is #.
    - a1369209993 5y ago
      I can't speak for whoever came up with it originally, but that is the reason I retained that behaviour in my own shell, and it certainly sounds plausible.
  - irjustin 5y ago
    If nothing else, it would simply error.
- ddalcino 5y ago
  I’ve been involved with two different open source projects where, within the last couple of months, users have opened issues complaining about the shell prompts in the documentation, or PRs removing them, because it makes it too hard to copy-paste commands. The PRs were accepted over my objections. I was taught that you NEVER copy paste anything from the internet into a terminal. You learn what the commands do, and you type them yourself. Am I just old?
  - actually_a_dog 5y ago
    No, you were taught the right thing. You never know what some random JavaScript is gonna do to the contents of your clipboard when copying from a web page. Best practice, IMO, is to open as dumb an editor as you can find and pasting the commands into an editor buffer for inspection before running anything in the shell. And, if you don’t understand what it’s ask you to paste into your shell, don’t do it. Even if you run with JavaScript off entirely, this at least makes you think before you do anything potentially destructive.
  - pope_meat 5y ago
    What we're supposed to do, and what actually happens are different things. Especially in a situation where you're trying to install something just to get some other thing to work.
  - MattGaiser 5y ago
    In theory, yes you are right. In practice, I have deadlines and people wanting things and I often need to get things I don't understand up and running pretty quickly.
  - irjustin 5y ago
    Goals of focus and trust to gain speed. The sentiment makes sense locally, but at some point you either need to trust the thing you're working with or you do it yourself. There's not enough time in a day to "learn the commands yourself" for everything you do, but if you personally choose to learn and type the commands yourself, great! It's also okay to trust others with what you're doing. If you run brew, you literally are trusting other's install scripts not to do something malicious. (Seems ironic to run the brew command, but not trust the copy/paste it tells you to do?) Even if you don't run brew and install/compile the software yourself, you haven't read every line of code that the software is running to know if that's truly safe. It's not ideal, but you need to trust at some level or you're never going to move forward.

herpderperator 5y ago

If people don't even know what those commands mean, why are they even presented as a step? The installer could do both things for them.

jandrese 5y ago
I guess people get touchy when you start editing their startup scripts? I agree that it would be pretty easy for the installer to check and add the lines if they are missing.
- MereInterest 5y ago
  > I guess people get touchy when you start editing their startup scripts? I'm definitely one of those people. The startup script is my personal configuration, under source control and managed to set up an environment exactly how I want it. The very first thing I do on a new computer is clone that repo, so that I have my standard working environment available. It's definitely not a dumping ground for anything that has just been installed. > I agree that it would be pretty easy for the installer to check and add the lines if they are missing. But this is where it gets difficult, because that's in no way an easy thing to check. My .bashrc sources a .bashrc_local, so that I can have some computer-specific settings. It has conditionals, based on what tools are available on the current machine. Heck, some of the commands are generated by a python script, such as coloring the PS1 pseudorandomly based on the hostname, so I can tell at a glance which computer I'm ssh'ed into. (Side note, I definitely need to clean it out at some point, as it has definitely accumulated a lot of cruft over the years.) Determining if a particular script is sourced requires solving the halting problem. Granted, doing a quick grep for the name of the setup script is probably sufficient, but an installer shouldn't be editing my setup script even if it doesn't find anything.
  - pjerem 5y ago
    At least it could ask if you want it to add it for you. I’d answer yes, you’ll answer no and everybody would be happy.
  - 5y ago

herpderperator 5y ago

> 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. 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. The first command makes future shells have brew in their $PATH, the second command applies it for the current shell. 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.

brendanfalk 5y ago
Agree! I will update this. Good catch. Thank you!
deleted 5y ago
[deleted]
brendanfalk 5y ago
But also just to clarify, the intention for this post was how to fix this issue if it had already occurred NOT a "how to install brew correctly" guide. If the issue had occurred, you wouldn't need to run the eval command again, it would have already been run 1,000 times from your .zprofile. Hence I suggest just to delete all references of it then add back one. But I do take your point that my post could also have been seen as ambiguous and hence added in your suggested changes.

evanrelf 5y ago

This feels more like an advertisement for Fig than a genuinely interesting issue?

forgotmypw17 5y ago
I think it's about equally both.
- indigodaddy 5y ago
  Not exactly a great look for the fig employees though is it?
  - herpderperator 5y ago
    Not everyone has to be an expert on the shell to be good at their job.
    - indigodaddy 5y ago
      Shouldn’t a software engineer who lives in the Mac and/or *nix ecosystem, be competent in the shell? I understand that it’s not programming, but it just seems such a core and fundamental/base skill to understand this stuff. I agree the instructions are not clear enough, however. “Run the following two commands, which adds the needful to your profile and current shell” or similar would be a better way to put it.
      - beermonster 5y ago
        I know lots of software engineers that don’t even know what a shell is. Sadly.
      - sundvor 5y ago
        Or Win10 with WSL2, however I guess that can be covered as *nix . I'll agree and further add that learning about the shell is essential knowledge building, just as touch typing is an essential skill to have, yet it's surprising how far one can get without. Learned early on both of these will just make your life easier as a SWE.

noway421 5y ago

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. Then the instruction becomes an easy 1 step task.

TheRealPomax 5y ago
"please lose your entire scroll buffer before this works, even though there's a way to use brew right now without doing that" isn't really going to win anyone favours. In cases like these: just ask the user what they want to do. > For brew to be available as command, brew needs to update your path and [bash/zsh/etc] profile. Please select how you wish to continue: > 1. Please do this for me > 2. Explain what you're about to do first, then ask me again. > 3. No thanks. I'll do this myself. And then you also make sure there's a runtime flag or even env var that can be used to override this, for admins who need to install brew as part of mass deploys.
- a1369209993 5y ago
  > please lose your entire scroll buffer before this works FWIW, some variation on: $ exec bash ought to work, since what you care about is restarting the shell (.bashrc,PATH,etc), rather than the terminal per se.
snug 5y ago
or source your profile $ source ~/.zshrc
- chisquared 5y ago
  Sorry, but I cringe every time I see someone suggest this. Startup scripts often aren’t idempotent, and it takes work to make sure they are. Please don’t source your startup script unless you know what you’re doing.
  - YetAnotherNick 5y ago
    Any examples of non idempotent script someone is likely to write? Because I can't think of much apart from doing some logging like 'user x logged at time y' which is likely to be fine to be written twice because it would be anyways if you open new terminal.

phendrenad2 5y ago

Solution: instead of that text-based installation instruction, show a link to a URL which guides them the rest of the way, with visuals.

indigodaddy 5y ago
That seems a bit overkill. A simple rewording of the instruction to make it clear would suffice. Something like “Run the following two commands, which adds the needful to your profile and current shell”

rubyist5eva 5y ago

The first line adds the brew setup to your shell startup file. The second line executes the same brew setup steps, but for your current shell so you can you start using brew right away. Both lines should be executed in your shell when you first install homebrew.

fouc 5y ago

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. 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.

na85 5y ago
> It's not compatible with keeping old versions of software installed. I'm sympathetic to the idea that sometimes software "updates" in fact introduce regressions, but there's a reason that one of the most universal traits among security professionals is "keeping automatic updates enabled". Surely the appropriate course of action is to fork a project rather than to just run outdated versions?
- fouc 5y ago
  Automatic updates should be something that users make the choice to enable, it shouldn't be a default. Forced & default automatic updates have a long-term consequence of reducing fragmentation of the software landscape, ultimately leading to a reduction in the degrees of freedom for the end user. Developers love this, but on the flip side they're gradually losing personal control over their computers and operating systems and software as a result.
- totallymike 5y ago
  The main exception being software for dev work, where you may need an older version of Postgres or some such
- Doctor_Fegg 5y ago
  The problem with Homebrew is this: Let's say there's a small piece of software you want to install. A command-line PDF-processing utility, or something. You use brew to install it. brew decides to update everything. Let's say (not an arbitrary example) this includes OpenSSL. It removes the old OpenSSL. Everything you built which somehow depends on OpenSSL (and that's a lot of stuff) is now broken. If it was just Homebrew installs, that would be fine, because they'd be upgraded too[1]. But it isn't. It's everything you've built from source which linked against the former, Homebrew-installed OpenSSL. You now have to spend the rest of the afternoon rebuilding and reinstalling stuff because Homebrew decided to trash a library that it had previously installed... all because you wanted to install one tiny command-line tool. This has bitten me, and many others, countless times. Here's two examples from a minute's Googling about the OpenSSL issue: https://github.com/kelaberetiv/TagUI/issues/635 https://github.com/kelaberetiv/TagUI/issues/635, https://github.com/kelaberetiv/TagUI/issues/86 https://github.com/kelaberetiv/TagUI/issues/86. But it's far from an isolated case - I've had stuff break on me because brew has decided to upgrade proj, for example, and the newer proj headers aren't backwards-compatible. (Pretty much all open-source geo stuff depends on proj somehow.) In theory you can brew pin stuff. But either I brew pin everything, or I need a crystal ball to decide what brew will break next. OpenSSL? proj? Postgres? I honestly wouldn't have worked those out for myself. I am not installing Homebrew on any Mac I own in the future. [1] In theory. I've had Homebrew make an entire Postgres database unreadable due to an arbitrary, and unwanted, upgrade. Fortunately I was saved by recovering the old data files into Postgres.app, which can run different versions of Postgres.

pwrplus1 5y ago

> A surprisingly common error users make when installing Brew Installing Homebrew.

beermonster 5y ago
The alternative options are not without their own shortcomings

femto113 5y ago

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) # dedupe path set path = ( `echo $path | tr ' ' '\n' | perl -ne 'print $_ unless $s{$_}++;' | tr '\n' ' '` )

smoldesu 5y ago

I agree with the other commenter, this is just a blatant ad for a paid product. 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... ...Furthermore, I also remember seeing another Fig-related submission earlier in the month. It feels like I'm the target of a hyper-concentrated ad-campaign.

kms_2021 5y ago

I really appreciate the quick test to show whether this problem exists for you.

nxpnsv 5y ago

It might be a bit of a baity thing for fig, and I've never encountered this problem, but I guess to work as i signed up...

rectangleboy 5y ago

The most common error is installing Brew in the first place.

julienfr112 5y ago

Maybe create a developer licence that is required to launch the terminal ?

philo23 5y ago

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. 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.

j1elo 5y ago

This is not an error users make. It's an error that Brew makes, as a software: not taking the chance to, you know, work for the user instead of otherwise, as computing should do. 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.

nerdponx 5y ago
Eh. Conda does this, and it creates its own problems for end users. It's not an ideal solution.

lyptt 5y ago

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. 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.

YetAnotherNick 5y ago
> wanting to update itself and all installed packages each time you install a new package Whatt?? It updates itself(which you can stop by ^c and the installation proceeds without updating) which takes around a minute for me but definitely not all the packages only the dependencies. Not sure if the parent or me has something wrong in the configuration that our experience is so different.
- lyptt 5y ago
  It's always been the case for me that it'll update everything I have installed, and won't let me proceed with installing a package until that finishes. No idea why, but it's obnoxious enough to make me never want to use it again.

icythere 5y ago

As discussed [1], please don't simply copy shell things without a stop;) [1] https://news.ycombinator.com/item?id=10554679 https://news.ycombinator.com/item?id=10554679

ngcc_hk 5y ago

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.

ngcc_hk 5y ago
For the job itself I wonder whether you can do a test first … eg instead of reading and analysis of dotfile create one .brewpath if file exist path should be there etc or even have a program to do this test and prompt user to run the script.