bash output causes trouble for Latex and hence no pdf

[nashjc]

I got some weird results when I tried to execute an inxi -F command in the bash engine. (inxi gives information on the current machine. I'm doing some comparative benchmarks).

The result from the Linux native terminal is quite a bit smaller than the rmarkdown ones. An Rmarkdown file is included below, stripped down from our working document. We can run the command in the native OS and then bring in the file, but it would be nice to have it run from within rmarkdown.

The knitr documentation says it uses bash -c and system2() command. I suspect there is some character encoding nonsense going on, and that isn't discussed in documentation as far as I can determine.

John Nash

---
title: "BashInR"
author:
  - John C. Nash, University of Ottawa, Canada
date: "26/05/2021"
output: pdf_document
---


```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE)
```

# Performance results for different computing environments

Here we present tables of the results, preceded by identified descriptions of the machines we
used.

M21-LM20.1 

```{r M21desc}
sessionInfo()
```

To get a good picture of the physical and logical machine that is M21-LM20.1, we can
run

```{r sys2}
system2("inxi -F >tlinux.txt")
```

in a command line terminal in the host machine. 

While it may be tempting to run either

```{r runinxi}
system('inxi -F >t.txt')
```

or 

```{bash inxi2}
inxi -F >t2.txt
```

it turns out that the encoding of the files is different. Indeed
the files are different sizes!

```{bash ls-t}
ls -al t*.txt
```

```{r s2}
 system2("inxi", "-F", stdout="tlinux2.txt")
```

This tries to read the file created by the linux OS directly. It will fail unless a file of the correct name is present.

```{r M21disp}
cat(readLines('tlinuxOS.txt'), sep = '\n')
```

[nashjc]

This issue appears to be outside rmarkdown and related to the character encodings used by "terminal" programs.

I can get a workable output as follows (and welcome comments on how to do this more simply!):

1. I put the command inside a script that runs the (old-fashioned) shell 'sh':

#!/bin/sh
inxi -F >../tlx.txt
echo "done!"

2. Then in my rmarkdown script, I put in a section

system("mate-terminal -e ./inxirun.sh")
cat(readLines('../tlx.txt'), sep = '\n')

(For info: the file it put in the directory above to avoid it polluting a version controlled local repo.)

This does not cause knit to choke. I have also tried xterm and konsole besides mate-termina.

JN

[yihui]

If the #!/bin/sh approach works, you should probably use the sh engine instead of bash, because the two are not necessarily equivalent (depending on your OS, sh can point to other shells, not necessarily bash, such as zsh or dash).

@nashjc

The result from the Linux native terminal is quite a bit smaller than the rmarkdown ones.

If using the sh engine does not work, is it possible for you to share the two different t*.txt output files? From your description, I don't know what the specific differences are (other than that one file is smaller than the other).

[nashjc]

As Yihui notes, the terminal and shell choices of particular distros (and versions even) may vary.

My current opinion is that it is likely best to try first with 'sh', since it seems to be a proxy for the most vanilla shell program, and to invoke this via the native OS terminal using
system("terminalprog -e pathtoashellscript")

Note that I am less interested in the vagaries of the output than in having my rmarkdown knit successfully. And this need is rather specialized -- we are trying to benchmark some code for the ImproveNLS Google Summer of Code.