Why do string commands via `R -e ..` on Mac vs Linux requires an extra escape?

Question

This one stumped me. I have a simple shell script executing that works fine on my Linux (AWS aka CentOS) machine but crashed on my Mac OS X machine. It turned out escapes (\) in string commands needed an extra escape character (\\).

Could someone enlighten me as to what I am missing here -- ie, what is it about running the R scripts on Macs that require this?

The behavior was *not* observed when calling, say, python3 -c ..

On both machines, I am using bash, specifically /bin/bash

NOTE: The Mac is a slightly later version of R: 3.5.1 vs 3.4.1, but I would be strongly surprised if that was the culprit. Anyone available to confirm?

---

Simple Example:

R --vanilla -e 'cat(" Hello \n World \n ")'

The above runs fine on a CentOS machine, but requires an additional escape character (\\n instead of \n) to execute correctly. (example at bottom)

For reference/comparison, the following python command works identically on each of the Mac OS X, CentOS machines I tested.

python3 -c 'print("Hello \n World")'

---

---

For details, here is the output comparing the two commands on each of the two machines

1. R --vanilla -e 'cat(" Hello \n World \n ")'
2. R --vanilla -e 'cat(" Hello \\n World \\n ")'

1.

R --vanilla -e 'cat(" Hello \n World \n ")'

## CENTOS: 
> cat(" Hello \n World \n ")
 Hello
 World

## MAC OS X:
> cat(" Hello
+
+ Error: unexpected end of input
Execution halted

2.

R --vanilla -e 'cat(" Hello \\n World \\n ")'

## CENTOS: 
> cat(" Hello \\n World \\n ")
 Hello \n World \n >

## MAC OS X:
> cat(" Hello \n World \n ")
 Hello
 World

For comparison's sake, I'm not seeing the same behavior when running a simple python script.

## Each of these produce identical 
##  results in Mac OSX as CentOS

python3 -c 'print("Hello \n World")'
python3 -c 'print("Hello \\n World")'

---

---

Machine & Session Info:

1. Linux Box

> cat /etc/os-release
NAME="Amazon Linux AMI"
VERSION="2018.03"
ID="amzn"
ID_LIKE="rhel fedora"
VERSION_ID="2018.03"
PRETTY_NAME="Amazon Linux AMI 2018.03"
ANSI_COLOR="0;33"
CPE_NAME="cpe:/o:amazon:linux:2018.03:ga"
HOME_URL="http://aws.amazon.com/amazon-linux-ami/"

> R --vanilla -e 'sessionInfo()'
R version 3.4.1 (2017-06-30)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: Amazon Linux AMI 2018.03

Matrix products: default
BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_3.4.1

2. Mac OS Box

Mojave 10.14.3

> R --vanilla -e 'sessionInfo()'
R version 3.5.1 (2018-07-02)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS  10.14.3

Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_3.5.1

3. Another Mac OSX machine, running 3.4.3, same error

> sessionInfo()
R version 3.4.3 (2017-11-30)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS High Sierra 10.13.6

Answer 1

Following up on my suggestion that the cause of the problem could be the difference between macOS sed and GNU sed and Charles Duffy's suggestion as last comment on the original question I have tried calling the R executable directly on macOS Mojave 10.14.3 and with R 3.5.3 as follows in a shell script:

export R_HOME=$(R RHOME)
Rexec=${R_HOME}/bin/exec/R

$Rexec --vanilla -e 'cat(" Hello \n World \n ")'

And this will not give error messages and give the same output as on Linux.

In my opinion the issue is not a bug in bash but a regrettable difference between macOS (BSD) and GNU sed. I don't have a clue how this could be corrected in the R wrapper script, if possible.