You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix windows compatibility regression of task dir key
The `dir` key can be used to specify an arbitrary working directory for the task.
This is used in npm-related tasks in order to provide support for projects that contain an npm project in a subfolder.
Taskfile variables are used for this purpose.
The template syntax used in Taskfiles is a bit problematic for use in YAML due to the fact that the template's
brace-wrapped format is also used by YAML's alternative "flow style" mapping syntax. This means it is necessary to use
syntax that explicitly defines values that consist only of a template as having a string type. That can be accomplished
through the use of quotes, but since the use of quotes is typically not required in YAML, they are generally eschewed,
and are instead only used in the shell code embedded in the tasks. For this reason, the alternative syntax of a "block
scalar" was chosen.
That approach worked at the time the system was established, and continues to work on POSIX machines. However, it seems
there was a change in the handling of the `dir` key on Windows in recent versions of Task. This causes the tasks that
used this approach to now fail spuriously:
```
task: Failed to run task "npm:install-deps": could not stat: CreateFile E:\arduino-lint\"\"
: The filename, directory name, or volume label syntax is incorrect.
```
There are actually two separate problems:
The first is the unnecessary wrapping of the value in quotes. Although wrapping paths in quotes is best practices in
shell code (in order to support paths that contain characters that would be problematic if unquoted, e.g., spaces), it
is not necessary in the `dir` key, which is not shell code and will correctly handle the unquoted path. On Windows, the
quotes are being interpreted as literal characters in the path rather than syntax.
The second is that the basic "literal block scalar" syntax (`|`) results in there being a newline at the end of the
value. This is also being interpreted as a literal character in the path.
The obvious solution to the first problem is the removal of the quotes, which were always superfluous. One solution to
the second problem would be to add the "block chomping indicator" (`|-`). However, since the the "block chomping
indicator" syntax is relatively obscure and not used elsewhere in the assets, it seems that the balance now shifts to
the basic "flow scalar" syntax being more clear and maintainable than the "block scalar" syntax.
0 commit comments