Under some conditions, ANSI colors output by Julia in have stopped working for me. I have tried this on Julia 1.6.3 and 1.7.0.
Under normal circumstances, colors work (this is in git-bash):
$ julia -e 'println("\33[1;31mhello\33[0m")'
hello
(Where hello is now bold and red). But if Julia runs a command with Base.run before the println, I get:
$ julia -e 'run(`true`); println("\33[1;31mhello\33[0m")'
←[1;31mhello←[0m
This seems to be a julia thing:
$ python -c "import os; os.system('true'); print('\33[1;31mhello\33[0m')"
hello
(Again, the hello is red).
This also affects cmd.exe:
C:\>julia -e "run(`\"c:\Program Files\git\usr\bin\true\"`); println(\"\33[1;31mhello\33[0m\")"
←[1;31mhello←[0m
But it seems to be only the case for commands that come from the git-bash environment:
C:\>julia -e "run(`cmd /c exit`); println(\"\33[1;31mhello\33[0m\")"
hello
(in red, again).
I asked about this on Julia Discourse a while back, but didn't get any answers. Does anyone here have any insight into what might be happening? Thanks in advance!
Related
I am working on Bash 5.0 from GNU repository. I wanted to find the place where Bash reads a string with ASCII colors and convert it to colors, like in the following case where it convert "Hello" to red:
root#ubuntu:~/Desktop/bash-5.0# ./bash
root#ubuntu:~/Desktop/bash-5.0# echo $BASH_VERSION
5.0.0(8)-release
root#ubuntu:~/Desktop/bash-5.0# ./bash -c 'echo -e "\033[31mHello\e[0m World"'
Hello World
I searched inside the source code and found two files that seems to be related:
bash-5.0/lib/readline/colors.c - link
bash-5.0/lib/readline/parse-colors.c - link
But they are not, they work only on the first time I load Bash and you need to write the following rows in the file ~/.inputrc for it to work:
set colored-completion-prefix on
set colored-stats on
Any idea where in the code Bash takes string like that "\033[31mHello" and convert it to red?
It's not the shell that's converting anything to colors, it is your terminal. The shell only outputs ANSI escape codes which are then picked up by the terminal.
Depending on your point of view and philosophical interpretations, \033[31mHello already is a colored string (for the shell, at least, it is)
I am using Gina Trapiani's excellent todo.sh to organize my todo-list.
However being a dane, it would be nice if the script accepted special danish characters like ø and æ.
I am an absolute UNIX-n00b, so it would be a great help if anybody could tell me how to fix this! :)
Slowly, the Unix world is moving from ASCII and other regional encodings to UTF-8. You need to be running a UTF terminal, such as a modern xterm or putty.
In your ~/.bash_profile set you language to be one of the UTF-8 variants.
export LANG=C.UTF-8
or
export LANG=en_AU.UTF-8
etc..
You should then be able to write UTF-8 characters in the terminal, and include them in bash scripts.
#!/bin/bash
echo "UTF-8 is græat ☺"
See also: https://serverfault.com/questions/11015/utf-8-and-shell-scripts
What does this command show?
locale
It should show something like this for you:
LC_CTYPE="da_DK.UTF-8"
LC_NUMERIC="da_DK.UTF-8"
LC_TIME="da_DK.UTF-8"
LC_COLLATE="da_DK.UTF-8"
LC_MONETARY="da_DK.UTF-8"
LC_MESSAGES="da_DK.UTF-8"
LC_PAPER="da_DK.UTF-8"
LC_NAME="da_DK.UTF-8"
LC_ADDRESS="da_DK.UTF-8"
LC_TELEPHONE="da_DK.UTF-8"
LC_MEASUREMENT="da_DK.UTF-8"
LC_IDENTIFICATION="da_DK.UTF-8"
LC_ALL=
If not, you might try doing this before you run your script:
LANG=da_DK.UTF-8
You don't say what happens when you run the script and it encounters these characters. Are they in the todo file? Are they entered at a prompt? Is there an error message? Is something output in place of the expected output?
Try this and see what you get:
read -p "Enter some characters" string
echo "$string"
I wrote the following for a homework assignment and it works fine in IDLE and Eclipse running Python 3.
However, I tried to run it from TextMate with the new line 1 -- which I found here -- to point it to Python 3 on the Mac. It seems to be running Python 3 but returns an error. It says: EOFError: EOF when reading a line. It's referring to line 5 below.
Anyone know why?
BTW, this TextMate issue is not part of the homework assignment, so I'm not trying to get homework help. I just want to figure out how to use TextMate with Python 3.
#! /usr/local/bin/python3
#
# Tests user string against two conditions.
#
user_string = input("Enter a string that is all upper case and ends with a period: ")
if user_string.isupper() and user_string.endswith("."):
print("Your string met both conditions.")
else:
if user_string.isupper():
print("Your string does not end with a period.")
elif user_string.endswith("."):
print("Your string is not all upper.")
else:
print("Your string failed both conditions.")
The problem you are seeing has nothing to do with the Python version. The problem is that TextMate does not try to redirect standard input so, when you are running via the TextMate's Python bundle Run Script command, the Python program sees an immediate end-of-file. As explained here, TextMate used to be fancier about this but the mechanism it used no longer works in OS X 10.6 so the feature was disabled.
One solution is to use the Shift-Command-R Run Script in Terminal command of TextMate's Python bundle. This causes TextMate to open a terminal window and run the script there and you can enter the input there. Unfortunately, while TextMate does respect the shebang line with the normal Command-R Run Script command, it doesn't seem to do so with the Run Script in Terminal command. You can verify that yourself in various ways. Try running this code snippet in TextMate:
#! /usr/local/bin/python3
import sys
print(sys.executable)
To get around that, you can set the TM_PYTHON environment variable in TextMate. See the answer here for more details on how to do that.
Textmate is using the built-in Python, rather than respecting the shebang line. You'd probably have to hack the bundle code to use the right python.
This question already has answers here:
Bash echo command not making use of escaped character
(4 answers)
Closed 6 years ago.
As practice, I made a shell script that outputs a colored message on the screen. I was trying to use ANSI color codes but the content itself would output instead.
My code:
#!/bin/bash
echo "\033[1;37;42m SUCCESS! \033[0m"
Output:
\033[1;37;42m SUCCESS! \033[0m
However, using 'print' does work:
#!/bin/bash
print "\033[1;37;42m SUCCESS! \033[0m \n"
Output (with white font + green background):
SUCCESS!
I tested this on Red Hat Enterprise Linux Server release 6.5 (Santiago) and Raspbian Jessie Lite 4.4, and had the same results. To the best of my knowledge and from all the search engine results I've gone through, 'echo' and 'print' are the same except 'echo' includes a newline and 'print' does not. Why in this case would it be different?
By default, echo will interpret it as a string, literally. You have to tell echo to interpret backslashes appropriately.
From the documentation:
-e enable interpretation of backslash escapes
echo -e "\033[1;37;42m SUCCESS! \033[0m"
I'm currently trying to solve a tricky/silly challenge and i've come to a dead end.
The challenge is basically to form a one-liner /bin/sh compatible command line
which essentially outputs "Hello World" without directly typing White space or Tab characters in the command itself.
for example something like -
echo Hello World
would be invalid since we used white space twice in the command line.
Any ideas?
Assuming that IFS by default is set to space:
# echo${IFS}a${IFS}b
a b
Tested on Solaris 10 sh.
Cheating a little, but it gives the correct effect (superficially) in bash:
PS1=hello$'\x20'world$'\n'"$PS1"
for example,
$ PS1=hello$'\x20'world$'\n'"$PS1"
hello world
$
The problem is that it will print hello world after every command in future :-)