Mac 10.14.6
iTerm2 Build 3.4.8
Google Cloud SDK 351.0.0
beta 2021.07.30
bq 2.0.70
core 2021.07.30
gsutil 4.66
Logging in to my virtual gcloud server without errors with:
gcloud compute ssh myserver
However, the backspace key in the terminal registers as a space key.
Tried exactly the same with the stock Mac terminal, the same behaviour.
What gives?
The backspace key will often seem to register as a space key if the environment variable TERM is not set to a value that is defined in your terminfo configuration.
You can check the value of TERM by running:
echo $TERM
terminfo can be configured in several places, but on Google Compute Engine it is likely using the values from /lib/terminfo. (Other possibilities include $HOME/.terminfo and /usr/share/terminfo.) You can check if your current setting for TERM corresponds to a file in this directory by running:
find /lib/terminfo -name $TERM
If the value is present, you will see something like /lib/terminfo/s/screen-256color. If it is not present, you will not see any output.
You can fix the problem by ensuring that your TERM environment variable is set to one of the files defined in terminfo.
Related
Trying to follow the directions for installing the MySQL ODBC driver.
When I try to run:
myodbc-installer -a -d -n "MySQL ODBC 8.0 Driver" -t "Driver=/usr/local/lib/libmyodbc8w.so"
It says:
[ERROR] SQLInstaller error 6: Unable to find component name
I've found a handful of cases of people reporting this same message, e.g., here and here. Yet there seems to be no resolution.
Noticing the slight variations in the -n name string for the various drivers, I wondered if perhaps the name was something subtly different and the documentation hadn't been updated. But I used a hex editor to look in /usr/local/lib/libmyodbc8w.so and the literal string "MySQL ODBC 8.0 Driver" is in it.
There may be some instances of a name mismatch causing the problem (e.g. in one of the linked-to cases, they use -n "MySQL" instead of the prescribed -n "MySQL ODBC 5.3" from the notes).
However...in my case it was a matter of not using sudo. The error message is not very helpful in indicating that the problem could be a matter of privileges! :-/ But at the very top of the linked instruction page it says (emphasis mine):
To install the driver from a tarball distribution (.tar.gz file), download the latest version of the driver for your operating system and follow these steps, substituting the appropriate file and directory names based on the package you download (some of the steps below might require superuser privileges)
What's going on is that unixodbc has system-wide odbcinst.ini and odbc.ini. It is stated that you should not be editing these files directly, but they are edited via an API that unixodbc provides. That API is called by the MySQL helper utility called myodbc-installer:
The error message is delivered by this print_installer_error() routine
...which is called from add_driver() when the routine SQLInstallDriverExW() returns false
(Note: unixodbc on most platforms provides the (W)ide Character version of SQLInstallDriverEx(), but myodbc-installer defines its own SQLInstallDriverExW() if it is not available via a shim.)
This API apparently doesn't have a way of saying it can't get the necessary privileges to the files (in /usr/local/etc or perhaps just in /etc). So myodbc-installer is just parroting what it got. Sigh.
I was trying to create a sharded mongo cluster and came across the env. variable "term", with value "xterm". Need help to understand the config field.
environment:
TERM: xterm
TERM is an env var that contains the terminal emulator used by your system. This var is not related to MongoDB.
In my Ubuntu 16.04, if I type echo $TERM, I'll get xterm-256color.
If you are using Docker, that TERM: xterm means that the terminal emulator used when you access your container will be xterm.
TERM affects MongoDB in the following way: Different terminal emulators generate different escape sequences when you press keys like Arrows, Home, End, Delete, etc; Mongo Shell, that runs on top of the emulator, will translate those sequences into its own 'language' to guarantee that each keystroke will present the same result in different terminals. Mongo uses Linenoise to do this job.
The value of TERM is not that important for 'keystroke processing'. Mongo Shell will try to translate the escape sequence from each terminal 'language' it supports. On the other hand, TERM is used to decide if the shell can show colors or not.
I have once before mounted this same database, so I am confident that I have the correct credentials.
During the last session that I had it mounted I was experimenting with my queries, visuals etc. and the session all of a sudden crashed.
Then when I reloaded slamdata, the mount for my database was gone.
Obviously I then tried to remount the same database with the same credentials in order to continue my work. However when I did this I got an error:
There was a problem saving the mount: An unknown error ocurred: 500 ""
And then there is a never ending spin wheel that sits on the mount button. I can leave this pop up and go to the original screen, but nothing occurs. And then if I try to remount again the same error occurs.
I have verified that I can still access my db and collections using robomongo. So if anyone knows what this error message refers to please let me know! I have yet to find its meaning online.
Note: I have already tried uninstalling and reinstalling/ restarted my computer.
In SlamData 4.2.1 this bug has been identified and fixed an issue with the MongoDB connecter that would corrupt the metastore if you use the _id field in a query. The fix is available in the SlamData 4.2.2 release soon
Below is the fix:
Delete the current metastore. Below is the location of this file for each supported operating system:
Mac OS:
$HOME/Library/Application Support/quasar/quasar-metastore.db.mv.db
Microsoft Windows:
%HOMEDIR%\AppData\Local\quasar\quasar-metastore.db.mv.db
Linux (various vendors):
$HOME/.config/quasar/quasar-metastore.db.mv.db
Open a terminal and switch to the location that you stored SlamData into. You should find a quasar-web.jar file in the following location based on your installed operating system based on default installation paths:
Mac OS:
/Applications/SlamData 4.2.1.app/Contents/java/app/quasar-web.jar
Microsoft Windows:
C:\Program Files (x86)\slamdata 4.2.1\quasar-web.jar
Linux (various vendors):
$HOME/SlamData 4.2.1/quasar-web.jar
Run the following command in a terminal:
java -jar quasar-web.jar initUpdateMetaStore
This will rebuild your metastore. Once complete it will return you to your operating system prompt.
Rerun the SlamData application as you normally would
Remount your database
At this point in time you can access your saved workspaces.
NOTE: You will not want to open the workspace you were using that caused this issue as it will cause the same problem.
I tried to do the following:
Download: client EC2 in https://aws.amazon.com/developertools/351. And save that in C:/AWS/CLI.
Create in the environment variables, a new system variable.
Name: JAVA_HOME
Value: C:\Program Files\Java\jre7
Create other new system variable.
Name: EC2_HOME
Value: C:\AWS\CLI
Edit the value of the system variable Path, and add %EC2_HOME%\bin.
Create other two system variables:
System variable name: AWS_ACCESS_KEY, value: my access key.
System variable name: AWS_SECRET_KEY, value: my secret key.
Open my windows command line and execute the code:
ec2-stop-instances <id_instancia> –region <region>
I received the error:
the filename, directory name or volume label syntax is incorrect.
Why does this happen?
Those API tools look somewhat old.
These days, it is recommended to use either:
AWS Command-Line Interface (CLI) (Windows, Mac, Linux)
AWS Tools for Windows PowerShell (Windows only)
If you like PowerShell, use that one. Otherwise, go for the AWS CLI. There is good documentation for both.
There's an extremely easy way to stop the instance from the instance's cmd, that is
shutdown /s
That will shutdown (and stop, not terminate) the EC2
I am trying to install RMySQL on my Windows 7 Professional x64 machine using R-2.15.1, RTools 2.16 (also tried 2.15), and MySQL 5.5.
I have copied libmysql.dll and libmysql.lib into mysql\lib\opt and \bin. I have also copied libmysql.dll into R-2.15.1\bin.
I have set Renviron.site properly as confirmed by Sys.getenv('MYSQL_HOME') using both the 8.3 nomenclature as well as non-8.3 nomenclature.
Sample output for Sys.getenv('MYSQL_HOME') is "C:/Program Files/MySQL/MySQL Server 5.5/" (quotes included). When I use 8.3 nomenclature it also is correct.
Here is the relevant part of my PATH:
c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;C:\Program Files\MySQL\MySQL Server 5.5\lib\opt;c:\program file\R\R-2.15.1\bin;
I have manually inserted it into the registry in the right location (because the MySQL 5.5 doesn't do that properly - it only puts it under the Wow6432Node) AND I inserted it into the system variables to deal with this error:
Error in utils::readRegistry("SOFTWARE\MySQL AB", hive = "HLM", maxdepth = 2) :Registry key 'SOFTWARE\MySQL AB' not found
I even tried
Sys.setenv('MYSQL_HOME=C:/Program Files/MySQL/MySQL Server 5.5/')
However, when I try to install RMySQL I get the following error:
checking for $MYSQL_HOME... not found... searching registry...
cygwin warning:
MS-DOS style path detected: C:/PROGRA~1/R/R-215~1.1/bin/x64/Rscript
Preferred POSIX equivalent is: /cygdrive/c/PROGRA~1/R/R-215~1.1/bin/x64/Rscript
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Try setting MYSQL_HOME to one of the following (you may have to use the non-8dot3 file name):
ERROR: configuration failed for package 'RMySQL'
If I am understanding the error properly, it can't find MYSQL_HOME, even though it calls it properly using Sys.getenv, is located in the proper location in the registry, AND is a system variable.
I have a similar issue with my Windows 7 x64 installation.
I think the problem is not related to the MYSQL_HOME, but to the registry.
As you can see here:
https://dev.mysql.com/doc/refman/5.1/en/windows-install-wizard.html
the default location for the registration is not SOFTWARE\MySQL AB but SOFTWARE\Wow6432Node\MYSQL AB.
I believe the answer is here:
http://martin.von-gagern.net/howtos/20110728-rmysql/