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')
```