Project not working correctly after overriding output name

[reavesjo]

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

I am trying to put the Quarto render of a .qmd file into a folder underneath "output", preserving the same file structure. I can accomplish this using a project file. However, using the -o option to assign the result a different name results in the output file going to the wrong place.

Steps to reproduce

This circumstance requires a few folders, so you can access it at https://github.com/reavesjo/temp. The ref-commands.txt file demonstrates what I have run to test this bug. This bug at very least appears for pdf and html output.

Actual behavior

quarto render stuff/file.qmd --to pdf -o test.pdf produces test.pdf under ./output/.

Expected behavior

quarto render stuff/file.qmd --to pdf -o test.pdf would ideally produce test.pdf under ./output/stuff/, as with quarto render stuff/file.qmd --to pdf.

Your environment

I am on Windows 11, using Git Bash as the terminal, though the same behavior is exhibited using R's quarto library.

Quarto check output

$ quarto check
Quarto 1.8.14
[>] Checking environment information...
      Quarto cache location: C:\Users\reavesjo\AppData\Local\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.14
      Path: C:\Users\reavesjo\AppData\Local\Programs\Quarto\bin
      CodePage: 1252

[>] Checking tools....................OK
      TinyTeX: (external install)
      Chromium: (not installed)

[>] Checking LaTeX....................OK
      Using: TinyTex
      Path: C:\Users\reavesjo\AppData\Roaming\TinyTeX\bin\windows\
      Version: 2025

[>] Checking Chrome Headless....................OK
      Using: Chrome found on system
      Path: C:\Program Files\Google\Chrome\Application\chrome.exe
      Source: Windows Registry

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

[>] Checking Python 3 installation....(None)

      Unable to locate an installed version of Python 3.
      Install Python 3 from https://www.python.org/downloads/

[>] Checking R installation...........OK
      Version: 4.5.0
      Path: C:/Users/reavesjo/AppData/Local/Programs/R/R-4.5.0
      LibPaths:
        - C:/Users/reavesjo/AppData/Local/Programs/R/R-4.5.0/library
      knitr: 1.50
      rmarkdown: 2.29

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

[mcanouil]

Please use the discussion board for help request.
Issues are for bug reports.

Converting this to a discussion.

[mcanouil]

The ref-commands.txt file demonstrates what I have run to test this bug.

There is nothing in it.

[reavesjo]

Apologies, this should be fixed now.

[mcanouil]

FYI, you can set the output-file name in your frontmatter and it will lead to the expected result:

format:
  pdf:
    output-file: test.pdf

As I'm pretty sure the current behaviour from the CLI is the expected behaviour.

quarto render stuff/file.qmd --to pdf -o test.pdf produces test.pdf under ./output/

[mcanouil]

Could you elaborate on the exact use case?

For reference:

• Output directory in quarto-cli #2171

and

• Epic: Execution Planner #6518

[reavesjo]

I want to have "draft" versions of reports--which use the output-file argument in the YAML--but also be able to create date-stamped "final" versions of said reports by specifying the output file name. I would like those files to end up in the same place (which is not the same directory as the scripts, so as to have a smaller .gitignore file), so that I know where to find things when files are finished rendering. Specifically, we are using quarto documents to render other documents using the R quarto library, but this behavior is exhibited (and obviously well-documented) in the CLI.

I had spent some time looking at #2171 previously, and I'm aware of the necessity of using child filepaths in --output-dir and the basic workaround of moving the files after creation. That is currently part of our workflow.

That said, I reported this as a bug (like #2375) because it does not seem intuitive to me that changing the output file name results in the file ending up in a different directory. If it's expected behavior, am I misunderstanding what --output-file does? Or perhaps what project files do?

[mcanouil]

Without answering whether this is a bug or not, I believe our path behavior in metadata vs path behavior in CLI options is supposed to be:

• relative paths in metadata are relative to the document
• relative paths in CLI options are relative to the directory where the command was invoked

This would be consistent with the current behaviour.

[mcanouil]

@reavesjo In your case, it would mean:

instead of:

quarto render stuff/file.qmd --to pdf -o test.pdf

do:

cd stuff; quarto render file.qmd --to pdf -o test.pdf

[cscheid]

Ok, great. So this is intended behavior.

Consider the following situation:

$ quarto create project website
...
$ mkdir subdir
$ echo 'hello' > subdir/hello.qmd

Now imagine the following possibilities:

• $ quarto render subdir/hello.qmd --output hello.html
  

• $ cd subdir
  $ quarto render hello.qmd --output hello.html
  

• $ cd subdir
  $ quarto render hello.qmd --output ../hello.html # note, this is disallowed
  

• $ quarto render subdir/hello.qmd --output subdir/hello.html # note, this is disallowed
  

The current semantics tries to make it clear how the path to hello.qmd relates to the --output path: they're both related by the current working directory. Any other semantics would mean that changing the hello.qmd file will affect the computation of the --output path. That's confusing and error-prone.

[cscheid]

If you're in a unix shell and are worried about mutating the current working directory, you can wrap the cd command in parentheses, like the following trick:

$ (cd subdir; quarto render hello.qmd --output hello.html)

[cderv]

What I remember about past investigation on related issue is that

• --output CLI flag is designed initially to be mapped to --output / -o Pandoc's CLI flah
• output-file YAML configuration is not the same and is handled directly by Quarto in outputRecipe

So, as confusing as this is, they are not equivalent and not configured to do the same. Not saying this is not to be improving - just stating the current situation.

Why do we have a case where command arg is passed to pandoc directly ? I am not sure to remember exactly.