override tex-file without asking

[Codeberg-AsGithubAlternative-buhtz]

I tested something around and used that line to generate the tex-file

R -e 'library(knitr);knit("myfile.Rnw")'

But the problem is that myfile.tex was still there and it was a very nice weeks of work document that is now overriden. There was no error no warning.

Of course I have backups but I lost some hours of work.

[yihui]

Sorry to hear about that. It is the first time over the four years of knitr's history that I have heard about it, though. I guess it would be too much trouble if knitr asks every single time before it writes the output file. It cannot tell if a foo.tex is the output of foo.Rnw or just a completely different tex file. I understand it was a very expensive lesson for you to learn (don't name two files with the same base filename if they are supposed to be different files after all), but I guess there isn't much I can do here. Sorry.

[Codeberg-AsGithubAlternative-buhtz]

You as the dev have a lot of options:

• don't make this the default behaviour (there should be explizit option override-without-asking)
• if it is the default behviour
  • create a a warning message and a bak-file (myfile.tex.bak)
• there is no need to let knitr "ask". it would be against the interface-concept of it. But e.g. there should be a better warning about that in the documentation

Me as a developer I would never implement such an unpolite behaviour in one of my programms.

[yihui]

The documentation ?knitr::knit has stated this:

[...] the filename of the output document is determined in this way: ‘foo.Rnw’ generates ‘foo.tex’ [...]

foo.tex is the output of foo.Rnw, and users are supposed to work with (and only with) the source document foo.Rnw. I think the vast majority of users start with foo.Rnw, and you happen to have started backwards on this way. It is so rare, but I agree it is unfortunate and super annoying when it happens. I'm not sure if this is an appropriate analogy: one can do rm -rf /usr /foo but apparently he/she most likely does not mean to remove /usr but /usr/foo instead, and the careless space ruined everything. You may argue rm should backup the files when deleting them or let users set an option or give users a warning when /usr is deleted, but I don't think that will ever happen.

Let's try not to bring politeness into the argument. It is hard to continue the discussion when we start evaluating morality of other people. I may well say it is not polite to blame the author after calling a command when you don't understand its consequence, but that is meaningless and does nobody any favors.

Yes, I can add the options you mentioned, and they make a lot of sense to this specific case. The question is how much weight I should put on this case. I tend to believe I do not need to change the default behavior. I understand it does not appear to be fair from your point of view. Again, sorry about your loss of hours of work.

[Codeberg-AsGithubAlternative-buhtz]

I see your point and of course you can close this bug-report without fixing it because you are the maintainer. And I see that my solutions of this bug are against the knitr-concept.

1. I think that is one of the problems here that I (and as you can see in the search engines) a lot of other users try to use knitr against its origin concept. We want to use knitr as a sub-component of our tex-environment. The main document-file should be a tex-file and in there we only include/import the knitr-related files. But this is not the concept of knitr and only possible with some workarounds/hacks. That is one of the big conceptual problems of knitr that it stays on top of the whole tex-environment. You have to work with knitr-files and not with tex anymore. But you made the concept.
2. Compare rm with knitr doesn't work. The job of rm is to delete files (better: remove inodes from the filesystem). The job of knitr is to generate tex-files out of Rnw-files - not more. You see?
   You as a developer can not give the whole responsibility to the user. When your software delete/override files and that is not a main-part of its job, than you are responsible for that. The ball is on your side. Give up the responsibility is to easy here.

[ramnathv]

I would have to disagree here. knitr supports multiple document formats and you are not restricted to working with .Rnw files. In fact, if you prefer keeping everything in a .tex format, you can author documents in tex with the extension .Rtex and I believe, it will build the .tex and .pdf files.

Having worked with knitr a lot, I can say that it is one of the most well designed tools I have encountered. It packs a lot of power and flexibility. So, I would strongly recommend that you at least take the effort to read the documentation, before making comments that are way off.

[yihui]

I was not comparing rm to knitr, but the careless (and disastrous) space in the example to your loss of the tex file (i.e. "how could one possibly want to delete /usr and why doesn't rm warn me since that is apparently a mistake?!" vs "how could you overwrite my tex file without warning me?"). Mistakes and misunderstandings always happen. One concept that looks natural in one person's eyes can be totally nonsense to another person. You may not like my design. That is all fine. I'm making the decision based on my observations, and I could well be wrong.

[Codeberg-AsGithubAlternative-buhtz]

The knitr-manual is only 11 pages with a toc. And with a string search I can not find "Rtex" in there. Where can I read something official about "Rtex" and how this can work?

[yihui]

I don't think Rtex is widely used (most people use Rmd or Rnw). A google search of knitr + Rtex can be more informative than the manual. If you really want to know everything, there is a 300-page book "Dynamic Documents with R and knitr" published by Chapman & Hall.

Anyway, Rtex is just different in the syntax of writing R code chunks. It does not prevent your tex file from being overwritten, either.

[Codeberg-AsGithubAlternative-buhtz]

I wonder what Rtex is when it is not in the official documentation.
What I can find about it indecates that it is the same old knitr-workflow. First I have to call knitr() on an Rtex file and then call xetex on the generated(!) file.
A integrate-R-in-latex-solution should only generate sub-tex-files which I can integrate in my own main-tex-file with a simple import.

[yihui]

Closing this issue since this is by design (you go from .Rnw to .tex; not the other way around). Sorry.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.