Is it possible to specify which .my.cnf file mysql client should use? I have 2 mysql instances running on different ports and want to only need to specify a filename with credentials.
As documented under Command-Line Options that Affect Option-File Handling:
When specifying file names, you should avoid the use of the “~” shell metacharacter because it might not be interpreted as you expect.
--defaults-extra-file=file_name
Read this option file after the global option file but (on Unix) before the user option file. If the file does not exist or is otherwise inaccessible, the program exits with an error. file_name is interpreted relative to the current directory if given as a relative path name rather than a full path name.
--defaults-file=file_name
Use only the given option file. If the file does not exist or is otherwise inaccessible, the program exits with an error. file_name is interpreted relative to the current directory if given as a relative path name rather than a full path name.
--defaults-group-suffix=str
If this option is given, the program reads not only its usual option groups, but also groups with the usual names and a suffix of str. For example, the mysql client normally reads the [client] and [mysql] groups. If the --defaults-group-suffix=_other option is given, mysql also reads the [client_other] and [mysql_other] groups.
Note that "to work properly, each of these options must be given before other options".
Related
According to the documentation it's possible to add the parameter --defaults-group-suffix to a mysql command, for it to "In addition to the default option groups, also read option groups with the given suffix".
So in case I use:
--defaults-group-suffix=.sample
A mariadb-Server started with this option will read both, the following blocks:
[mariadbd]
…
[mariadbd.sample]
…
So I can put options which should apply to the specific instance to the second block.
My question is: Is there a way to add an option group, which is only evaluated, when the parameter --defaults-group-suffix is not provided, in other words empty?
The default block [mariadbd] obviously can't be used, since it is read by all instances with a defined suffix.
Additional question, since I can't find it in the documentation: If one option is specified multiple times in one (or more) configuration files: Is it the first, or the last match, that applies?
According to the stackoverflow guidelines, next time please only ask one question per posting.
1st question: No, it is not possible - the suffix option is an additional option, there are no conditions which check suffix and other options.
2nd question: If multiple configuration files with same options but different values are used, the option/value from last read configuration file will be used. Check the read order of configuration files by executing
mysqld --help --verbose | grep -C1 "Default options"
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf
I am working on TCL script that will open another tcl file and I want to get value of variable from second opened file and use it in the first file.
Two file abc.tcl and xyz.tcl
abc.tcl opens file xyz.tcl and reads value of variable and use it in abc.tcl.
If xyz.tcl sets a global variable, abc.tcl will be able to see it if it used source to load in xyz.tcl.
Here's a simple example. This is xyz.tcl:
set SomeVariable 12345
This is abc.tcl:
source xyz.tcl
puts "The password on my luggage is $SomeVariable"
The source command is really very simple internally. It just reads in the contents of the file (into a string), and then internally evals that string. Yes, this means that you probably shouldn't put source inside a procedure, at least not unless you're sure what the consequences of this are.
I am trying to connect a database to Weka 3.6.13 in Linux Elementary OS.
First, I had a problem with JDBC connection, solved by this answer changing the /usr/bin/weka file.
Now, when I load the database, this error comes:
Unknown data type: INT. Add entry in weka/experiment/DatabaseUtils.props.
However, I am trying to use explorer only, this file doesn't even exists in my installation.
I installed via sudo apt install weka.
What should I do?
Look inside the directory where your weka.jar file resides, and check if there exists a file called DatabaseUtils.props.
The Weka wiki says:
Weka only looks for the DatabaseUtils.props file. If you take one of
the example files listed above, you need to rename it first.
My file is different I think the actual name does not really matter, it's the filename extension that matters.
In my version of this file there is a section that looks like this:
... (snip...
# mysql-conversion / type-mappings
CHAR=0
TEXT=0
VARCHAR=0
STRING=0
LONGVARCHAR=9
BINARY=0
VARBINARY=0
LONGVARBINARY=9
BIT=1
BOOL=1
NUMERIC=2
DECIMAL=2
FLOAT=2
DOUBLE=2
TINYINT=3
SMALLINT=4
#SHORT=4
SHORT=5
INTEGER=5
INT=5
BIGINT=6
LONG=6
REAL=7
DATE=8
TIME=10
TIMESTAMP=11
#mappings for table creation
CREATE_STRING=TEXT
CREATE_INT=INT
CREATE_DOUBLE=DOUBLE
CREATE_DATE=DATETIME
DateFormat=yyyy-MM-dd HH:mm:ss
#database flags
checkUpperCaseNames=false
checkLowerCaseNames=false
checkForTable=true
setAutoCommit=true
createIndex=false
# All the reserved keywords for this database
Keywords=\
AND,\
ASC,\
BY,\
DESC,\
FROM,\
GROUP,\
INSERT,\
ORDER,\
SELECT,\
UPDATE,\
WHERE
# The character to append to attribute names to avoid exceptions due to
# clashes between keywords and attribute names
KeywordsMaskChar=_
#flags for loading and saving instances using DatabaseLoader/Saver
nominalToStringLimit=50
idColumn=auto_generated_id
If you do a google search for this file, another guy has posted his on github. The weka Wiki or SVN/Git-Repo might also list an offfical version somewhere (cannot find it right now), or you can open your weka.jar file as a zip file and extract the .props file (/src/main/java/weka/experiment/DatabaseUtils.props.mysql).
In any case, Mysql exists in many different versions, and I think you can even switch the query engine inside mysql. So I cannot express any guarantees that any of these 2 .props files shown here really work for you. You should experiment a bit.
I am coming into an existing project after several years of use. I have been attempting to add the nice keywords $Header$ and $Id$ so that I can identify the file versions in use.
I have come across several text files where these keywords did not expand at all. Investigation has determined that CVS thinks these files are BINARY and will not expand the keywords.
Is there anyway from a Linux Command Line invocation to permanently change the status of these files in the repository to cause keyword expansion? I'd be appreciative if you could tell me. Several attempts that I have tried have not succeeded.
cvs admin -kkv filename
will restore the file to the default text mode so keywords are expanded.
If you type
cvs log -h filename
(to show just the header and not the entire history), a binary file will show
keyword substitution: b
which indicates that keyword substitution is never done, while a text file will show
keyword substitution: kv
The CVSROOT/cvswrappers file can be used to specify the default new files you add, based on their names.
The OpenGrok wrapper script has an update option, but when I run it without any options (as echoed in the usage), I get
Loading the default instance configuration ...
FATAL ERROR: OpenGrok Source Path /var/opengrok/src doesn't exist - Aborting!
I have also tried specifying the SRC_ROOT, but continue to get the same error.
This might not be the right answer, but I have been able to update by re-running the index job itself. It doesn't take as long as the initial indexing.
from https://github.com/OpenGrok/OpenGrok
E.g. if opengrok data directory is /tank/opengrok and source root is
in /tank/source then to get more verbosity run the indexer as:
$ OPENGROK_VERBOSE=true OPENGROK_INSTANCE_BASE=/tank/opengrok \
./OpenGrok index /tank/source
SRC_ROOT is a variable in the OpenGrok wrapper (normally in /usr/opengrok/bin/OpenGrok), this variable is to say OpenGrok where you have your src code to be indexed. So you need to edit it:
SRC_ROOT="your/src/path"
Also, after that maybe you'll se an error for the Data location... and you have to set also the variable DATA_ROOT (index location)
DATA_ROOT="you/data"