When I run a Javascript file with Deno ...
// file.js
console.log(42)
... doing deno run file.js, then Deno prints ...
←[33m42←[39m
... to the standard Windows 7 console (cmd.exe). What is this, and how can I disable this?
On Windows 7 code coloring is not supported in the standard cmd.exe, resulting in these strange characters.
Solution
If you add an environment variable NO_COLOR=true Deno will not try to color the output anymore and the weird characters will disappear. If you remove the variable again you may have to restart Windows in order to get back the coloring.
See also deno help where I got this from.
A helpful tool to edit environment variables is RapidEE.
If you want the colors, try out a console emulator like for example cmder.
Related
When running on Windows, I have changed my default terminal in the IntelliJ IDE from default Windows cmd to bash (I am using the one installed with Git, located at C:\Program Files\Git\bin\bash.exe). It works very well, the only trouble is that when running sbt from the terminal, some strange characters are shown (I assume they are some control characters intended to format the output).
This does not happen when I run sbt directly from the bash launched in the Windows as a standalone window.
Is there some setting (an environment variable or a config file) for any of the three components involved (sbt, IntelliJ, bash) I could change so that I do not see those formatting characters misinterpreted? If they would work and affect the formatting it would be a nice bonus, but that is less important to me.
IntelliJ:
Standalone:
sbt by default colors the console output, which does not work on Windows, but perhaps the launcher script doesn't disable the codes in the IntelliJ terminal script.
You can disable colors by passing the -Dsbt.log.noformat=true to sbt
You can preserve the colours and formatting if you add the following to your .bashrc file:
sbt() {
/c/progra~2/sbt/bin/sbt.bat "$#"
}
export -f sbt
.bashrc can be found (or created) in your %USERPROFILE% directory, e.g. C:\Users\{username}\.bashrc.
Substitute a different path to sbt.bat if necessary, but it needs to be without spaces.
Restart your terminal afterwards, or run source ~/.bashrc.
This exports a bash function that causes "sbt" to run the sbt batch file launcher instead of the shell script launcher that it would otherwise. The batch launcher clearly does a better job of processing the output on Windows. (I also use this for gcloud and gsutil commands that fall over in other ways when invoked from Bash.)
Find the sbtopts file (Windows location is C:\Program Files (x86)\sbt\conf by default) and make sure it contains following line and it is not commented out:
-no-colors
I wrote a build script for my project (maven, grunt as well as some server-reconfiguration), and when I use the WebStorm command-line with
~/Projects/javaee-angularjs$ ./launchServer.sh
Everything works as expected.
However, when I configure the file to be run by WebStorm (the green triangle top-right) it fails because of: /home/user/Projects/javaee-angularjs/launchServer.sh: line 29: grunt: command not found
The run-config should be absolutely correct:
working directory is the correct one and the script is found to begin with.
Any Idea what could cause this weird behavior?
P.S. I don't know whether WebStorm can run bash natively, since I've always had the bash plugin installed.
Try starting WebStorm from terminal - does the issue persist?
When being launched from desktop/System menu, WebStorm only sees environment variables configured in ~/.profile (login shell), but not in interactive shell configuration files (like ~/.bashhrc). Possible workarounds:
Workaround 1: make required variables available in a login shell (i.e. for bash, move them from .bashrc to .bash_profile).
Workaround 2: run IDE from a terminal, via bin/webstorm.sh
Workaround 3: edit the desktop launcher and set command to /bin/bash -l -i -c "/path/to/webstorm.sh"
see also https://youtrack.jetbrains.com/issue/IDEABKL-7589
The error sounds like Webstorm cannot find grun in its path. Try using the full path to the grunt command.
I just switched to a windows machine and I'm trying to get fish configured correctly. I installed it through the default route, as a shell selected through cygwin setup. It seems to be working fine, but when I directly access fish.exe or run fish.exe through IntelliJ, it outputs a ? before very prompt:
I googled and found this on fish documentation FAQ:
I'm seeing weird output before each prompt when using screen. What's wrong?
Quick answer:
Run the following command in fish:
echo 'function fish_title;end' > ~/.config/fish/config.fish
Problem solved!
The long answer:
Fish is trying to set the titlebar message of your terminal. While
screen itself supports this feature, your terminal does not.
Unfortunately, when the underlying terminal doesn't support setting
the titlebar, screen simply passes through the escape codes and text
to the underlying terminal instead of ignoring them. It is impossible
detect and resolve this problem from inside fish since fish has no way
of knowing what the underlying terminal type is. For now, the only way
to fix this is to unset the titlebar message, as suggested above.
Note that fish has a default titlebar message, which will be used if
the fish_title function is undefined. So simply unsetting the
fish_title function will not work
So it appears that intelliJ and cmd (fish.exe runs in cmd.exe if you access it directly) do not support setting the title bar, so they just output the character to the terminal instead. However, their suggested solution does not work. I've tried various options like echoing an empty string or a space, but nothing gets rid of that darn question mark.
Has anyone else run into this and found a solution?
Notes:
It doesn't have this behavior when using fish through mintty.exe,
most likely since that terminal supports setting the title, but I really prefer
to use the terminal inside intelliJ instead of having it in a
separate window.
It didn't have this problem when I used fish through IntelliJ on Ubuntu or MacOSX, it appears to be isolated to Windows
I have been testing with Codeception and PhantomJS for a while, but when ever i have to debug and run
vendor/bin/codecept run --debug
with colors set to true all i get is:
Modules: ←[33mWebDriver, AcceptanceHelper←[39m
and so on... So for some reason the color is just outputed in a raw format and is not working at all. Colors usually work. like when i use "ls --color" it just works.
My System is Windows 7 i'm using the "git bash" and i have also tried the regular "cmd" "powershell" and "cygqwin". Neither one of them seem to work with codeceoptions output.
So what is the problem? I'm clueless :(
in bash, try running
export TERM=ansi
or
export TERM=xterm
before running your program
or, to test color output from the shell itself:
echo -e "\e[41m\e[32mCOLOR\e[0m"
if that does work than it is the program, not the environment
finally, you might just need a better console.
try conemu, it has excellent ansi color support and i use it for cmd powershell bash perl and ssh sessions :)
http://sourceforge.net/projects/conemu/
Your application (Codeception) was not adapted to Windows console, which doesn't support ANSI colorizing. To enable ANSI colors you may choose one of the following options:
ConEmu is the Windows local terminal with ANSI capabilities and many other features like tabs, splits, preconfigured shell tasks, ... Also, it's the only terminal which able to "replace" default Windows console. Yep, I'm the author.
Some applications may work properly in mintty (bundled with cygwin or msys). Many native Windows console tools can't work properly in this terminal, but may be your app will be fine.
There is AnsiCon project. It enables ANSI colorizing in standard Windows console.
BTW, bash's ls (cygwin or msys) was adapted to Windows console API, so it doesn't post ANSI to terminal, unless terminal has done special initialization of POSIX subsystem. ConEmu can do this initialization via cygwin/msys connector.
I am getting very strange outputs from my IRB console. Here it is:
irb(main):001:0> File.dirname(__FILE__)
=> ←[0;31m"←[0;0m←[0;36m.←[0;0m←[0;31m"←[0;0m
Seems like an encoding issue, right? I am not sure why this is happening. Any ideas how to fix it?
Those are escape codes used to set colors in a terminal program; probably most popularly to colour a prompt in an xterm or compatible terminal. My bash prompt environment variable, for example, looks like this:
PS1="\[\033]2;\w\007\]\[\033[0;31m\]\u#\h \[\033[0;32m\]\!\[\033[0;31m\]> \[\033[0m\]
It looks like some string like that one is getting into your console and confusing it (since it's not bash and/or in an xterm-friendly terminal emulator, I guess).
As Carl and Mike pointed out, that's color information. You can have the colors actually show up if you install ANSICON. Wirble and Cucumber showed up with colored text in their output in a dos box on my Windows machine once I installed that.