I have a strange problem which surfaces intermittently. The installer installs fine but the installation path has foreing characters. This is a pure English US language installer.
This is what I do:
g_szProductBaseDir = g_szCompanyBaseDir ^ IFX_PRODUCT_NAME;
where,
g_szCompanyBaseDir = D:\Program Files\ABC\
IFX_PRODUCT_NAME = Hardware\VMC567-CIRCLE
The special characters embed themselves before IFX_PRODUCT_NAME. In the end we have an install path with an extra folder with foreign character name.
The log says:
D:\Program Files\ABC\??\Hardware\VMC567-CIRCLE
Can anyone give me some pointer on this?
You need two backslashes for paths, otherwise you will have characters being escaped. Also, you'll probably need to put g_szProductBaseDir into LongPathToQuote() before you can use it:
g_szProductBaseDir = g_szCompanyBaseDir ^ IFX_PRODUCT_NAME;
LongPathToQuote(g_szProductBaseDir, TRUE);
Related
I have npm and node installed (tried NVM for Windows and direct installations).
When running 'npm -v' or 'node -v' in Git Bash everythings works fine. But when I try to run 'npm run dev' (or any other command) the output says that 'node command is not recognized'.
In other shells (CMD/Powershell) everything works fine.
I've checked Path variable in Windows, Path variable in Git Bash, everything seems to be correct.
Error screenshot
Path variable screenshot
Path variables cmd/procmon
Any help appreciated.
p.s. While I was trying to find an answer I saw the same question from #jameseg , maybe if he sees this one he could help.
Your PATH environment variable is quite a mess. It has duplicate entries, also has an entry C:\Program Files\nodejs\node.exe which is not valid because it should be a folder, not a file, and it has . in the middle which doesn't make much sense either.
But the main problem is that it has a stray doublequote, after C:\Program Files\Java\jdk-13.0.1\bin:
With this, effectively all the paths after it are ignored, because they are treated as part of one big quoted string (which is implicitly terminated by the end of the variable data).
To illustrate what I mean, consider this example:
This correct PATH variable...
C:\a;C:\b;"C:\c 123";C:\d;C:\e
...is interpreted as:
C:\a
C:\b
C:\c 123
C:\d
C:\e
But, this bad PATH variable where I deleted one of the quotes...
C:\a;C:\b;C:\c 123";C:\d;C:\e
...is interpreted like this:
C:\a
C:\b
C:\c 123";C:\d;C:\e
This may at first make only half sense, but it's because of the quirky way Windows parses this variable: When encountering a doublequote, it's removed from the result but toggles a flag that says whether we are now inside a quoted string. And when the flag is set, semicolons are ignored. So even if the stray quote is at the end of a path (or in the middle of it), it will have the effect of essentially quoting the rest of the variable data until the next doublequote or the end of the data.
Confusingly, you may still have where node report that it found node, because the where.exe tool does its own parsing, in a slightly different way (ignoring quotes), so you cannot rely on its output! (For example, try set PATH=c:\win""dows. where explorer will say it can't be found, yet explorer will work to open Explorer. You get the opposite with something like set PATH=x"y;c:\windows - where explorer will list c:\windows\explorer.exe, yet explorer will not work.) The reason why it works in Git Bash is probably the same: when the environment variables are translated to UNIX paths, they are parsed slightly differently than Windows would do it itself, inadvertently correcting the problematic entry in the process.
So, the solution is to remove this doublequote from your path variable.
I installed IJulia package for sublime. When I start sublime, I got ZMQ shared library not found....
I try to find ZMQ from Julia:
julia> using ZMQ
julia> println(ZMQ.zmq)
C:\Users\Nick\.julia\v0.3\WinRPM\deps\usr\x86_64-w64-mingw32\sys-root\mingw\bin\libzmq.DLL
I open Package settings - IJulia - user, modified the path in this line:
"zmq_shared_library": "~/.julia/v0.3/WinRPM/deps/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libzmq.dll",
Restart sublime, I got this:
Unable to find an entry point ... libstdc++-6.dll
What's should I do?
Environment:
Windows 7, 64-bit
Julia v"0.3.8"
Sublime text 3
Update - kernel died
I found that there's an issue here:
https://github.com/quinnj/Sublime-IJulia/issues/64
To quote:
tildebyte commented on 28 Feb
Answering my own question: libstdc++-6.dll exists in 2 places: Sublime
Text 3 Beta\Data\Packages\IJulia\windeps and
.julia\v0.3\WinRPM\deps\usr\x86_64-w64-mingw32\sys-root\mingw\bin.
i.e., the version shipping with the plugin doesn't match the one
libzmq is linked against. I fixed it by copying down ZMQ's libstdc DLL
from mingw\bin into the plugin's windeps dir. So, yes, I concur:
#M-Marz libzmq is probably mismatched to the plugin OR he's got
another libzmq somewhere in the path, which ST is finding first.
So I tried to copy the libstdc++-6.dll from .julia\v0.3\WinRPM\deps\usr\x86_64-w64-mingw32\sys-root\mingw\bin to Sublime Text 3 Beta\Data\Packages\IJulia\windeps.
Sublime stops complain ZMQ library not found or cannot found entry point; however, when I try Ctrl-shift-p, open ijulia, I got ***kernel died***.
I searched my system, found that there's several libstdc++-6.dll for several individual applications: Julia, Evernote, VLC ...
How could I figure out what's wrong?
Update - "kernel died" Solved
I found the same problem here:
https://github.com/quinnj/Sublime-IJulia/issues/60
Thanks to #GregPlowman:
Finally, after much playing around, I managed to get Sublime-IJulia
working on Windows.
Seems some file paths are processed differently. (Maybe some by
Windows directly, others by Julia with some parsing?).
In any case, care needs to be taken with file paths on Windows:
absolute or relative
quoting entire pathname (especially important if path name has spaces)
path separators ( forward or back slash / vs \ )
I played around with many combinations and got really confused.
However I think the Julia executable path should be absolute, quoted
(if spaces in path name) and use backslashes. ZMQ and kernel pathnames
can be relative, should be unquoted, and use forward slash separator.
Here's the Windows extract from Sublime user settings file that worked
for me:
"windows": {
"zmq_shared_library": "~/.julia/v0.3/ZMQ/deps/usr/lib/libzmq.dll",
"commands": [
{
"command_name": "default",
"julia": "\"C:\Program Files\Julia-0.3.5\bin\julia.exe\"",
"julia_args": "",
"ijulia_kernel": "~/.julia/v0.3/IJulia/src/kernel.jl"
}
] }
Note that to quote path name use \", and to use backslash path
separator use \.
Cheers, Greg
Lesson learnt
When an opensourse software goes wrong, the first place to find solution is the issues from github. Thanks to #tidlebyte and #GregPlowman. (Both of them fired the issue, and found solution themselves.)
Brief answer:
Solution to ZMQ Library Not Found
Step 1:
(1) Copy everything from IJulia package settings - default to package settings - user.
(2) Find ZMQ lib path
julia> using ZMQ
julia> ZMQ.zmq
"C:\\Users\\Nick\\.julia\\v0.3\\WinRPM\\deps\\usr\\x86_64-w64-mingw32\\sys-root\\mingw\\bin\\libzmq.DLL"
(3) Modify the zmq_shared_library path according to (2).
Step 2: Copy libstdc++-6.dll from C:\\Users\\Nick\\.julia\\v0.3\\WinRPM\\deps\\usr\\x86_64-w64-mingw32\\sys-root\\mingw\\bin\\ to C:\Users\Nick\AppData\Roaming\Sublime Text 3\Packages\IJulia\windeps. (Yes, overwrite.)
Solution to Kernel Died
Modify the path in IJulia package settings - user
"windows": {
"zmq_shared_library": "C:/Users/Nick/.julia/v0.3/WinRPM/deps/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libzmq.DLL",
"commands": [
{
"command_name": "default",
// "julia": "julia-readline.exe",
"julia": "\"C:\\application\\Julia-0.3.8\\bin\\julia.exe\"",
"julia_args": "",
"ijulia_kernel": "~/.julia/v0.3/IJulia/src/kernel.jl"
}
]
}
Pay special attention to the quotes on path. Especially \" for quote the whole path.
Again, thanks to #tidlebyte and #GregPlowman for their early exploration and solution. If anybody got stuck on any of above steps, please let me know.
I am using Windows 7 64bit and switched to the latest Android Studio and I am getting this error with:
Error:A problem occurred configuring project ':myproject'.
Could not normalize path for file 'C:\Users\me\Apps\Android\android\myproject\myproject:facebook-sdk\bolts-android-1.1.2.jar'.
Error The filename, directory name, or volume label syntax is incorrect
This occurred for versions
Android Studio: 1.0.1
Gradle: 2.2.1
This issue will come if the syntax is mismatched. Please find below scenario,
I did one mistake in my build.gradle file
compile files(':libs/lib_ivy_android')
and I modified later like below
compile files(':libs/lib_ivy_android.jar')
then also I got same error I did some R&D about this then finally I modified like below then no error
compile files('libs/lib_ivy_android.jar')
So this might be a solution for you.
#ScottBarta and #KenWhite solved this in the comments (the : is invalid in a filename)
The problem is that the directory name is invalid, as #Scott
indicated. Windows does not allow colons (:) in a filename, as that is
the drive separator. C: is valid, myproject:facebook-sdk is not, as
myproject: is not a valid drive letter.
Other invalid letters are
< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)
As the OP said, just remove it:
removed it and now it started working for me.
I had this same error, because I add same library in both .jar and also dependency
Like this
Comment one .... Happy coding :]
I have downloaded Cassandra community edition 2.1.2 (I know its a latest development release currently hence may not be stable). The reason being newer version of cassandra-stress tool which support YAML based configuration which enables to run the tool on my desired keyspace instead of the hardcoded "Keyspace1" in current stable version.
On Windows 7 machine when trying to run cassandra-stress via command line and specifying the path to YAML file, it is always giving error due to ":" character in path starting with "C:\"
C:\Program Files\DataStax Community\apache-cassandra\tools\bin>cassandra-stress user profile=../cqlstress-musicdb.yaml ops(insert=1)
The output is
Illegal character in path at index 10: file:///C:\Program Files\DataStax Community\apache-cassandra\tools\bin\cqlstress-musicdb.yaml
I tried different options to specify the path
giving absolute path
giving absolute path in double quotes as well as single quotes
copy YAML in the same folder and just specify the file name
copy YAML in a path without spaces because when using single quote space gives the problem
escaping ":" using backslash
ignoring "C:" from the beginning and directly starting abosolute path by "/"
tried different sample YAML file which comes with cassandra
As a next step, I am planning to download the source code and check whats going on there, or try this out on some linux machine if I am able to get hold of one in my org, but just thought to put this question is anyone could help.
Thanks.
I'm not sure what's going on there exactly, but it does seem like a bug that the new cassandra-stress has such trouble with that profile path on Windows.
I was able to make the following work:
First, copy your .yaml file to a path without spaces (like c:\temp)
Then, run the stress command using the "file:///" prefix, like the following
C:\>cd "Program Files\DataStax Community\apache-cassandra\tools"
C:\Program Files\DataStax Community\apache-cassandra\tools>bin\cassandra-stress user profile=file:///c:/temp/cqlstress-example.yaml ops(insert=1)
On Windows you may have an easier time if you install into a path like c:\cassandra rather than the default under Program Files. (Avoiding all those spaces in directory names.)
This issue is still is present in the 2.1.5 edition of Datastax Community Edition for Windows. The stack is installed under e:\cassandra and it still fails :-(. Note what is not documented is that you need to give full path using syntax like so:
file:///c:/temp/cqlstress-example.yaml
Another cruel hack is to set up a local apache server, place your yaml files there and use profile path to be served from the server like so
bin\cassandra-stress user profile=http://localhost/sample.yaml ops(insert=1)
I got this error while (re)building, using cygwin make.exe version :3.81.
Error : *** target pattern contains no `%'.
This error is due to a presence of a ":". Therefore it no longer supports windows paths.
You need to download version 3.80 and replace the make.exe in the \bin directory.
Apparently it needs cygintl12.dll too.
rollback to make 3.80 (Geant4)
cd /usr/bin
mv make.exe make_381.exe
wget http://geant4.cern.ch/support/extras/cygwin/make.exe
chmod +x make.exe
install libintl2 from cygwin setup for the required cygintl-2.dll
I got the same error when trying to build a project on Linux or OSX, that was previously built on a Windows machine and had some .o.d files hanging around in the output folder.
Once I manually deleted the .o.d files the problem was resolved. Apparently the "Clean" command of my IDE (CodeLite in this case) wasn't deleting the .o.d files.
Most likely due to the presence of a colon following a drive letter. For example consider
build : $(NativeHeaders)/*
If
NativeHeaders=../../../cpp/generated
then all is well, but
NativeHeaders=C:/dev/folder/cpp/generated
results in the error that you get.
I was getting this error because I didn't have a Tab (\t) character at the beginning of my commands. I had expandtab in my vim set so it was replacing a tab character with 4 spaces. When I turned that off and changed spaces to a tab it was fixed
I had the target pattern contains no '%' error while building with the Android NDK using cygwin.
I found the following link helpful:
Errors Generated by Make
‘missing target pattern. Stop.’
‘multiple target patterns. Stop.’
‘target pattern contains no `%'. Stop.’
‘mixed implicit and static pattern rules. Stop.’
These are generated for malformed static pattern rules. The first means there’s no pattern in the target section of the rule; the second means there are multiple patterns in the target section; the third means the target doesn’t contain a pattern character (%); and the fourth means that all three parts of the static pattern rule contain pattern characters (%)–only the first two parts should. If you see these errors and you aren’t trying to create a static pattern rule, check the value of any variables in your target and prerequisite lists to be sure they do not contain colons. See Syntax of Static Pattern Rules.
And so, my solution included changing my system variables from Windows format to Unix format like so:
Instead of C:\Android\android-ndk-r10c, I used /cygdrive/c/Android/android-ndk-r10c for the NDK path.
Similarly, I changed the NDK project path to /cygdrive/c/Android/project/src/main/jni.
In my case I was using CMake under Cygwin when I got this error. It turned out the Windows version of CMake was executed. Subsequently, Windows paths were used in the make file. I installed Cygwin's version of CMake through the setup program and got it working.
I had this problem on Linux when the build directory contained a ":" caused by doing a mercurial checkout which created a directory named "server:port".
I had to change the following in my make file to be compatible with Make_381:
before:
ARDUINO_BASE_DIR = C:\programs/arduino
now:
ARDUINO_BASE_DIR = \\programs/arduino
Try this if you're running Eclipse C/C++ and referencing files from Cygwin under Windows, make sure c:/cygwin/bin or c:/cygwin64/bin comes after your preferred compiler tools in your Windows Path environment.
Example:
Path = ;C:\yagarto\bin;C:\yagarto-tools\bin;C:\cygwin64\bin;
After making the changes, exit Eclipse and restart for it to take effect (simply restarting Eclipse without exiting won't fix the problem.
In my project, obj folder was probably corrupted and I was getting this error. Manually deleted obj folder. Then ndk-build completed fine.