Fix windows compatibility regression of task dir keys
#644
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:\tooling-project-assets\"\" : 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
added
type: imperfection
per1234
added
topic: code
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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
dirkey 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
dirkey 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
dirkey, 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.