As of November 2017 VSCode allow to pipe output directly to VSCode. I did tried with a few command until I got a bunch of ANSI codes which I'm not interested.
I'm running something like yarn info babel-core | code and getting this:
yarn info v0.24.6
{ name: [32m'babel-core'[39m,
description: [32m'A placeholder package that bridges babel-core to #babel/core.'[39m,
[32m'dist-tags'[39m:
{ latest: [32m'6.26.0'[39m,
old: [32m'5.8.38'[39m,
next: [32m'7.0.0-beta.3'[39m,
bridge: [32m'7.0.0-bridge.0'[39m },
I would like to that output without these ANSI codes.
If you NodeJS then you can globally install strip-ansi-cli which provides you the command: strip-ansi. It does exactly that.
For your case, you may use it as follow:
yarn info babel-core | strip-ansi | code
Happy coding!
Alternatively, plugins now exist, e.g. ANSI Colors, that once installed enable you to select ANSI text as the file's "language mode." You can then use VS Code's _Command Palette_ (Ctl-Sft-P) to preview the file (ANSI Text: Open Preview) with escape sequences respected, i.e. in color (and etc.)
Credit
Can I display a file with ANSI color escape sequences in Visual Studio Code?
Related
I am using VScode for writting shell scripts.
I specify the language of the script on VS Code and I am already enjoying the rest of the formatting.
I would like the options of my commands (that would be everything starting with one dash "-" or two dashes "--", including the dashes) to be formatted in a peculiar color for reading convenience.
Example:
example -in $file -out output.txt -mode 5 --force
I would like -in, -out, -mode and --force to all have a similar color, not a color already used in the usual shell formatting in VScode.
Screenshot of the current code in VS Code:
Working with .sh files on Windows causes issues when running them in Linux Docker containers if they have EOL of CRLF. Can I make VS Code always work with LF for specific file type such as .sh while still using CRLF for all others?
I only find "files.eol": "\r\n" in settings, but this is global.
I understand you can change this in the bottom toolbar on a per-file basis, but I would like this to be the default for all .sh files.
In your settings window, go to
Settings > Text Editor > Files > Eol option. You'll fine following available options there
- \n
- \r\n
- auto (default)
Here \n represents LF, \r\n represents CRLF, and auto use the operating system specific EL operator.
Select your option and save.
VS Code: version 1.13.3
You can use EditorConfig.
Install the editorconfig extension, and then add a .editorconfig file at the root of your project with this:
[*]
end_of_line = crlf
[*.{sh}]
end_of_line = lf
But as #axiac said, I would recommend to always use lf...
EDIT : I was a bit "premature" with this answer. But it now works as of v1.40. See https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_40.md#fileseol-per-language
You can do this in vscode without an extension. You can make a language-specific setting:
In the command palette, search for "Configure language specific", select it and choose "shellscript" from the language options:
This will create the following in your settings:
"[shellscript]": {
},
Now add in whatever you want to apply to shellscript files only like (not all settings will work in there but most do):
"[shellscript]": {
"files.eol": "\n"
},
VERY, VERY IMPORTANT:
The end-of-line sequence is used for new files. For existing files,
the existing end-of-line sequence is always preserved. To change the
end-of-line sequence for an existing file, use the Change End Of Line
Sequence command.
from https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_40.md#fileseol-per-language
Edit: Note this is an older question, from a time when AWS CLI was v1 - as noted in comments, there are other likely better solutions with v2
I'm using AWS CLI on Windows to query items from DynamoDb. Some of these items include non-ASCII characters.
When the query hits those items, it dies with an error
'charmap' codec can't encode character u'u010d' in position....
After hours of searching, I finally stumbled across a hackish workaround; under the AWSCLI\encodings directory, I copied utf_8.pyc over cp1252.pyc. This allows me to continue, but of course is ugly.
Before resorting to that, I also tried setting environment variables such as LANG, LC_ALL, LC_CTYPE to various permutations of en-US.UTF-8 or similar, all with no effect that I could see.
Does anyone know how (or is it even possible) to tell AWS CLI to use a particular encoding?
Since you're using the command line interface, a change to the terminal's encoding scheme should fix the issue.
Type:
chcp 65001
in the console (for UTF-8; you may also try different encodings) and retry your operations.
Maybe it could help as well - the issue with translation from AWS and storing results to the file (or powershell variable):
With error:
aws translate translate-text --text "Investigation" --source-language-code "auto" --target-language-code "PL" >> a.txt
'charmap' codec can't encode character '\u015a' in position 1: character maps to
Adding env. variable fixes the problem
set PYTHONIOENCODING=UTF-8
aws translate translate-text --text "Investigation" --source-language-code "auto" --target-language-code "PL" >> a.txt
The same in powershell:
PS C:\Users\???\Documents> $aws = aws translate translate-text --text "Request" --source-language-code "auto"--target-language-code "PL"
'charmap' codec can't encode character '\u015b' in position 4: character maps to <undefined>
PS C:\Users\???\Documents> exit
C:\Users\???\Documents>set PYTHONIOENCODING=UTF-8
C:\Users\???\Documents>powershell
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
PS C:\Users\???\Documents> $aws = aws translate translate-text --text "Request" --source-language-code "auto"
--target-language-code "PL"
PS C:\Users\???\Documents> $aws
{
"TranslatedText": "Prośba",
"SourceLanguageCode": "en",
"TargetLanguageCode": "pl"
}
I've reinstalled AWS CLI using upgraded MSI installers which now use Python 3 instead of Python 2 and the unknown encoding error is now gone.
I am using git bash on windows 10 and set PYTHONIOENCODING=UTF-8 was not actually did env change. Used export PYTHONIOENCODING=UTF-8 then overcame the charmap error
for Windows 10 and cli is installed by python
Error:
'charmap' codec can't encode characters in position XX-XX: character maps to
Solution: run following command in command-line
set PYTHONIOENCODING=UTF-8
I have a similar question to this:
ColdFusion, CFDirectory and the French
which was not given a satisfactory answer.
We have upgraded from Coldfusion 9 to Coldfusion 11. So far no major problems except the following:
When using CFdirectory to display file names that contain non ASCII characters in their names (eg: accents, umlauts) we get to see the file name with replacement characters � instead of the correct UTF equivalent. For example a file named L’État, c’est moi.pdf is displayed as L�����tat, c���est moi.pdf.
We are confident that this is a Coldfusion issue as nothing has changed but the Coldfusion version. With Coldfusion 9 CFdirectory worked OK when listing the same accented filenames. Our OS is Redhat 7.0 and the file names are also displayed correctly on the terminal with the ls command. I have also created a quick PHP script to see if PHP can read correctly the directory with the "readdir" command and there no problems there either, filenames are rendered correctly.
So I believe this has to be a Coldfusion 11 issue. I have added the -Dfile.encoding=UTF-8 -Dencoding=UTF-8 parameters in the JVM settings from the Coldfusion administrator server interface but it made no difference.
Any suggestions on how to rectify this would be appreciated.
example of code used follows:
<cfdirectory
action="list"
directory="#ExpandPath( './' )#/pdfs"
listinfo="name"
name="qFile"
/>
<cfdump
var="#qFile#"
label="All Files"
/>
Have you tried setting the cfprocessingdirective tag?
<cfprocessingdirective pageencoding="utf-8">
CF 11 WikiDocs
Also, In the Chrome Network Inspector, make sure the encoding is being returned correctly. Eg:
Content-Type:text/html; charset=UTF-8
If your environment is Linux, you need to have a clean UTF-8 configuration.
Please have a look here.
I had the same problem, I just add into the file ~/.bashrc these lines:
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
After that, don't forget to restart your Coldfusion Server
sudo /opt/coldfusion11/cfusion/bin/coldfusion restart
Please see: Why are certain characters not being injected correctly to SQL Server from a CFQUERY?
Make sure your file is saved with encoding Unicode UTF-8.
Also make sure your JVM arguments will process that as well. Admin > Server Settings > Java and JVM. Add " -Dfile.encoding=UTF-8" to the Arguments.
I had the same problem this solved my bug
/.bashrc
LC_ALL="de_DE.UTF-8"
on linux and after change restart coldfusion application
I would like to type :make in Vim to compile my LaTeX document. I wrote down compilation rules in a Makefile, but as soon as I enable the LatexSuite Vim extension, the Makefile is no longer used. Instead, Vim runs latex -interaction=nonstopmode (note the absence of a filename) and hangs in that command. I did not change the g:Tex_UseMakefile option from its default 1 to 0 and according to the documentation, that should cause my Makefile to be used, but it's not.
What configuration is needed to tell LatexSuite to just use my Makefile?
LatexSuite was obtained via OpenSuSE repositories: vim-plugin-latex-20120125-21.1.1.noarch
You can override this via following setting in your vimrc.
autocmd FileType tex let g:Tex_CompileRule_dvi = 'make'
Alternatively, set makeprg in $HOME/.vim/after/ftplugin/tex.vim
set makeprg='make'
Helpful in-source documentation of file <latex-suite-root-folder>/compiler/tex.vim
Section " Customization of 'makeprg': {{{
This (g:Tex_CompileRule_dvi) is a string which should be directly be able to be cast into
" &makeprg.