I am trying to start the wso2server.bat for the WSO2 Application Server. This is available inside E:\wso2as-5.3.0\bin. But I am currently encountering this error when running the file from the windows command prompt.
My Environment Variables are as follows.
User Variable:
PATH: F:\ESB\wso2as-5.3.0\bin
System Variable:
JAVA_HOME: C:\Program Files (x86)\Java\jdk1.8.0_144
Path: F:\ESB\wso2as-5.3.0\bin
I've tried changing the Path Variables but I keep on getting this same error in starting the server.
Any suggestions in this regard will be much appreciated.
Right Click My Compuer -> Advanced -> Environment Variables -> System Variables -> Select Path variable -> append the below value.
Your user variable should look something like
F:\ESB\wso2as-5.3.0\bin;C:\WINDOWS\system32
Note: I am assuming you installed your windows in C drive.
Related
I've got a .ps1 script that I use to open a new instance of powershell as a different user:
runas /netonly /user:******\******* powershell
Until today it worked fine but now it returns the following error:
Attempting to start powershell as user "*******\********" ...
RUNAS ERROR: Unable to run - powershell
2: The system cannot find the file specified.
Has anyone else encountered this error before, are there any known fixes?
OP here: Solved this, didn't realise that I had accidentally overwritten a PATH Local Environment Variable. For future poor souls like me, the fix is:
System Properties -> Advanced Tab -> Environment Variables -> System Variables:Path -> add C:\windows\system32\WindowsPowerShell\v1.0
I'm sure there is a better solution however
I've installed mongoDB on my windows 10 OS. Then I tried setting its database path to some directory by moving to it and typing mongod --datapath=data in cmd, where data is the folder which is to contain the db(I've used the relative path because I'm in that directory). But message comes that mongod is unrecognized command. After some searching I found that by specifying mongod path, i.e. "C:\Program Files\MongoDB\Server\3.4\bin\mongod.exe" --datapath=data works. Similar thing happens for mongo.
I want to directly run mongod and mongo commands, I have seen people directly using it(without going to the directory or specifying the path).
For a Windows installation, by default you have to use the full path to the exe unless you add it to the PATH.
To add it to the PATH:
01) Get path to bin, something like: C:\Program Files\MongoDB\Server\4.0\bin
02) Press the Windows key, type env, select Edit the system environment variables
03) On the Advanced tab, click Environment Variables
04) In the User variables for xxxx section, select path and then click the Edit... button
05) Click New and paste your path with a trailing slash, eg:
C:\Program Files\MongoDB\Server\4.0\bin\
06) Click OK, OK, OK and restart your command window.
Source
The examples you have seen are probably based on UNIX installations which I think by default install mongo as a service (which Windows doesn't) and that is what is called in those examples.
To simplify startup and configuration on Windows, you can also install it as a service. See the Mongo documentation here and the
"Configure Windows Service for MongoDB' section".
This will then allow you to start and stop Mongo by simply calling
net start MongoDB
Or
net stop MongoDB
If installed MongoDB version is 6.0 or above, mongo command will not work on Powershell/cmd. If you run the command you will get the following error:
'mongo' is not recognized as an internal or external command,
operable program or batch file.
To run mongo commands, you have to install MongoDB Shell from
After installing the shell, extract the zip file, you can rename the extracted folder (mongosh-1.6.0-win32-x64) as "MongoDB Shell" and move that folder to Windows(:C) > Program Files
Now open the folder, go to bin and copy the path:
C:\Program Files\MongoDB Shell\mongosh-1.6.0-win32-x64\bin (or
C:\Program Files\mongosh-1.6.0-win32-x64\mongosh-1.6.0-win32-x64\bin)
Go to
Settings > System > About > Advanced system settings > Environment
Variables > Under System Variables, click on 'Path' then 'Edit' >
Click 'New' and paste the above copied path > Click 'Ok' 'Ok' 'Ok'
Now open Powershell/cmd, run the command 'mongosh'
You're all set to work with MongoDB
To add it to the PATH:
Add Mongo’s bin folder to the Path Environment Variable
Kindly check the link:
here
After adding bin folder to the path Environment Variable
then simply type mongo in terminal it will start working
reference : Microsoft document
set your path like this
;C:\Program Files\MongoDB\Server\4.0\bin
this is worked for me.
Based on welshGaz answer above, I edited the User Path variable but it did not work for me yet. I wasn't able to access the System Path variables.
What I noticed from the errors on the command prompt is that it what missing the "C:\data\db" directory to store its files (I don't know what those files are for just yet). So I created that directory myself and it worked.
Same problem here. I installed through the .msi file provided for windows X64bit. In the installer instructions from MongoDB (https://docs.mongodb.com/manual/tutorial/install-mongodb-on-windows/), I read that you can add C:\Program Files\MongoDB\Server\4.2\bin to the System Path. Then it asks to omit the full path to the the MongoDB binaries. That is where I think some information is missing. How are we supposed to omit the full path to the MongoDB binaries?
Currently I can get MongoDB to run mongod using:
"C:\Program Files\MongoDB\Server\4.2\bin\mongod.exe" --dbpath="c:\data\db"
For --dbpath="c:\data\db" you can replace "c:\data\db" with the path to your database.
I can also run mongo using:
"C:\Program Files\MongoDB\Server\4.2\bin\mongo.exe"
Another reason to it if you enabled any property in YAML file and it is not formatted properly. YAML looks for specific syntax like colon":"+space" ".
E.g.-
security:
authorization: enabled
use mongosh command from your terminal. mongo command no longer works for 6.0 and above.
if you are trying to connect from connection url eg mongodb://localhost:27017/yourdb try changing it to something like mongodb://127.0.0.1/yourdb
I have made some ssis packages dtsx into my local system, and wanted to execute using a powershell script. I tried this code
dtexec /File c:\ssisExample.dts
This resulted in an error of
unable to load the package as XML because of package does not have a valid XML format
First Scenario: Directly executing a file using command in PowerShell
1) Dtexec /FILE ‘\FILE_PATH_NAME\ssisPackage.dtsx’
Errors recorded:
1) The XML is not in correct format/Unable to load the packages
2) Specified File path is not proper
3) At least one of the DTS, SQL, ISServer or File options must be specified
Resolutions
1. Make sure you put path in single quotes as dtexec /FILE
‘FILE_PATH/ssisPackage.dtsx’. Copy the path from the properties
under SSIS package which is created in Visual Studio.
2. Give access to SSIS packages to be remotely acess from a third
party. For that, run Dcomcnfg.exe (requires Local Administrator)
a) Go to Component Services->Computers->DCOM Config->Microsoft SQL Server Integration Services 13.0 (whatever version is installed).
b) Right click ->properties->Security tab->Launch and Activation permission -> Check remote launch and remote activation
c) Same for Access Permission
3. Make sure that system has Microsoft.SqlServer.ManagedDTS package
a) To check that try going to folder In run command C:\Windows\assembly\gac_msil
b) Move to folder name Microsoft.SqlServer.ManagedDTS and check for the package versionr
c) Once done try giving access to these DTS packages
d) Run Dcomcnfg.exe (requires Local Administrator)
e) Go to Component Services->DCOM Config->MsDtsServer100
f) Right click to properties and onto the security tab press Edit for Launch and Activation Permission. Allow for Remote Launch and Remote Activation. Close
g) Press Edit for Access Permission -> Allow Remote Access
Your package should have the .dtsx file extension. Try this
dtexec /File c:\ssisExample.dtsx
/De[crypt] password !
If you saved your package on local file system and used the wizard to create them MS tools usually encrypt the password on file. make sure decrypt the password with /de argument
You should try this it works for me.
EXEC xp_cmdshell 'dtexec /f "c:\ssisExample.dtsx"'
How comes cmd.exe shows different values for PSModulePath than PowerShell does?
PowerShell:
\\share\user\WindowsPowerShell\Modules;
C:\Program Files\WindowsPowerShell\Modules;
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
CMD:
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
The environment variables seems to be modified 'localy' at execution ( changes are not saved to the system ).
Running cmd from within the powershell console should work as you expect :
PS>cmd /c echo %psmodulepath%
Anytime you start up PowerShell it will create a set of environment variables for that session. These can all be found under the $env (ex. $env:PSModulePath). There is a set of default values that go here. These default values are hard corded but you can of course modify those default values by changing it in one of the profile script locations.
As for CMD.exe, whenever it starts up it too will create environment variables, however it's environment variables are pulled from the OS environment.
Go to Control Panel -> System -> Advanced Settings -> Advanced Tab -> Environment Variables
I'm executing this code:
p = subprocess.Popen(['/path/to/my/script.sh','--flag'] , stdin=subprocess.PIPE)
p.communicate(input='Y')
p.wait()
It works when executing it on the shell using "python scriptName.py",
BUT when executing using PyDev in Eclipse, it fails, the reason:
/path/to/my/script.sh: line 111: service: command not found
This bash script "script.sh" contains the following command which causes the error:
service mysqld restart
So "service" is not recognized when running the .sh script from the context of PyDev.
I guess it has to do with some ENV VAR configurations, couldn't find how to do it.
BTW - Using "shell=True" when calling subprocess.Popen didn't solve it.
service usually is located in /usr/sbin, and that this directory isn't on the PATH. As this usually contains administrative binaries and scripts which arn't designed to be run by everyone (only by admins/root), the sbin directories arn't always added to the PATH by default.
To check this, try to print PATH in your script (or add an env command).
To fix it, you could either
set the PATH in your python script using os.setenv
pass an env dict containing the correct PATH to Popen
set the PATH in your shellscript
use the full path in your shellscript
set the PATH in eclipse