I'm using a script to get the subversion head revision number from a subversion repository derived from the script found at http://blog.guymahieu.com/2008/06/09/getting-the-svn-head-revision-number-from-a-windows-batch-file/. The script works fine when called from a normal command line, but when calling the same batch file as pre-build-event with path $(ProjectDir)/../getSVNRev.bat the command svn is unknown.
The path to svn.exe is in the standard system %Path% but it seems that VS uses another path. I echoed the %Path% variable in the batch file and the %Path% seems to be set to the VC++ binary path. I added the path to svn.exe to the VC++ binary path, got that echoed, but still the svn.exe was not found.
I even copied svn.exe and all dlls into system32 but still, the command svn was unknown to the VS command line.
Are there any other locations I should add the path, so that the pre-build event on VS.NET 2003 recognizes svn.exe?
Thanks,
Norbert
I think you want to go to Tools->Options->Projects and Solutions->VC++ Directories, then make sure that "Show directories for" is set to "Exectuable Files" and your platform is set to Win32, then add the directory with the executable to the list, or just add $(Path) to the list so that your system paths end up in there.
Related
I have an application named DriveMaster which I want to run from command line with different arguments. The application is residing in:
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster.exe\"
Now in Windows - Run, if I open command prompt and want to give a command like:
DriveMaster /s:Scriptname.srt
This should be able to launch DriveMaster with that particular script.
How can I do this? What should I need to add in the Environment variables so that I can run the application from command prompt?
In Windows 7:
In the menu Start click Computer
In the context menu, select System Properties
Select Advanced System Settings -> tab Advanced
Select Environment Variables Menu System Variables to find the PATH variable and click it.
In the editing window, change the PATH, adding value: ; C:\Program Files (x86)\ULINK DM2012 PRO NET\v970
Open Run and type: DriveMaster /s:Scriptname.srt
That's all.
When you're in the command prompt the working directory is given in the prompt:
C:\Users>
Here, I'm in the folder C:\Users. If I want to run a program or a script in the folder I'm currently in, I can use its name alone (e.g. DriveMaster). If the program is outside my working directory, I can't call it like that because there could be many DriveMasters in different folders throughout my computer. I can either change my directory to be the one that has this program, or I can specify where in the filesystem it's located.
Changing the directory and running:
C:\Users> cd "C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\"
C:\Program Files (x86)\ULINK DM2012 PRO NET\v970> DriveMaster
Specifying the full path:
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster"
(I need to use quotes here because the folder names have spaces and my command prompt may not know if it's part of the folder name or the beginning of another command or argument.)
On the same line I call the program, I can choose a number of arguments (also called options, switches, flags) to change the way to program behaves. If my program accepts another file and wants it in the form /s: and-then-the-filename, that file also needs to be in my working directory. If it lives somewhere else, I can use the full specification, like I've done above.
Environment variables are a little more complicated of a topic, but there is one we might be interested in here. The Path environment variable is a list of folders that the command prompt will look in when you try to use names of files that aren't in your working directory. If I know I'm going to be using this program frequently and like where it is, I can add its folder to my Path so that I can access it with just DriveMaster in the future:
set PATH=%PATH%;C:\Program Files (x86)\ULINK DM2012 PRO NET\v970
(If I mistype that command, though, I could break other things in a way that would be hard to fix.)
In a file name drivemaster.bat whch would be located at some point in the path,
#echo off
setlocal
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster.exe" /s:Scriptname.srt
where Scriptname.srt would need to be quoted and supplied with a full pathname if it's not in the current directory.
Oh you want to type DriveMaster /s:Scriptname.srt
Then use
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster.exe" %1
in that script in place of the original "c:..." line.
edit : removed stray terminal backslash from ...exe
I'm trying to override the windows find command, so that I can call another implementation of find. The other implementation is provided by MSYS and located in C:\MinGW\msys\1.0\bin. On Windows 7, I can open up a CMD, and run:
SET PATH=C:\MinGW\msys\1.0\bin;%PATH%
Since that prefixes the MSYS path before the C:\Windows\System32\ path, when find is called within CMD on Windows 7, the MSYS version executes.
That command doesn't work with Windows 8.1. When I call find in CMD on Windows 8.1, it defaults to the Windows implementation no matter what I do. Is there a way to override it on Windows 8.1?
I'm looking for a solution that only changes the path information of the current CMD instance. For my purposes, I'd rather not have to use powershell (even though the path setting works as expected in powershell).
Thanks!
When you run cmd.exe, make sure that you are not running the command from the C:\Windows\System32 directory (that's where it opens automatically for me). When you are in a directory with a matching command (in this case MS' find.exe) that local copy will take precedence over your PATH variable, even if your MSYS find.exe is listed first in the path.
So, to get it to work for me I run cmd.exe, then
C:\WINDOWS\system32>SET PATH=C:\msys64\usr\bin;C:\Program Files (x86)\CodeBlocks\MinGW\bin;%PATH%
If I run where find I get
C:\WINDOWS\system32>where find
C:\Windows\System32\find.exe
C:\msys64\usr\bin\find.exe
C:\Program Files (x86)\Git\bin\find.exe
If I change directories and run where find I get:
C:\WINDOWS\system32>cd C:\
C:\>where find
C:\msys64\usr\bin\find.exe
C:\Windows\System32\find.exe
C:\Program Files (x86)\Git\bin\find.exe
My path is slightly different because I'm trying this with MSYS2, but the same should apply to the older version of MSYS.
Good luck #mikewesthad!
My goal is to add a few executables to my PATH (for example, chrome), so that I can call
> chrome
from the command prompt and it will launch Chrome.
I know I could add Chrome's containing directory to my path (set PATH=%PATH%<chrome_path_here>;), but since I have a few executables I want to add, I'd rather make a new bin directory that contains symbolic links to the actual executables and just add that single directory to my PATH.
The Chrome executable is located at
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
So I tried
> mklink chrome.exe "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
That successfully creates a symbolic link for the files (says so in output, and upon examining with > dir). I know my PATH is set up correctly, b/c when I run > where chrome it finds my new symbolic link.
However, when I try to execute chrome with my new link, nothing happens. A new empty window should appear, but nothing happens. No error message in the command prompt or anything.
What am I doing wrong? Am I misunderstanding symlinks in Windows? This is the approach I use in Linux all the time, but I'm new to Windows Cmd.
Thanks!
Most programs will not run from places other than they install location - which is exactly what happens when you try to run it from symlink.
It would be much easier to create CMD/BAT files in that folder with matching names which will launch programs from locations you want:
REM chrome.cmd
start /b cmd /c "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" %*
With Windows 7 I confirm that symlinks do not work, are simply ignored as reported in the original question.
As Harry states in his comment, shortcuts do work, and to me are simpler and easier than writing a separate script for each new command I want to enable under CMD.
He states that you need to add .lnk to your PATHEXT variable in order to do this. I affirm that this does work, and with .lnk added to PATHEXT I can simply enter the name portion of the shortcut to run the command. For example if my shortcut is named "sublime.lnk" and PATHEXT includes .lnk, I can execute the link with the simple command "sublime". Nice!
As an alternative I found that PATHEXT need not be modified if I simply type in the full name of the shortcut, including the .lnk, at my CMD prompt. E.g., I created a shortcut named "sublime.lnk" under %HOMEPATH%/bin, pointing to "C:\Program Files\Sublime Text 2\sublime_text.exe".
Now by placing %HOMEPATH%\bin in my %PATH% I can run sublime via the command "sublime.lnk".
Either of the above are the best way I know of giving access to various commands from around Windows' filesystem from a CMD prompt. I'm not a Windows expert though, and welcome a better or more standardized solution to this problem.
P.S.: I just found out the hard way that you need to ensure the "Start in:" property of any shortcut you use in this fashion is blanked out, or your program will not start in the directory you invoke the shortcut from.
P.P.S.: On a related note, I discovered how to run Windows Explorer (or its replacement) on the directory your CMD session is logged in to: start ..
I have installed ActivePerl on my Windows OS. I have followed below URL
procedure to install
ActivePerl Installation
After having done that, I have tried to run "perl -v " on the command line. But it reports the following error.
The system cannot execute the
specified program
What do I need to do to solve these issues?
I was facing a similar issue... but the thing was that I could execute the file by right clicking the file and opening it with perl command line interpreter.... but still the perl-v command would give the error... all I had to do was execute this command
set PATH=C:\Perl\bin;%PATH%
This solved the issue...
You need to make sure the directory where the Perl executable lives (it might be C:\perl\bin, but basically wherever you told ActiveState Perl to be installed) is in your PATH environmental variable (you can find the variable value by typing set PATH command on command line prompt in Windows).
If you're not sure where you installed Perl to (and can't find it in the default C:\perl\bin), you can find the directory by going to Start menu, finding ActiveState Perl folder, and right-clicking on "Perl Package Manager" icon, then pick "Properties" from the right-click menu. Properties window (in the "Shortcut" tab) will have a "Target" line showing the directory.
I was getting a similar error after installing ActiveState Perl on Windows 8 x64 bit edition and trying to invoke 'perl' at the command line.
'perl' is not recognized as an internal or external command, operable
program or batch file.
I remember selecting the option during installation to add the Perl directory to the system PATH environment, and after checking the system properties, it was indeed showing in the system PATH.
I tried installing 'Microsoft Visual C++ 2008 x86 and x64 redistributable setup' files as suggested by a few places but it still did not resolve the issue, until I tried some of the suggestions in this thread.
At the command prompt I entered:
set PATH
And surprisingly it did not list the Perl directories as being included in the PATH variables.
So to remedy that I entered this into the command prompt and hit enter:
set PATH=C:\Perl64\bin;C:\Perl64\site\bin;%PATH%
(The directory paths are for the 64 bit edition of Perl, adjust according to your installation) the %PATH% portion is important and ensures your existing settings are kept and not wiped out and overwritten when you set the PATH.
That fixed it and entering 'perl -v' into command prompt successfully replies your Perl version. If you had a PowerShell window open before setting the PATH variable, you will need to close it and re-open another instance of PowerShell.
I believe the original underlying issue was something to do with different PATH variables for 32-bit and 64-bit environments and possibly some internal Windows redirection that takes place automatically.
This doesn't sound like a problem with PATH - I would expect it to give the message 'perl' is not recognized as an internal or external command, operable program or batch file.
I have not seen this error message, but http://nirlevy.blogspot.com/2008/03/system-cannot-execute-specified-program.html makes some suggestion for related programs.
Or maybe ask on an Active State forum.
I had the same error. I was able to solve it by changing the order of the Perl64 entries in the PATH variable in the Environment Variables. I moved the C:\Perl64\bin to be before C:\Perl64\site\bin and it worked.
I had a similar error which was solved by adding the .pl extension to the script name, which I had forgotten to do.
I could not get it to work otherwise even with my Perl's location (C:\Apps\Perl\bin) verified as in %PATH%.
The problem lies in the installation directory.
The Perl PATH variable will be set to C:\Program Files\perl (depends on 32 or 64 bit of course), BUT, the default installation directory is C:\perl. This is kind of sneaky actually as you would assume the installer would be more intelligent about this, but it sets the environment variable to that directory no matter WHERE you install the damned thing.
My basic problem is that if I run GCC from the windows command line (cmd.exe in Windows XP) and it does nothing: no .o files are created, no error messages, nothing. It will only throw an error message if I use DOS-style paths, but nothing else. When I run from the Cygwin shell then it will throws error messages as appropriate for the errors in the source and produces the .o files as it needs. Using 'make' from the DOS command line doesn't work either. Has anyone encountered this behavior before?
I've actually made some progress on this. Background:
I have WinAVR installed and its bin directories set in my PATH. WinAVR is GCC and associated development utilities but for the AVR 8-bit microcontroller. It shares many utility names with regular GCC.
In the past I remember Cygwin putting its bin directories in the PATH. It didn't seem to do this this time, so I put 'C:\cygwin\bin' into the PATH and then later 'C:\cygwin\usr\bin' there as well.
The latest release of Cygwin has issues with the way it handles files. Basically, gcc.exe is not an executable, but a type of symlink to the actual executable (which is either gcc-3.exe or gcc-4.exe depending on what you have installed). In the BASH shell these symlinks are easily resolved, in cmd.exe they are not. This means that if you attempt to enter 'gcc' into cmd.exe as a command it will respond 'Access is denied'. The solution for that is to call the actual GCC file name (gcc-4) instead of the symlink.
The solution seems to have come by rearranging my PATH. To edit the PATH environment variable, right click on 'My Computer' and go to properties, then Advanced and then Environment Variables. Under 'System Variables' find 'Path' and double click it to edit. Remove all entries that have C:\cygwin in them and then go to the FRONT of the PATH and enter them there. For me it was C:\cygwin\bin and C:\cygwin\usr\bin. The important part for me was making sure that the Cygwin entries were before the WinAVR entries. I noticed that when I tried to call 'make' in cmd.exe it was calling the WinAVR version instead of the Cygwin version. This lead me to rearrange my path and after some fooling around it became clear that using gcc-4 from the cmd.exe shell was working. It then worked in Code::Blocks as well and I was off.
Alternatively, it might have just fixed itself from something else entirely. Computers have a way of doing that.
Alternatively you can delete file: gcc.exe which is a file link and rename
the actual gcc executable file: gcc-3.exe (or gcc-4.exe depends on your version) to gcc.exe