I have installed the latest version of Redis v2.8.9 from MsOpenTech
The server is up and everything is ok.
But when I invoke the redis-cli.exe and type in the word info : I see each char {each click} with weird info around it :
With previous version (2.8.4) of redis , it doesn't happen and all chars displayed normally.
Question
What are those extra chars ? and how can I make it to be displayed normally ?
nb - windows 8 / 64bit
They look like ANSI character control code used to format and colorize the display. Use an ANSI compliant terminal, or set the FAKETTY environment variable, or use the --raw option.
Apparently it was a bug which was fixed in a newer version :
https://github.com/MSOpenTech/redis/issues/118
Related
I am using Python's Paramiko library to SSH a remote machine and fetch some output from command-line. I see a lot of junk printing along with the actual output. How to get rid of this?
chan1.send("ls\n")
output = chan1.recv(1024).decode("utf-8")
print(output)
[u'Last login: Wed Oct 21 18:08:53 2015 from 172.16.200.77\r', u'\x1b[2J\x1b[1;1H[local]cli#BENU>enable', u'[local]cli#BENU#Configure',
I want to eliminate, [2J\x1b[1;1H and u from the output. They are junk.
It's not a junk. These are ANSI escape codes that are normally interpreted by a terminal client to pretty print the output.
If the server is correctly configured, you get these only, when you use an interactive terminal, in other words, if you requested a pseudo terminal for the session (what you should not, if you are automating the session).
The Paramiko automatically requests the pseudo terminal, if you used the SSHClient.invoke_shell, as that is supposed to be used for implementing an interactive terminal. See also How do I start a shell without terminal emulation in Python Paramiko?
If you automate an execution of remote commands, you better use the SSHClient.exec_command, which does not allocate the pseudo terminal by default (unless you override by the get_pty=True argument).
stdin, stdout, stderr = client.exec_command('ls')
See also What is the difference between exec_command and send with invoke_shell() on Paramiko?
Or as a workaround, see How can I remove the ANSI escape sequences from a string in python.
Though that's rather a hack and might not be sufficient. You might have other problems with the interactive terminal, not only the escape sequences.
You particularly are probably not interested in the "Last login" message and command-prompt (cli#BENU>) either. You do not get these with the exec_command.
If you need to use the "shell" channel due to some specific requirements or limitations of the server, note that it is technically possible to use the "shell" channel without the pseudo terminal. But Paramiko SSHClient.invoke_shell does not allow that. Instead, you can create the "shell" channel manually. See Can I call Channel.invoke_shell() without calling Channel.get_pty() beforehand, when NOT using Channel.exec_command().
And finally the u is not a part of the actual string value (note that it's outside the quotes). It's an indication that the string value is in the Unicode encoding. You want that!
This is actually not junk. The u before the string indicates that this is a unicode string. The \x1b[2J\x1b[1;1H is an escape sequence. I don't know exactly what it is supposed to do, but it appears to clear the screen when I print it out.
To see what I mean, try this code:
for string in output:
print string
I want to insert data from a large CSV file to MonetDB. I can't use MonetDB "mclient" because this procedure must run inside a Pentaho Server application within a Docker container. MonetDB is inside a Docker container too.
Here's my very simple transformation:
When I test the transformation, I always get the following error message:
2021/03/20 22:37:37 - MonetDB bulk loader.0 - Error loading data: 42000!COPY INTO: record separator contains '\r\n' but in the input stream, '\r\n' is being normalized into '\n'
Does anyone have any idea what is happening?
Thank you!
This is related to line endings. Pentaho issues a COPY INTO statement,
COPY INTO <table> FROM <file>
USING DELIMITERS ',', '\r\n'
Here, \r\n means DOS/Windows line endings. Since the Oct2020 release, MonetDB always normalizes the line endings from DOS/Windows to Unix style \n when loading data. Before, it used to sometimes normalize and sometimes not. However, normalizing to \n means that looking for \r\n would yield one giant line containing the whole file, hence the error message.
I will submit a patch to MonetDB to automatically replace the USING '\r\n' with '\n'.
This will fix it in the longer term.
In the short term I have no good solution to offer. I have no experience with Pentaho, but looking at the source code, it seems Pentaho is uses the system property lines.separator, which is \r\n on Windows.
This means, if you have access to a Mac or Linux machine to run Pentaho on, that will work as line.separator is \n there. Otherwise, maybe you can ask the Pentaho people if the JVM can be started with something like java -Dline.separator="\n" as a workaround, see also this Stack Overflow question.
Otherwise, we'll have to use a patched version of either Pentaho, the MonetDB JDBC driver or MonetDB. I could send you a patched version of the JDBC driver that automagically replaces the '\r\n' with '\n' before sending the query to the server but you have to figure out yourself how to get Pentaho to use this JDBC driver instead of the default one.
I use the IntelliJ IDEA's Embedded Local Terminal quite a lot, but there is one thing that is driving me nuts : special and accented characters do not work.
This is what should but is not working :
HOME key to go to the beginning of the line : does nothing
END key to go to the end of the line : does nothing
[CTRL + left arrow] to go to previous word : prints D
[CTRL + right arrow] to go to next word : prints C
all accented characters : prints nothing at first, then ? when I hit another key
There are probably other combinations that should but do not work ... but these are the most annoying ones.
I'm using :
Ubuntu 16.04 virtual box guest running on a Windows 10 host
IntelliJ IDEA 2016.2.4
zsh
oh-my-zsh
Important notes :
in a GNU Terminal (outside of IntelliJ then) everything works perfectly, so I don't think that the "running inside a VM" thing is the source of the problem.
if I run bash instead of zsh the special characters are working (home, end, next work, etc...) but I still don't have propre support of accented characters (prints �), and I'd really prefer using zsh.
showkey --scancodes prints Couldn't get a file descriptor referring to the console
if I start od -c I get ^[[H for the HOME key and ^[[F for the END key
showkey --ascii works and prints ^[[H too for the HOME key
What I did already :
checked that the TERM variable is not overridden in .zshrc
add bindkey "${terminfo[khome]}" beginning-of-line and end of line equivalent in .zshrc
add lines (that seemd appropriate) in .inputrc for readline (OK I see now that this was useless as Zsh does not use readline)
edit : I could make the home/end keys work (see accepted answer below), but not the CTRL+LEFT and CTRL+RIGHT key (for forward-word and backward-word). After some more digging this seems to be an issue with IntelliJ not 100% properly emulating the terminal. 4
There is an issue here, with interesting input from an oh-my-zsh contributor : https://youtrack.jetbrains.com/issue/IDEA-118848#comment=27-1292473
They consider ditching smkx (which appears to be the root of the problem) from oh-my-zsh soon. I've checked out this PR and now my keys work fine (still need the bindings, but CTRL+LEFT and CTRL+RIGHT are ok now)
edit: accented/special characters are now properly supported in IntelliJ (yeehaa !), be sure to have at least the following version : IntelliJ IDEA 2016.3.1, Build #IC-163.9166.29, built on December 9, 2016
I can appreciate that zsh works fine outside IntelliJ.
Step 1
Find the correct key codes being used by the terminal inside Intellij. This will depend on the OS you are using. For OSX and Linux od -c followed by pressing the keys will result in the key code being emitted.
Step 2
Once you have the keycodes, modify your ~/.zshrc :
bindkey "$HOME_KEY_CODE_FROM_STEP_1" beginning-of-line
bindkey "$END_KEY_CODE_FROM_STEP_1" end-of-line
for example (as was the case for the OP):
bindkey "^[[H" beginning-of-line
bindkey "^[[F" end-of-line
and restart the terminal.
I'm frequently updating my db on the server, and I run the following line from the command line:
mysqldump -u root --password=mypass mydb|mysql -h mysite.cc -u remotusr --password=remotpsw remotdb
The problem is that it loses the UTF characters along the way.
How can I keep the utf chars in cmd, or what is a better practice doing this?
( Upgrading to an answer )
As documented under mysqldump — A Database Backup Program:
--default-character-set=charset_name
Use charset_name as the default character set. See Section 10.5, “Character Set Configuration”. If no character set is specified, mysqldump uses utf8, and earlier versions use latin1.
[ deletia ]
--set-charset
Add SET NAMES default_character_set to the output. This option is enabled by default. To suppress the SET NAMES statement, use --skip-set-charset.
Therefore, unless you have settings in an option file which are overriding these defaults (you can specify --no-defaults to ensure they are not), the output from mysqldump should be more than capable of being redirected to another mysql session without loss of Unicode characters.
Instead, the conversion to a smaller character set appears to be occurring on retrieving & displaying your data from the new database. Since you are using PHP's Original MySQL API for this purpose, despite the warning in the introduction to its manual chapter (below), you should use mysql_set_charset() to set the connection character set.
This extension is not recommended for writing new code. Instead, either the mysqli or PDO_MySQL extension should be used. See also the MySQL API Overview for further help while choosing a MySQL API.
I'm attempting to migrate a database from a windows to a linux host.
Thanks!
Ashley
You are not finding the the table names under linux mysql, coz its default is case-sensitive.
And for windows its case-insensitive.
I can't guess if ignoring case sensitivity works for you. But you can do by adding a line in my.conf. i.e. making mysql in linux to be case insensitive.
mysqlserver:~# vi /etc/mysql/my.cnf
...
[mysqld]
lower_case_table_names = 1
Check out the following links and see if that helps:
http://bugs.mysql.com/bug.php?id=33898
http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html
Bug 33898 suggests setting lower_case_table_names=2.