-
-
Notifications
You must be signed in to change notification settings - Fork 12
Fix windows compatibility regression of task dir
key
#950
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
@per1234
per1234
added
topic: infrastructure
Related to project infrastructure
os: windows
Specific to Windows operating system
type: imperfection
Perceived defect in any part of project
labels
Sep 14, 2025
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@ ## main #950 +/- ## ======================================= Coverage 83.33% 83.33% ======================================= Files 1 1 Lines 180 180 ======================================= Hits 150 150 Misses 19 19 Partials 11 11
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: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.