How to squelch sh errors from imported bash functions?

Question

So I've got a .bash_aliases file with many exported bash functions inside; a good deal of which are incompatible with sh...

The problem is that sh is used all over my laptop (OS X) and linux machines that I ssh into. In addition it always tries to import my bash functions and spams errors.

The functions in question are:

• all of my functions that have a '-' in their name (NOTE: these only spam errors on OS X, not linux)

• and a log() function (below) with syntax that is only legal in bash

  log() {
      # braces allow for piping of same output to multiple files
      { $@ 2> >(tee .err.log); } &> >(tee .out.log);
      echo; echo logged output to .err.log \& .out.log respectively;
  }
  export -f log
  

So how can I solve this problem? I'd prefer it if I didn't have to rename the functions or put them in separate scripts inside a */bin directory...

Thanks for the help!

P.S. screenshot:

EDIT: I see I didn't include enough info. So yes .bash_profile does source .bashrc which in turn sources .bash_aliases (I have no .profile). In addition I have already tried to create an exit clause in .bash_aliases when $SHELL='sh' but it didn't work which is because they are being imported directly from my environment (as @Bodo and the import errors in screen cap indicate).

EDIT2 IMPORTANT: Also strangely I just found out that in the linux machine that I ssh into /bin/sh is a symbolic link to bash. Which means that bash although throwing no errors when sourcing log() actually does throw errors when importing it from the environment??

Answer 1

You should not export the functions. Instead I suggest to source .bash_aliases for all bash instances that need it. (I guess you need the functions in interactive bash shells only.)

A similar problem is mentioned here: /bin/sh: error importing function definition for `some-function', where the accepted answer proposes to rename the functions.

You see the errors even if /bin/sh is linked to bash on your system, because when bash is called as sh, it tries to behave like sh and to comply with POSIX, see https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html#Invoked-with-name-sh

Answer 2

The simple solution is to not source them. Since ~/.bash_aliases isn't a standard file, you must be explicitly sourcing it in one of your config files. So an easy solution would be to find the line that source it (most likely in your ~/.bashrc) and change it from this (or whatever your system has, this one is from Ubuntu):

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

To this:

if [ -f ~/.bash_aliases ] && [ -n "$BASH_VERSION" ]; then
    . ~/.bash_aliases
fi

That way, the .bash_aliases file will only be sourced when running bash.

---

To clarify, what I am assuming is happening here based on the information in your question and comments, is the following:

1. You are sshing into a machine.

2. Because you are sshing into it, this launches the default /bin/sh as a login shell.

3. Since this is a login shell, it will source ~/.profile.

4. Because your .profile is set up to source ~/.bashrc (again, not standard, but common), you now read .bashrc although you might not be running bash.

5. Since your .bashrc is set up to source ~/.bash_aliases, you read that file too and that produces the errors.

Yet another reason why I personally am not a fan of the decision some systems have made to make the default ~/.bashrc source ~/.profile.