Running the Config Wizard via the start menu (Windows 7) simply fails. Running it from the command prompt shows the infamous
'C:\Program' is not recognized as an internal or external command, operable program or batch file
I know this is due to the space in "Program Files" (dir C:\pro* /x doesn't show C:\Progra~1).
The solution I've found for this is to replace C:\Program Files\... with "C:\Program Files\...".
My question is this:
Since the WebLogic config wizard runs from config.cmd, which is loaded with variables for path names, do I have to update Windows system environment variable PATH and put quotes around all path names that have a space (since I don't know what WebLogic is looking for)?
Update:
I tried this and received Files was unexpected at this time. Which made me think I was off with the quotes, but they are paired properly around every path with C:\Program Files. A search on this error resulted with this advice...basically the double quotes are the cause.
If the lack of quotes causes the first problem, and the presence of quotes causes the second problem, what to do? It's a loop...
I installed another JDK in a location with no spaces (still got the error because I didn't change any environment variables because work site will change them back, breaking things).
The install docs in chapter 4 say:
To begin domain configuration, navigate to the
ORACLE_HOME/oracle_common/common/bin directory and start the
Configuration Wizard.
On UNIX operating systems:
./config.sh
On Microsoft Windows operating systems:
.\config.cmd
Which implied at a command prompt (to me anyways). I was reading another site for help and the guy said to update config.cmd to point it to new JDK location instead of JAVA_HOME.
Instead of right clicking on config.cmd to edit it I double clicked it and lo and behold...this nice domain creator GUI opened up where I could specify which JDK to use. Done! No errors...
If that little tidbit were in the docs it would've save me a lot of time and frustration. And no, I'm not a server admin type, just a dev who needed a local web server for testing purposes.
I hope this helps someone.
Related
This question already has an answer here:
VS code terminal can't find AWS SAM even though windows terminal can
(1 answer)
Closed yesterday.
So I downloaded the MySQL installer from https://dev.mysql.com/downloads/installer/. I then went through the process of setting it up via the installer etc. After this was complete, I went to test the command in both Windows PowerShell and CMD, but neither worked.
I looked everywhere I could online to find out what the issue was, but nothing really worked. I found a post that said to add the MySQL path to the main system PATH and so I did. The command I used was:
SET PATH=%PATH%;C:\Program Files\MySQL\MySQL Server 8.0\bin
I also manually edited my environment variables and checked everything there. HOWEVER, a really weird thing is that when I run that command in cmd the mysql --version command WORKS! When I run the same command in Powershell it doesn't, and when I close Windows Terminal and re-open it, the command no longer works in cmd! I really have no idea whats going on. The error message I receive in PowerShell is:
PS C:\Users\User> mysql --version
mysql: The term 'mysql' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
And the error message I receive in CMD is:
C:\Users\User>mysql --version
'mysql' is not recognized as an internal or external command,
operable program or batch file.
If anyone could give me a hand, that'd be amazing, thanks.
Adding to the PATH the way you did is only temporary. It lasts as long as the terminal is open, and when the terminal is gone, so is the change to the path. Use setx instead of set to make it permanent, or make the change using the UI in Windows settings. To do the latter, open the Settings dialog and type Environment into the search box, and then choose the option to change the system environmental variables. When the System Properties dialog appears, click the Environmental variables button at the lower right.
How can I get ejabberd to run an external auth script on windows?
So far- I've modified the file
C:\Program
Files\ejabberd-15.06\lib\ejabberd-15.06\priv\cfg\ejabberd.yml
to comment out the existing auth_method directive and instead added this:
auth_method: external
extauth_program: "D:\\DROPBOX\\Dropbox (Personal)\\EJABBERD\\auth\\ejabberd-auth.exe"
However, when I try to connect to the server- I see nothing in the logs indicating an attempt to run the script. I've even tried changing it to a non-existant file to see if that will log an error of some sort, but nothing.
All I get are "Accepted connection" type of logs.
In case it matters- upon start I do get several "unknown option" errors, including "ejabberd_config:validate_opts:752 unknown option 'auth_method' will be likely ignored" - however it seems this is a known, cosmetic-only error (see: https://github.com/processone/ejabberd/issues/630)
I do not use Windows, but, you should try playing with Erlang open_port command:
open_port({spawn, "YOURCOMMAND"}, [{packet, 2}]).
Note that open_port Erlang documentation says:
For external programs, the PATH is searched (or an equivalent method is used to find programs, depending on operating system). This is done by invoking the shell on certain platforms. The first space separated token of the command will be considered as the name of the executable (or driver). This (among other things) makes this option unsuitable for running programs having spaces in file or directory names.
I see your path has spaces. That alone should indeed make it impossible to call your command.
That said, external_auth command has never been tested on Windows. You may need to patch ejabberd command to make that authentication through external process work. I would be surprised if it works as is.
I have heroku toolbelt installed on Windows7 (x64 HomeEd). When i'm trying to login to heroku, i recieve strange message about MySQL (though MySQL already works fine with all software installed):
Microsoft Windows [Version 6.1.7601]
(c) Microsoft Corp., 2009. All rights reserved.
C:\windows\system32>heroku login
"MySQL" is not recognized as an internal or external command,
operable program or batch file.
"MySQL" is not recognized as an internal or external command,
operable program or batch file.
C:\windows\system32>
Exactly like shown - two times. As I found, heroku.bat does not invoke MySQL at any step. I think that OS runs some script (a kind of autoexec) just before or in parallel with heroku.bat, but i can't find the way used to do this. This is confirmed by the fact that when i start the other bat files the same two messages about MySQL appears.
Can you help me find how that strange script is invoked?
Detailed research shown that the reason is MySQL component, named "MySQL Fabric 1.5.3 & MySQL Utilities 1.5.3 1.5". During installation MySQL added it's location to Path environment variable. This caused to break Path variable contents with "&" symbol and any invocation of Path variable cause error
It seems that at some point a script tries to call MySQL.exe and this file can't be found. To solve this problem you should add the Directory containing MySQL.exe to %PATH%. First make sure MySQL.exe is located on your system. If you are not sure where it is, start CMD, go to your root directory (CD \) end enter dir /S MySQL.exe. This will search your drive for the file and show you the path, where it can be found. Save the path somewhere.
Now that you know where the file is is, you have to add it's location to %PATH%. To do so enter setx PATH "<NEWPATH>;%path%;" where is the path to the directory containing MySQL.EXE. Dont forget ;%path%;, this is very important. If you don't put it there it wil mess up your %PATH%.
Close the console, open a new one and type heroku login. This should fix the problem.
Now if you are not interested in fixing the error and just want to know where it comes from, you should post the code of the batch file that is executed by calling heroku login.
Just remove the C:\Program Files (x86)\MySQL\MySQL Fabric 1.5 & MySQL Utilities 1.5\;C:\Program Files (x86)\MySQL\MySQL Fabric 1.5 & MySQL Utilities 1.5\Doctrine extensions for PHP\; from your path (It is breaking things up, it gets added during MySQL installation)and add the MySQL bin path. For me it is C:\Program Files\MySQL\MySQL Server 5.7\bin
I'm unable to find the command line tools in Mercurial-TortoiseHg version 2.7.2. I checked for hg.exe file and it is present at C:\Program Files\TortoiseHg path but whenever I try running the command it fails and throws the error :
‘hg’ is not recognized as an internal or external command, operable program or batch file.
I have also added it to the windows PATH= ; C:\Program Files\TortoiseHg.
Not sure what else to look for. Please help.
Notes:
As mentioned in "Mercurial not working after TortoiseHg update", TortoiseHg v2.X.X no longer uses the hg command, but rather thg.
That means your PATH might not be updated properly to reference hg.exe of TortoiseHg.
to update your PATH, make sure not add any extra space:
set PATH=%PATH%;C:\Program Files\TortoiseHg
(no space between ';' and 'C:\...')
As mentioned by the OP Sowmya Guru, if you modify the user environment variable, a restart (or at least a new DOS windows) is necessary.
Posting my answer related to vanilla Mercurial install (not 'TortoiseHg') as it was the first page in search results, my solution was to use the 'Mercurial-3.4 (64-bit msi)' installer instead of the 'Mercurial-3.4 (64-bit exe)' from this page.
If I run Inno Setup compiler from a command line/batch file it creates an exe with the version information in the file name.
However, when I run from hudson (same command line) I don't get the version information.
Perhaps I am missing something.
Is this a known issue?
This is the way I am doing it in the iss script file.
#define FileVerStr GetFileVersion(SrcApp)
EDIT:
The env vars are all set for all users - not just my login - so the service has access to everything that the command line build does.
EDIT: See my answer for a resolution of this.
Like "tim" has said, then relative paths doesn't work as expected for defines.
#define MyAppVer GetFileVersion(SourcePath + "\..\Build\Release\MyExeName.exe")
#if MyAppVer == ""
#error MyAppVer - Version information not found!
#endif
By prefixing with SourcePath then the relative path will start from the path where the InnoSetup-script is located.
You are likely running Hudson on Windows given the technology mentioned.
When there is a discrepancy between what happens on the command line and what Hudson does, it is often because Hudson is running as a service on Windows. This means it is running as the service user, which is distinct from your login account.
I would look for an environment variable that you have defined in your user profile that may enable this behavior, that is not being set for the service user.
I am not exactly sure how to describe how I "fixed" this/worked around it.
It seems the GetFileVersion() method does not use the same base path as the other part of the Inno functionality that determines where the source files/installable files are.
The SAME relative paths used for:
// this is for determining what files get put into the install image
[Files]
Source: ..\Build\ForRelease\MyExeName.exe; DestDir: {app}
and
#define SrcApp "..\Build\ForRelease\MyExename.exe"
#define FileVerStr GetFileVersion(SrcApp)
apparently do not use the same mechanism to resolve the file name/path. So what i did to work around this was to copy the exe file that contains the version info to two additional different locations (aside from ..\Build\ForRelease) - one where hudson starts the processes and also to the path where the inoo script is. (I am too lazy to figure out which one is the one that makes it all work.
Again, this works fine from my batch file but not from hudson. It is essentially a strange interaction with how Inno works I guess.