Brew: chown command differ under fish, don't need $ infront of parenthesis expanding

[ghost]

Bug reports:

After running Onyx, I got this message:

Error: /usr/local is not writable. You should change the ownership
and permissions of /usr/local back to your user account:
  sudo chown -R $(whoami) /usr/local

Propose a feature:

I use fish shell, and the the correct command would be: sudo chown -R (whoami) /usr/local without the $. Can the correct version be printer when running under fish?

[UniqMartin]

We have a lot of similar output in many different places across all of Homebrew and all of it is written from the perspective of a sh (or compatible shell) user, which probably represents the majority of our users due to Bash being the default on macOS. I'm not sure how feasible it is for us to make all of this output context-sensitive and I'm not even sure if we have a reliable way to detect the user's shell. But let's leave this open and see how other maintainers feel about this …

[DomT4]

Crossposting myself: https://github.com/Homebrew/brew/pull/481#issuecomment-233145513

[ghost]

@DomT4: Valid 👍

[apjanke]

I agree with Martin and Dom's concerns here. I think we should probably stick with Bourne style shell snippets, and let non-sh-compatible users translate. It'd be a good amount of work, and we'd only be gaining a convenience, and for probably a small proportion of Homebrew users.

We could do the detection: that's already done when picking what shell configuration file (e.g. ~/.profile or ~/.zshrc) to tell users to edit in the caveats. (Though I don't think it's 100% reliable, and probably can't be, due to the variety of scenarios brew might be invoked under.)

But it'd be work, and would make the caveats less readable for developers and sh users. (If we did fish, we should probably include tcsh, ksh, and zsh as well, which might differ. And I don't think we have experts in fish or other shells besides bash and zsh.) And if we didn't get it 100% (for both shell detection reliability, and coverage of code snippets to be translated), then you still might have the odd case where the user gets presented with a snippet of shell code, and they have to wonder whether it's been correctly "localized" for their shell, or if it's defaulted back to bash and needs to be translated. So they'd have to examine the code for syntax clues anyway.

Since most of the shell code examples out in the wild seem to be sh/bash, users of "alternative" shells like fish and csh are probably used to having to translate anyway; it's part of the price of admission. Seems like it would keep things simpler to do things that way in brew, too.

Automating the translation would make it easier and maintain readability. We could just do all the code snippets in bash and mark them up as shell code, and use a translation library to mechanically convert them to other shells. But that would require taking another vendored dependency, which we've pretty much tried to avoid.

[MikeMcQuaid]

I agree with Martin and Dom's concerns here. I think we should probably stick with Bourne style shell snippets, and let non-sh-compatible users translate. It'd be a good amount of work, and we'd only be gaining a convenience, and for probably a small proportion of Homebrew users.

Agreed.