-
Notifications
You must be signed in to change notification settings - Fork 92
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
ANSIBLE_FORCE_COLOR can prevent extension from working correctly #373
Closed
Labels
bug
Something isn't working
Comments
The appropriate code to set and unset the values should go into the |
This bug should be closed only when we update ALS. |
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Jan 18, 2022
In order to avoid erroring parsing output on system where the user may have configured ansible to always use color, we inject an override of that option before executing external commands. This affects both ansible and ansible-lint. Related: ansible/vscode-ansible#373
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Jan 18, 2022
In order to avoid erroring parsing output on system where the user may have configured ansible to always use color, we inject an override of that option before executing external commands. This affects both ansible and ansible-lint. Related: ansible/vscode-ansible#373
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Jan 19, 2022
In order to avoid erroring parsing output on system where the user may have configured ansible to always use color, we inject an override of that option before executing external commands. This affects both ansible and ansible-lint. Related: ansible/vscode-ansible#373
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Jan 19, 2022
In order to avoid erroring parsing output on system where the user may have configured ansible to always use color, we inject an override of that option before executing external commands. This affects both ansible and ansible-lint. Related: ansible/vscode-ansible#373
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Jan 19, 2022
In order to avoid erroring parsing output on system where the user may have configured ansible to always use color, we inject an override of that option before executing external commands. This affects both ansible and ansible-lint. Related: ansible/vscode-ansible#373
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Jan 20, 2022
In order to avoid erroring parsing output on system where the user may have configured ansible to always use color, we inject an override of that option before executing external commands. This affects both ansible and ansible-lint. Related: ansible/vscode-ansible#373
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Jan 20, 2022
In order to avoid erroring parsing output on system where the user may have configured ansible to always use color, we inject an override of that option before executing external commands. This affects both ansible and ansible-lint. Related: ansible/vscode-ansible#373
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Jan 27, 2022
This makes runCommand automatically strip ANSI escapes from stdout and stderr, while still allowing user to opt-in for not stripping them. The reason for using stripping by default is that the primary use case for runCommand is to process the output and not to display it inside a terminal. This should prevent bugs where we fail to parse the output from various tools due to presence of ANSI codes. Related: ansible/vscode-ansible#373
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Jan 27, 2022
This makes runCommand automatically strip ANSI escapes from stdout and stderr, while still allowing user to opt-in for not stripping them. The reason for using stripping by default is that the primary use case for runCommand is to process the output and not to display it inside a terminal. This should prevent bugs where we fail to parse the output from various tools due to presence of ANSI codes. Related: ansible/vscode-ansible#373
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Jan 27, 2022
This makes runCommand automatically strip ANSI escapes from stdout and stderr, while still allowing user to opt-in for not stripping them. The reason for using stripping by default is that the primary use case for runCommand is to process the output and not to display it inside a terminal. This should prevent bugs where we fail to parse the output from various tools due to presence of ANSI codes. Related: ansible/vscode-ansible#373
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Jan 27, 2022
This makes runCommand automatically strip ANSI escapes from stdout and stderr, while still allowing user to opt-in for not stripping them. The reason for using stripping by default is that the primary use case for runCommand is to process the output and not to display it inside a terminal. This should prevent bugs where we fail to parse the output from various tools due to presence of ANSI codes. Related: ansible/vscode-ansible#373
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Mar 1, 2022
Closes: ansible/vscode-ansible#373 Closes: ansible#173 Closes: ansible#194
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Mar 1, 2022
Closes: ansible/vscode-ansible#373 Closes: ansible#173 Closes: ansible#194
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Mar 1, 2022
Closes: ansible/vscode-ansible#373 Closes: ansible#173 Closes: ansible#194
ssbarnea
added a commit
to ssbarnea/ansible-language-server
that referenced
this issue
Mar 1, 2022
Closes: ansible/vscode-ansible#373 Closes: ansible#173 Closes: ansible#194
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After a debugging session with @priyamsahoo we found what is preventing our extension from working correctly for some users.
If you happen to have
ANSIBLE_FORCE_COLOR=1
inside shell environment, user ansible.cfg or project specific config, it will break our extension, likely because we try to parse the output as JSON in one or more places without explicitly disabling the coloring on those commands.Our extension should work regardless how user configured that variable, or others.
The text was updated successfully, but these errors were encountered: