I need to compile some Kotlin files and run them as described at Kotlin documentation
However, my command line keeps saying this:
C:\Users\name\Documents\Projec\Kotlin>kotlinc
'kotlinc' is not recognized as an internal or external command,
operable program or batch file.
I am a 64-bit Windows 7 user.
So I downloaded the latest version of the compiler (1.0.6 ATM) and extracted the files into my Program Files folder.
My variable path is set like this:
PATH=C:\Program Files\Java\jdk1.8.0_101\bin; C:\Program Files\kotlinc\bin;C:\Program Files (x86)\Android\android-sdk\platform-tools;
At this point I have no idea, I tried two versions of the compiler and tried changing the path variable few times.
Any help appreciated.
Windows PATH is semicolon-delimited; white space is not trimmed.
You need to remove the space between ; and C:\Program Files\kotlinc\bin\ in order for the directory to be added correctly to PATH.
Related
I am using Conan package manager on Windows to create a package. The conan command to create the package copies files to a folder within %USERPROFILE%\.conan (or C:\Users\xxxxxxx\.conan). Then from this location it builds a Visual Studio project and ultimately calls doxygen.exe to create a .chm help file in a post-build command. The doxygen command fails with:
error : failed to run html help compiler on index.hhp
Further investigation reveals the hhc.exe command executed by doxygen is failing with:
C:\Users\xxxxxxx\.conan\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation>"C:/Program Files (x86)/HTML Help Workshop/hhc.exe" html\index.hhp
HHC5010: Error: Cannot open "C:\Users\xxxxxxx\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation\html\Module.chm". Compilation stopped.
Close inspection reveals that in the error message, the ".conan" folder is missing. Sure enough, I confirmed that hhc.exe fails when the index.hpp resides in a folder that has a parent folder that starts with a ".".
Attempts to resolve this:
changing the Doxyfile setting OUTPUT_DIRECTORY to "$(TMP)/DoxygenModule" resolves the error, but creates the .chm file in another location, which I do not prefer.
navigating to the 8DOT3 name of the ".conan" folder, which is "CONAN~1", to run the hhc.exe command, succeeds, but unfortunately I have no way of getting conan to use this 8DOT3 path for creating the package. E.g. C:\Users\xxxxxxx\CONAN~1\...
I can live with the using the %TMP% folder but would prefer generating the .chm in the current folder. Anyone have any ideas?
HTML Help Workshop v1.31 is installed on my machine at C:\Program Files (x86)\HTML Help Workshop, probably from a Visual Studio installation (not sure). I attempted using a version downloaded from Microsoft website (v1.30) as well, which made no difference.
Other info: Conan version 1.18.0, Doxygen version 1.8.14, Windows 10 Version 1809
Unfortunately not a solution, but this is a known limitation in the hhc.exe, see: https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
Edit 2019-11-15:
I've just pushed a proposed patch to github (pull request 7402, https://github.com/doxygen/doxygen/pull/7402).
This proposed patch changes inside doxygen from the current directory to the short named current directory, but just for the HTML Help compilation.
Edit 2019-11-16:
Code has been integrated in the master version on github.
This is not an answer either. Actually, you found the answer and workaround[s] yourself.
Use OUTPUT_DIRECTORY to specify a directory containing no folder names beginning with periods.
The error you described is a known issue of the MS HTML Help compiler. More general, the HTML Help compiler does not like some folder and file names. Try and stick with these characters _, a..z, A..Z, 0..9. Do not use these signs in particular ., -, # .
Please note that the proprietary CHM file format is about 20 years old (Windows 95, ...). HTML Help is in maintenance mode, which means no new features and bug fixes are expected for either the runtime or the compiler. All mainstream development on HH has stopped.
There is no way to avoid this error if a directory name above begins with a period. Not even if only the necessary files are written by Doxygen and compiling of the index.hhp is done by a third-party tool like FAR HTML using your path that contains .conan. This is because all applications are using the faulty HHA.dll.
The above applies of course to the entire workflow you have described. Maybe you can interrupt it.
Doxygen can be configured not to call the HTMLHelp compiler. Just uncheck the GENERATE_HTMLHELP option (DoxyWizard: Experts > Topics > HTML). You have all files generated by Doxygen in your preferred output directory - but of course without the CHM file. This can be imported later e.g. by HelpNDoc and compiled as a CHM file in another location.
If you can interrupt the workflow and can also make changes to Doxygen's settings, then a preference setting of OUTPUT_DIRECTORY to e.g. C:/CacheMenu/CONAN~1/DOXYGE~1 also works as expected (here used as test case).
No matter what you do, your workaround and copy and paste from another directory outside is a quick solution at this stage. Please note the EDIT in #albert's answer.
I have several build dirs for different configurations (using an external build system from the CLI), so the executable name duplicates the desired cwd:
path/to/build1/executable
path/to/build1 (desired cwd)
path/to/build2/executable
path/to/build2 (desired cwd)
Is there a more convenient way to run the executable from the directory containing it, without typing the path twice?
The most likely solution would be with a variable like ${workspace_loc} under "Arguments -> Working directory", but I could not find a suitable variable.
Tested on Eclipse 4.6.3.
If you use managed build you can get away with specifying config_name appended to workspace_loc, i.e. if you project is called "test" this should work (tested on linux)
${workspace_loc:test}/${config_name:test}
My app prints
Current working dir: /home/elaskavaia/workspace/test/Debug
I have a problem using 'xcopy' command.
I'm building a C# project with msbuild. At the end of the build, a batch file is called to copy my assemblies from Debug/Release to some other folders.
Here is the problem, my build fail and the error log is 'xcopy is not recognized as an internal or external command, operable program or batch file'.
The path is correctly set, xcopy do works from a windows command line and from the visual studio command line (the one set with the project environment).
I tried to set the path in the batch file but it doesn't help.
Any suggestion?
I'm using windows 7
Cheers :)
I encountered the same problem.
It seems to be a problem with the path environment variable within Visual Studio.
When I added a "path" statement to the beginning of my build event, it produced the following output:
PATH=
This seems to indicate that the path is empty within the VS build environment.
When I specify the full path to xcopy like this, the problem went away:
%systemroot%\System32\xcopy ...
I'm not sure what caused Visual Studio to lose it's path.
Set Environment variable PATH = %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\
This is not a problem with Windows 7 or 8. It's actually a problem with applications that update environment variables such as PATH.
The PATH is stored in the Registry as an "Expandable string value" (REG_EXPAND_SZ), but a lot of applications write it back to the Registry as a "String Value" (REG_SZ). If your path contains anything like %SYSTEMROOT%, this will not be expanded into C:\Windows (or whatever yours is) if the path is stored in a REG_SZ.
The fix is simply to edit your path manually from the control panel. You need to make a change (eg add a ; to the end of the path) and then apply it. This will fix up your path in the Registry to be a REG_EXPAND_SZ.
(Go to the System Control Panel and select Advanced System Settings. Edit the Path Environment variable in the lower box, and that should fix it.
You can tell whether your path is broken in this way by opening a command prompt and typing PATH. Your path will be listed. If you can see anything enclosed in % % then your path is not being expanded.
It happened to me after I updated one of my Visual Studio extensions, during which Visual Studio was closed and reopened by the updater. I could no longer properly build my project. I closed Visual Studio and reopened it and the problem went away.
I just experienced this for the first time with a batch file I use to copy an Access front-end app to the user's local machines. Their environment is a mix of Windows 7 & 8 and 32-64 bit machines. I noticed that the xcopy.exe was both in the System32 and the SysWOW64 folders and I wondered if there was some conflict. So -- I copied the xcopy.exe into the folder where the batch file resides and it now seems to be working. Just thought I'd share this.
Eileen
I also had a problem with xcopy (same error message) - with a very simple batch program that I use to backup files to a removable drive. Have been using that program for at least 5 years with never a problem. Then yesterday xcopy is unknown to Win7. The replacement of xcopy with %systemroot%\System32\xcopy at each instance solved the problem. Very strange.
Go to environment variable and correct PATh including ; in last.
It will work, this is not at all related to OS or Technology.
It's working for me, Not even need to restart OS, Just open new command prompt.
[Fixed for me]
After adding the correct paths to "Path" environmental variable it still doesn't work (for cmd and VisualStudio) (even after restarting the PC).
The problem was in broken register parameter:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
ParameterName=PATHEXT
I had the value .wlua;.|exe. Maybe was broken after installing something.
Everything works again after changing it to:
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
Hope this helps if nothing other works.
Something has gone wrong with my java set-up on my computer, obviously, but I can't figure out what it is until I get some more info.
When I try to run Eclipse, it give me an error:
Failed to load the JNI shared library "C:\Eclipse\1234\tools\jdk1.5.0_14\bin\..\jre\bin\client\jvm.dll"
I want to know how to find out what the rest of that filepath is. "\bin..\jre\" doesn't help me much. I suspect that it's 2 paths concatenated, but I'm not sure.
I've tried running Eclipse from the command line, but the error shows up only in the popup window.
Also, where does the JNI path get set, anyway?
I've looked at my JAVA_HOME environment variable, but it only contains "C:\Program Files\Java\jre7\bin".
This JNI-path-corruption... thing happened after I ran an installer -- nope, no uninstaller :(
C:\Eclipse\1234\tools\jdk1.5.0_14\bin\..\jre\bin\client\jvm.dll
I want to know how to find out what the rest of that filepath is. "\bin..\jre\" doesn't help me much. I suspect that it's 2 paths concatenated, but I'm not sure.
That is the full path. On all file systems that I've used ".." indicates the parent directory (i.e. up one directory). So the path refers to:
C:\Eclipse\1234\tools\jdk1.5.0_14\jre\bin\client\jvm.dll
As for how eclipse has decided on trying to use this path, I'm not sure.
your JAVA_HOME settings are wrong , as JAVA_HOME should point to the directory just above bin , and in the bin directory java executable files e.g. java.exe , javac.exe , appletviewer.exe must exist.
For example, if on my computer java.exe is in D:\JAVA7\bin directory my JAVA_HOME will be D:\JAVA7
After I re-named my JDK folder and deleted a JRE folder (I actually had to kill a process in order to delete the folder) then I edited the system variables accordingly but I'm getting error messages when I type in 'javac' or 'java' even when %classpath% shows the updated values.
Is there a hidden system variable that is still holding the older value? How can folder I get ride of the old pointer to jre folder? Is this because I ended a java process earlier in order to be able to delete the JRE folder? If so, how can I fix it now?
Thank you so much in advance for helping me out.
This is copied from the command window:
C:\jdk1.7>java
Error: could not open `C:\Program Files\Java\jre7\lib\i386\jvm.cfg'
C:\jdk1.7>javac
'javac' is not recognized as an internal or external command,
operable program or batch file.
C:\jdk1.7>echo %classpath%
.;C:\jdk1.7\bin;C:\jdk1.7\lib;C:\jdk1.7\jre\bin;C:\ANT\lib;C:\ANT\bin;c:\documen
ts and settings\homayoon\my documents\selenium tutorial\;
C:\jdk1.7>
If you renamed the folder manually, there will be a lot of registry entries that point to the old name.
Change them with RegEdit; or, faster, reinstall Java.