For the python program I am writing I would like to give the opportunity of configuring it in three different ways. Environment variables, configuration files and command line arguments.
Logically I think command line arguments should always have the highest priority. I am a bit doubting whether environment variables should have precedence over configuration files? And will it matter whether configuration files are system wide, user specific or given as argument on the command line?
(Note that my platform is Unix/Linux)
The standard that I know is first look for a command line parameter, if not found environment var, then local config file then global config file.
So when a package is installed somewhere. It will have a default config file. This can be changed with a local config file. Which can be overrridden with a environ parameter and then the command line param has the highest precedence.
If a config file is declared on the command line then its contents will take precedence over environ params or any other config files. But command line params will take precedence over it.
But remember that the search path still exists. If the package is looking for a var it looks for.
Command line.
Config file thats name is declared on the command line.
Environment vars
Local config file (if exists)
Global config file (if exists)
I think many command line compilers and the Boost library config pak works in a similar fashion
AWS CLI is in line with the accepted answer:
Precedence of options:
If you specify an option by using one of the environment variables described in this topic, it overrides any value loaded from a profile in the configuration file.
If you specify an option by using a parameter on the CLI command line, it overrides any value from either the corresponding environment variable or a profile in the configuration file.
Related
I am using IBM Integration Bus v.9
I try to read configuration from file, like this tutorial.
Based on the documentation, I've already set up my environment variable in Windows like this :
MQSI_FILENODES_ROOT_DIRECTORY to C:\MQSIFileInput
In the File Read Node properties, i set input directory to "config" (without apos), because the file located in C:\MQSIFileInput\config directories.
When I run, i got error "The directory config is not a valid directory name". What am I missing here?
Do I need to set up another configuration to read the file properly?
Thank you.
The MQSI_FILENODES_ROOT_DIRECTORY variable needs to be visible to the ExecutionGroup process at startup, so first thing to check is how did you set the env var and did you restart the broker?
Due to the way that processes are forked on windows the process for setting env vars is usually something like:
Stop broker
Close Broker Command Prompt
Modify mqsiprofile.cmd to include variable
Open new Broker Command Prompt
Verify env var is set ie/ echo %MQSI_FILENODES_ROOT_DIRECTORY%
Start Broker
The directory also needs to be readable by the Broker's process ID (and writable if you will be deleting the file or moving it to a backout dir etc).
Wondering if it's possible to move the module directory in a JBoss 7 install to a non-default loco.
Does anyone know of a config param to specify where to pick it up?
Kinda like a conf-dir, bin-dir type of thing.
Thanks,
Aaron.
Yes, it's actually possible. As the documentation states, from within the standard launch scripts users are able to manipulate the module path by setting the $JBOSS_MODULEPATH environment variable. (If not set, $JBOSS_MODULEPATH is set to $JBOSS_HOME/modules). The module path is provided to the running process via the -mp command line argument that is set in the standard scripts.
I am trying to run a very simple tcl script
package require Expect
spawn sftp user#host
the error I get is
The system cannot find the file specified.
while executing
"spawn sftp user#host"
The only reason I see it's that sftp path should be specified somehow. I call this from a batch script and I've also tried changing the directory to sftp location before calling the script but the error is still the same.
By far the most likely cause of the issue here is that the sftp program is not in a directory that is on your PATH. The concept is almost the same across platforms, but with some minor niggles.
Working with the Unix PATH
Check to see if sftp is available in a PATH-known directory by typing:
which sftp
At your shell prompt. It should respond with the location of the sftp program, but if it isn't found then you get no response at all. If it isn't found, you'll need to find it yourself and add its location (strictly, the directory that contains the program) to the PATH. Find the program with something like:
locate sftp
Or (very slow!):
find / -name sftp -print
To append a directory to the PATH, do this in your shell:
PATH=$PATH:/the/dir/to/append
You can add a directory within the Expect script too (as long as it is before the spawn, of course!):
append env(PATH) : /the/dir/to/append
Working with the Windows PATH
On Windows, use Windows Search (Windows+F IIRC) and look for a file called sftp.exe (there's also a command line search tool, but I forget how to use it).
With the Windows PATH, a little more care is required:
append env(PATH) ";" {C:\the\dir\to\append}
# Or this...
append env(PATH) ";" [file nativename C:/the/dir/to/append]
Which is to say, the Windows PATH uses a different separator character (because : is used for separating drive names from directory parts) and the native name of the directory must be used, rather than the somewhat-more-convenient forward-slash variation (the backslashes interact with Tcl's syntax, hence the {braces}). Forward-slashes can be used provided you use file nativename to convert before appending, as in my second version.
Some Tcl Techniques that can Help
You can use the Tcl command auto_execok to find out whether a program is on your PATH or not. For example:
puts [auto_execok sftp]
However, for some commands (notably start on Windows) you get a more complex response; the command really exists as part of the code that supports interactive Tcl usage, describing how to run some external program which can sometimes be a lot more complex than it appears to be at first glance. Still, it approximates to a cross-platform version of which as listed in the beginning of this answer...
Tcl 8.6 provides $tcl_platform(pathSeparator) variable as a way to get the PATH element separator character (a : or ;, depending on platform). Probably doesn't help you though, as 8.6 hasn't yet been distributed as widely as previous versions.
I've configured my SSIS configuration to load from an XML file. When I run the package with dtexec, I specify a different configuration file for each country I'm processing. In Visual Studio I specified this as France.dtsConfig (I have to choose one and this was the first one).
When I run the package with dtexec /FILE Import.dtsx /Reporting V /ConfigFile "C:\Italy.dtsConfig" I still see the output telling me that "The package is attempting to configure from the XML file France.dtsConfig".
I thought I could override the configuration by providing a different dtsConfig file for each country. Is this possible? What am I doing wrong?
I am using SQL Server 2008 R2 and I was getting the same issue with the Configuration override apparently being ignored. I found the trick I needed was to remove the XML config setting from the package (Package Configurations), and then when running the package the XML configuration file you specify is applied. There is however no message emitted about using the file (and since you removed the XML configuration definition from the package, that message is also not emitted).
MSDN has an explanation (go to section "Understanding How SSIS Package Configurations Are Applied at Run Time") that at first didn't make sense to me, but after finding that not having an XML configuration file defined gives the desired result, I can see what it is trying to say.
In my case I was using the XML file to set the instance name of the server on which the [SSIS Configurations] table was found. At design time this was DEVServer in the connection manager object, and I want to override the value to TESTSvr. Following the rules:
"The utility applies the configurations that were specified in the package at design time and in the order that is specified in the package." So the value DEVServer is loaded from the package.
"The utility then applies any options that you specified on the command line." The value in my XML file (TESTSvr) is now loaded. I can supply any filename I like here, and it will be loaded (be it France or Italy).
"The utility then reloads the configurations that were specified in the package at design time and in the order specified in the package. ... The utility uses any command-line options that were specified to reload the configurations." Note the second part of the rule, about using the command line values. Since we currently have set the server to TESTSvr, this value is now used to load the other configuration values from the [SSIS Configurations] table that you want.
I don't have a reference to an article that documents this behaviour, but I have confirmed it. If the file specified as the configuration file in the package configurations is available at run time, it will be used in preference to the one specified on the command line.
In my experience and my opinion, this is contrary to normal behaviour where specifying something in a command should override the built-in default.
To use the configuration file specified in the dtexec command, rename or delete the file that is specified in the Configuration String of the XML configuration file in the Package Configurations Organiser.
Found a way!
In the designer simply uncheck the "Enable package configurations" option under SSIS -> Package Configurations, and save.
dtexec will still honour the supplied configuration file on the /conf switch, but it will no longer attempt to use the design time configuration file even if is accessible.
I still agree that this is strange behaviour, and that the /conf should override design time settings no matter what.
This should work
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Specify the complete config file location within double quotes
Edit :
When you have deployed your package in MSDB then the command to execute the package is
DTEXEC /SQL "\Package.dtsx" /SERVER "Server Name"
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Else if you have deployed in File System then
DTEXEC /f "Physical Package Location"
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Check whether you are pointing to the correct package
MSDN
You can use the /ConfigFile option to load additional configurations
at run time that you did not specify at design time. However, you cannot
use the /ConfigFile option to replace configured values that you also
specified at design time
I am creating a dtsx package that I am running through a bat file. At design time, I created a package configuration that points to a specific location. When I am running the package at run-time, however, I am setting the ConfigFile to a package configuration in a different location. It appears, however, that the package is still running off of the configuration set at design time. Does any one know why this might happen? Any ideas on how I can get the package to run with this different configuration? The following is what I am running in my bat file.
dtexec.exe /f "mypackage.dtsx" /ConfigFile "[some_path]/newconfig.dtsConfig"
If you are using SQL Server 2008, then the order in which package configurations are applied in is as follows:
Design-time configurations
Run-time configurations (i.e. those specified by the /ConfigFile parameter
Design-time configurations again
Therefore any variables set in the design-time config cannot be changed using the /ConfigFile parameter.
The official solution to this is to change the path to the design-time configuration using the /Set parameter.
Details on this can be found here: http://msdn.microsoft.com/en-us/library/bb500430.aspx
I suggest having different sets of .dtsconfig files per environment (DEV, QA, PRD) and to register them as Environment Variables on the machines using setx batch command to define the Variable name and file path.
By using the same Environment Variables names on all environments you will mitigate the need to specify the .dtsconfig file at runtime.