setting `output-dir: ./` will rm -rf the entire project

[petrelharp]

I have:

• searched the issue tracker for similar issues
• installed the latest version of Quarto CLI
• formatted my issue following the Bug Reports guide

Bug description

Suppose that I set up my _quarto.yml as follows:

project:
  type: website
  output-dir: ./

and then add a test.qmd:

---
title: "Untitled"
format: html
---

and then do quarto render.

Here's what happens:

1. the directory is rm -rf'ed.
2. a new directory with the same name is created, which has only a .quarto/ directory in it, nothing else.

In other words, this completely wipes the entire project. I tried this out, thinking naively that it might produce the html files living next to the qmd files. Happily, I tried this in a test directory.

Also, happily, setting output-dir: ../ does not wipe the parent directory. That's good.

Also - confusingly - setting output-dir: . instead of output-dir: ./ renders in-place, as I originally expected.

Steps to reproduce

mkdir test
echo '
project:
  type: website
  output-dir: ./
' > test/_quarto.yml
echo '---
title: "Untitled"
format: html
---' > test/test.qmd
cd test
quarto render
ls -la

Actual behavior

The result is

# ls -la
total 0

Expected behavior

The directory that we're in is not deleted.

Your environment

• OS: Debian Sid

Quarto check output

Quarto 1.8.26
[✓] Checking environment information...
      Quarto cache location: /home/peter/.cache/quarto
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.6.3: OK
      Dart Sass version 1.87.0: OK
      Deno version 2.3.1: OK
      Typst version 0.13.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.8.26
      Path: /opt/quarto/bin

[✓] Checking tools....................OK
      TinyTeX: (not installed)
      Chromium: (not installed)

[✓] Checking LaTeX....................OK
      Using: Installation From Path
      Path: /usr/bin
      Version: 2025

[✓] Checking Chrome Headless....................OK
      Chrome:  (not detected)

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
      Version: 3.14.0 (Conda)
      Path: /home/peter/micromamba/envs/ds435/bin/python
      Jupyter: 5.9.1
      Kernels: python3, ir

[✓] Checking Jupyter engine render....OK

[✓] Checking R installation...........OK
      Version: 4.5.2
      Path: /usr/lib/R
      LibPaths:
        - /home/peter/R
        - /usr/local/lib/R/site-library
        - /usr/lib/R/site-library
        - /usr/lib/R/library
      knitr: 1.43
      rmarkdown: 2.23

[✓] Checking Knitr engine render......OK

[petrelharp]

Also note #13623 which is not the same thing but in the same flavor.

[mcanouil]

See quarto render --help.

That's not a bug, that's a design choice.

[cderv]

In other words, this completely wipes the entire project. I tried this out, thinking naively that it might produce the html files living next to the qmd files. Happily, I tried this in a test directory.

First @petrelharp, let me says that I am sorry for what happens. This is bad behavior to me from Quarto.

That's not a bug, that's a design choice.

@mcanouil I would not put it exactly that way.

yes output-dir allows to set output directory, and yes quarto will delete output dir for clean state at each quarto render

However, I don't think we should allow setting output-dir: . and especially we should warn and not deleted which is (#13623), or for output-dir: . we could try even error.

This is to me an edge case that indeed users not aware of how output-dir works can do, and we should be less destructive about this.

So I'll reopen to think about it. Especially

Also - confusingly - setting output-dir: . instead of output-dir: ./ renders in-place, as I originally expected.

Seems to mean we do the right thing, but not detect ./

[petrelharp]

Thanks, @cderv.

That's not a bug, that's a design choice.

At first, I thought it might be. Clearly, deleting the output directory is a design choice. However, there is 100% no possible use case in which the desired behavior of output-dir: ./ is "delete the entire directory including the _quarto.yml in which this is specified. And it's a really super extremely bad thing to have happen to people on accident.

More generally - this is a meta comment, not about this bug, and I am not trying to start a long discussion here - I would be skeptical of design choices that leads one to defending behavior like this. (Also see #13623, which IMO is not the way to go.)

Anyhow, thanks for your hard work on quarto!