Q:

How to determine which '\' is causing error?

I'm working with a Makefile with a target that's missing a recipe, and its causing a make to fail. I'm trying to patch a Makefile using sed in a bash script, and sed is failing claiming problems around a \. The script provides the recipe to download, untar, patch and build the sources.
The idea is to see if a recipe is present for lldbPluginSystemRuntimeMacOSX.a, and add it at a particular location if its not found. So the recipe needs to be added with a leading tab and a trailing slash.
When the following executes:
# Determine if Apple
IS_DARWIN=`uname -s | egrep -i -c "Darwin"`
if [ $IS_DARWIN -ne 0 ]; then
  OTHER_OPTIONS=" --enable-libcpp"
fi

# Fix LLDB on OS X
if [ $IS_DARWIN -ne 0 ]; then
  cp Missing-Makefile llvm/tools/lldb/source/Plugins/SystemRuntime/MacOSX/Makefile
  chmod a+x llvm/tools/lldb/source/Plugins/SystemRuntime/MacOSX/Makefile

  COUNT=`cat llvm/tools/lldb/lib/Makefile | egrep -i -c lldbPluginSystemRuntimeMacOSX`
  echo *****COUNT: $COUNT*****

  if [ $COUNT -eq 0 ]; then
    sed -i '' "97i \tlldbPluginSystemRuntimeMacOSX.a \\" llvm/tools/lldb/lib/Makefile
  fi
fi

The snippet outputs the following error:
*****COUNT: 0*****
sed: 1: "97i \tlldbPluginSystemR ...": extra characters after \ at the end of i command

Note Well: I am on OS X, and that means sed is not BSD sed, and its not Linux sed. OS X is its own world.
I'm having trouble zeroing in on the exact problem. I've tried adding three slashes to the tab per Using sed to insert TABs, but that causes a similar error with two slashes. I also tried Nunk's suggestion of 2 slashes with no joy. It appears guessing at a problem is not the best approach.
The best I can tell, there is no verbose mode or other ways to get detailed information from sed on OS X.
QUESTION: How do I determine which \ is causing the problem? Is it even possible to determine the problem slash?

A:

You do in fact need an actual literal newline.
I often use the cat debugger :-) or sometimes a more advanced vis version  (e.g., vis -w does the trick on MacOS) to see what the input looks like, but in this case you need to inspect arguments rather than stdin, which makes it trickier.  Fortunately echo "$@" | vis ... is sufficient here:
  sed -i '' '97i\ 
TABCHARlldbPluginSystemRuntimeMacOSX.a \\ 
' llvm/tools/lldb/lib/Makefile

becomes:
echo '97i\ 
TABCHARlldbPluginSystemRuntimeMacOSX.a \\ 
' llvm/tools/lldb/lib/Makefile | vis -w

which, fed to an sh (plain old sh, don't really need bash here) instance, gives me:
sh-3.2$ echo '97i\ 
> TABCHARlldbPluginSystemRuntimeMacOSX.a \\ 
> ' llvm/tools/lldb/lib/Makefile | vis -w
97i\\\040\^JTABCHARlldbPluginSystemRuntimeMacOSX.a\040\\\040\^J\040llvm/tools/lldb/lib/Makefile\^Jsh-3.2$

which is not very readable, but does show that the backslash newline here had a space after it (that's the \040 shoved in between the \\ and \^J).  Removing it would make sed be OK with this, as long as that's actually what gets through.
Given a modern shell, you can encode stuff readably using $'...':
sh-3.2$ echo $'magic: i\\\n\tstuff' | vis -w
magic:\040i\\\^J\^Istuff\^Jsh-3.2$ 

(remember, literal backslash is encoded in vis output as \\, literal newline is \^J, and literal tab is \^I).
Remember also that echo adds a newline, and sed does not, so you probably want something more like:
sed -i '' $'97i\\\n\tnew indented line inserted\n' Makefile

here.

