error because of Non ascii account name in Windows

[jinlin82]

When having a Non ascii accout name in Windows system, for example echo %username% in CMD list a Chinese Account name, run quarto render hello.ipynb --to html will give an error:

Error running filter C:/quarto-0.9.446-win/share/filters/quarto-pre/quarto-pre.lua:
...arto-0.9.446-win/share/filters/quarto-pre/quarto-pre.lua:3420: attempt to index a nil value (local 'f')
stack traceback:
        ...arto-0.9.446-win/share/filters/quarto-pre/quarto-pre.lua:3384: in function <...arto-0.9.446-win/share/filters/quarto-pre/quarto-pre.lua:3377>

Pandoc has no problem. pandoc hello.ipynb -o hello.html is ok.

Quarto Version: 0.9.446

[jinlin82]

Maybe the reason for this error roots in path C:\Users\%username%\AppData\Local\quarto?
So I wonder can we make a portable quarto zip file, which will make C:\Users\%username%\AppData\Local\quarto just in quarto main directory?

[dragonstyle]

This is likely relate to the windowsANSI codepage, which we use when running LUA (for any lua file system operations). We inspect the system to try to determine the codepage to use in LUA and use this codepage when interacting with the filesystem. What is the codepage this environment is configured for? Can use this to determine:

Get-WinSystemLocale | Select-Object Name, DisplayName, 
                        @{ n='OEMCP'; e={ $_.TextInfo.OemCodePage } }, 
                        @{ n='ACP';   e={ $_.TextInfo.AnsiCodePage } }

I reproduce this when using non-ascii characters in paths using my windows installation's default ANSI code page of 1252.

You can install Quarto using a zip file (available here):

https://github.com/quarto-dev/quarto-cli/releases/tag/v0.9.466

Just be sure that the bin directory is in your path.

[jinlin82]

My windows installation's default ANSI code page(ACP) is 936.

Maybe the ACP is irrelevant to this error. On the same system, one account name is ascii, quarto is ok; another account name is Chinese, error happens. both acccouts have same ANSI code page(ACP) of 936.

even install Quarto using a zip file, when run quarto, directory C:\Users\%username%\AppData\Local\quarto is created, and because of %username% is non-ascii, so error happens.

[dragonstyle]

I think it would only be triggered by paths that contains characters unsupported by the codepage. My best guess is that somehow we're using the incorrect ACP (prob 1252) and as a result ascii paths are functional and non-ascii paths are non-functional. Let me investigate adding some debugging to help identify the code page we're using for file interaction in our filters.

[jinlin82]

In fact i just installed Qaurto in C root diretorory, C:/quarto-0.9.446-win, if the account name is Non-ascii, the error is:

Error running filter C:/quarto-0.9.446-win/share/filters/quarto-pre/quarto-pre.lua:
...arto-0.9.446-win/share/filters/quarto-pre/quarto-pre.lua:3420: attempt to index a nil value (local 'f')

if I i install Qaurto in a directorory which the path have non ascii character, if the account name is ascii, the error is:

Error running filter C:/中文/quarto-0.9.446-win/share/filters/init/init.lua:
cannot open C:/中文/quarto-0.9.446-win/share/filters/init/init.lua: No such file or directory

[jinlin82]

issue #1001 is very similar to the first error.
issue #1002 may has the same reason with the second error.

[jinlin82]

By the way, In my experience this non-ascii path error is common in many command line programs.

I appreciate your effort to investigate this.

[jjallaire]

@dragonstyle Are our init hooks for path encoding potentially not running here?

[dragonstyle]

Yeah that is one possibly that I'm investigating, though when I run locally they appear to be running. Also considering whether for some configuration of windows we're reading the codepage incorrectly...

[dragonstyle]

issue #1001 is very similar to the first error.
issue #1002 may has the same reason with the second error.

Thanks for suggesting, I suspect these issues are more likely to be related to unquoted paths in our bash scripts...