Hacker News Reader

Comment by asaph | Hacker News Reader

> Don’t try to install things with brew if brew is not installed:

   if which brew 2>&1 /dev/null ; then
        brew install jq
   fi

This just hides a useful error message (brew not installed). I would rather just see that error message (either interactively or in a log) and have the script fail. Hiding the error message just leads to an eventual failure down the road when jq is invoked.

View on HN

In bash, there is the build-in command named "command". I have used it for the same purpose, like in:

    command -v brew >/dev/null && brew install jq

If you don't care for maximum POSIX compatibility, i.e. your script is bash-specific, it's better to use "hash", which is going to ignore aliases (but not functions) and also has the benefit of caching the command for further use.

  hash foo &>/dev/null || { echo "foo command not found blabla..." >&2; exit 1; }

more info: https://stackoverflow.com/questions/592620/how-to-check-if-a...

Wow. It's impossible to google, and on MacOS, `man command` is useless.

$ help command

command: command [-pVv] command [arg ...] Execute a simple command or display information about commands.

    Runs COMMAND with ARGS suppressing  shell function lookup, or display
    information about the specified COMMANDs.  Can be used to invoke commands
    on disk when a function with the same name exists.
    
    Options:
      -p    use a default value for PATH that is guaranteed to find all of
            the standard utilities
      -v    print a description of COMMAND similar to the `type' builtin
      -V    print a more verbose description of each COMMAND
    
    Exit Status:
    Returns exit status of COMMAND, or failure if COMMAND is not found.

Thank you.

I never knew about help to describe a builtin shell command. normally searching for something like "command" in the bash man page would be very tedious.

also: help echo

i do think 'man command' should bring up the specific man page for this, so there is no need to search into the bash man. this works with most builtin shell commands. e.g. 'man ls' is a thing

On (at least) Debian systems (, and probably many more) `ls` is not a built-in, but an external binary (`/usr/bin/ls`) is used.

`which ls` and `help ls` will show you, if it is similar on your system.

It does't need to be a built-in to have a man page (many first party and third party libraries come with their own man pages).

"man command" on linux says "no manual entry for command"

"man echo" on linux describes /usr/bin/echo "help echo" describes the builtin.

on the othe hand, "man command" on mac os x gives a huge manpage of builtins (still hard to search for the common word "command")

How little we expect from our computers. "help <command>" should be the first thing you expect to work.

`command` is a bash builtin, not an external program. The information is in the bash man page (which is hard to find in there because the word "command" is in the man page 7 bajillion times. Look in the major section "SHELL BUILTIN COMMANDS" where you find `cd` and others like it).

You can determine if something is a bash built-in by using 'which command'. If it's built-in, man won't work.

In config.fish I use type for this purpose, together with the exit code

  test (type brew 2>/dev/null); and brew # blahblah

type -p also works in bash/zsh

Fish as well, but the redirection of both stdout and stderr is different:

  type -p brew >/dev/null ^&1; and brew

in Bash it would be:

  type -p brew &>/dev/null && brew

Using test avoids caring about stdout/stderr.

You don't need to check for `brew` in each task if they're run automatically. Just have one task that checks for `brew`.

With a proper dependency graph, the tasks installing things would depend on the task `brew-installed`.

This, of course, is leaving alone the point that installing stuff on startup is weird, doubly so with brew which is pretty slow.

Correction, to clarify: you need to check for `brew` in each task but not warn. One master warning is enough.

It seems you miswrote, or the author corrected himself. Right now it's:

  if which brew >/dev/null 2>&1 ; then
      brew install jq
  fi

Which would hide the error message. The code you posted outputs:

  brew not found
  /dev/null not found

It's impractical to determine whether Hacker New's undocumented formatting language is going to eat any given angle bracket ahead of time. I suspect OP wrote something correct and the site has mangled it.

It got messed up when I was trying to format it, unfortunately. But my point still stands.

I think this snippet needs some context. In all contexts that I can imagine, the first line should actually be

  if which jq &>/dev/null; then
    brew install jq
  fi

That seems more reasonable, but it's not what the author wrote. He precedes the snippet with "Don’t try to install things with brew if brew is not installed", so his intention does seem to be to swallow errors silently, which is definitely weird.

He might want his .bashrc to work on both macos and linux.

IME .bashrc already doesn't work the same on OS X, though, so that's still a weird reason.

Likely due to using the older version of bash preinstalled on Mac. Installing a new one and it should be virtually identical.

Reply on news.ycombinator.com