In Windows, where is the most appropriate place to store an executable that will be ran as a scheduled task on a server?
A file share?
"C:"?
"C:\Windows"?
Others?
Stay out of C: and C:\Windows. Never put it on a file share (what if it isn't available)?
I'd just use a subdirectory of C:\Program Files (to be more precise, of %ProgramFiles% - the user's system may not be installed on C:, for instance).
Related
Working on a batch file that calls another batch file.
K:\Market Risk>call "K:\Market Risk\activate.bat"
The system cannot find the path specified.
So I set the path at the beginning of my batch file and made sure it was there:
SET PATH=%PATH%;K:\Market Risk\
K:\Market Risk>echo %PATH%
C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;
C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;
C:\WINDOWS\System32\OpenSSH\;C:\Program Files (x86)\Shoreline Communications\
ShoreWare Client\;C:\Program Files\dotnet\;C:\Program Files (x86)\Microsoft SQL Server
\150\DTS\Binn\;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\
WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files (x86)\
Shoreline Communications\ShoreWare Client\;C:\Program Files (x86)\Common Files\Oracle\
Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;
C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;
C:\Program Files (x86)\Shoreline Communications\ShoreWare Client\;
C:\Users\Kyle.Dixon\AppData\Local\Microsoft\WindowsApps;C:\Users\Kyle.Dixon\AppData\Local\
Programs\Git\cmd;C:\Users\Kyle.Dixon\AppData\Local\atom\bin;C:\Users\Kyle.Dixon\Documents\
R\R-3.5.2\bin\R.exe;C:\Users\Kyle.Dixon\Documents\R\R-3.5.2\bin;C:\Users\Kyle.Dixon\
AppData\Roaming\MarketView\MarketView ExcelTools\;K:\Market Risk\
However, I'm still getting the same error:
K:\Market Risk>call "K:\Market Risk\activate.bat"
The system cannot find the path specified.
Has anyone had this issue before?
I recommend reading What is the reason for "X is not recognized as an internal or external command, operable program or batch file"? It should help to understand how the environment variable PATH is managed by Windows. It is unfortunately not really good managed by Windows which cause lots of problems because of no command is available to safely add/remove a folder path to system or user PATH. The results of missing such a command or executable written by Microsoft to safely update PATH with applying all necessary error checks are lots of not good coded scripts which quite often corrupt system and user PATH stored in Windows registry on trying to update them.
My recommendation is opening Windows Control Panel - System and Security (on View by: Category selected) - System - Advanced System Settings - Environment Variables as administrator and cleaning up both Path environment variables, the user Path (upper pane) and the system Path (lower pane). The window Environment Variables can be opened also by clicking on Windows Start button, typing on keyboard environment and Windows suggests in the menu Edit environment variables for your account and Edit the system environment variables in the language of Windows. Click on one of the two suggested items and if necessary depending on Windows version next on button Environment Variables.
The system Path should start always with following default Windows folder paths:
%SystemRoot%\System32
%SystemRoot%
%SystemRoot%\System32\Wbem
%SystemRoot%\System32\WindowsPowerShell\v1.0\
%SystemRoot%\System32\OpenSSH\
The system Path was badly updated once in the past if it does not start anymore with these folder paths exactly as written here. (The last folder path is available only on Windows 10 since version 1809 and of course Windows 11.) C:\WINDOWS stored in Windows registry and displayed on editing the system Path instead of %SystemRoot% is an indication that an installer executable or script has not good updated system Path because of replacing original folder paths with referencing environment variable SystemRoot by the expanded version. This does not really matter for these folder paths, but could have been harmful for other folder paths.
No folder path should exist more than once in one of the two Path environment variables.
Remove all duplicates in user Path as well as in system Path.
Your two Path environment variables contain three times:
C:\Program Files (x86)\Common Files\Oracle\Java\javapath
C:\Program Files (x86)\Shoreline Communications\ShoreWare Client\
C:\WINDOWS
C:\WINDOWS\system32
C:\WINDOWS\System32\OpenSSH\
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
A folder path existing already in system Path should not exist a second time in user Path and of course also not once more in system Path.
A folder path can be listed without or with a backlash in Path. I prefer folder paths without backslash at end in Path as this causes less troubles on updating Path in future on using command reg by a batch script.
Environment variable Path should contain only folder paths and not fully qualified file names.
So C:\Users\Kyle.Dixon\Documents\R\R-3.5.2\bin\R.exe is completely nonsense in Path.
After cleanup of both Path environment variables the folder paths in system Path should be something like:
%SystemRoot%\system32
%SystemRoot%
%SystemRoot%\System32\Wbem
%SystemRoot%\System32\WindowsPowerShell\v1.0\
%SystemRoot%\System32\OpenSSH\
%CommonProgramFiles(x86)%\Oracle\Java\javapath
%ProgramFiles(x86)%\Microsoft SQL Server\150\DTS\Binn
%ProgramFiles(x86)%\Shoreline Communications\ShoreWare Client
C:\Program Files\dotnet
For the last path it is better to keep C:\Program Files and do not use %ProgramFiles%, except there is C:\Program Files\dotnet and C:\Program Files (x86)\dotnet which I don't know as I don't have such a directory on my Windows computer. For the reason see the Microsoft documentation page WOW64 Implementation Details.
The user Path should be finally something like:
%LocalAppData%\atom\bin
%LocalAppData%\Microsoft\WindowsApps
%LocalAppData%\Programs\Git\cmd
%AppData%\MarketView\MarketView ExcelTools
%UserProfile%\Documents\R\R-3.5.2\bin
There is not much written about environment in which the two batch files are executed. So most written below is pure speculative.
I suppose that drive K: is not a drive on a local hard disk, but a network drive. So it is possible that the network resource mapped to drive K: is currently not available either because of network resource not mapped to drive letter K: or there is network connection issue or a network resource permission issue.
Windows remaps a network resource to a drive letter as once done by the user only on logon of the user because of network drive mappings are user account related stored by Windows in Windows registry. So if the batch file is executed as scheduled task with using a different account or also on user not logged in, the drive K: does indeed not exist. The scheduled task executing the batch file must be configured to use the account which has the necessary permissions to access all network resources and local directories/files which are accessed by the batch file. And it is additionally necessary to access files and folders on a network resource with their UNC paths instead of using drive letter K: of network drive not existing on execution of the batch file in this environment.
See also: What must be taken into account on executing a batch file as scheduled task?
But possible is also that the error message
The system cannot find the path specified.
is not output by cmd.exe on processing the batch file containing the command line
call "K:\Market Risk\activate.bat"
but on a command line executed on processing the batch file K:\Market Risk\activate.bat.
Therefore I suggest to remove from both batch files #echo off at top or change it to #echo on and run the main batch file from within a command prompt window, see debugging a batch file. Then it should be 100% clear which command line in which batch file is responsible for this error message.
I am currently working on a Windows batch file that will allow me to silently install git (the executable for which will be placed in the folder that the .bat file will be running from) in a pre-specified location on the file system.
I've found this article which seems to provide some suitable advice:
https://github.com/msysgit/msysgit/wiki/Silent-or-Unattended-Installation
However, I'm not entirely sure what parameters I would need to mention in my LOADINF file. I would like to pre-define the options that the user would manually select throughout the various stages of installation, so that it can run through from start to finish without prompting anything from the user.
Can anyone help or point me to a place where I can find these parameters and their available values?
Create a file, for eg. my-config.cnf (or my-config.ini) with the following content:
[Setup]
Lang=default
Dir=C:\Program Files (x86)\Git
Group=Git
NoIcons=0
SetupType=default
...
<other options as shown in the msysgit wiki>
Now, in the batch file, when you execute the installation file (say msysgit-install.exe), use /LOADINF as follows:
msysgit-install.exe /SILENT /LOADINF="my-config.cnf"
I have a setup exe, and I want its .msi file for administrative installation (see https://superuser.com/questions/307678/how-to-extract-files-from-msi-package)
But, although I see at the beginning the extraction of .msi, I can't find it.
Where is the location of this file?
Usually MSI file(s) might be extracted in different temp locations depends from who was launched (User\System\etc) and how configured setup.exe. Sometimes you can extract it with help of different command-line switches for setup.exe.
The simple way to check - launch it under user account, go to %temp% folder, most likely there should be created folder with {GUID_view_name}. Inside this folder you will find MSI file.
User's %temp% folder has different location in different Windows versions:
Windows XP\2000\2003:
"C:\Documents and settings\{user name}\Local settings\Temp" or "%userprofile%\local settings\temp"
Windows Vista\7\8\2008\2012
"C:\Users\{user name}\AppData\Local\Temp" or "%userprofile%\appdata\local\temp"
P.S. Also you can check this SO question-answer.
Snapshot a clean VM and use a program such as Install Watcher or InCntrl to record the current state of the file system. Run the setup.exe until you are on the first dialog of the MSI and take another recording. Diff and look for where the MSI and related support files appear.
I found a much better solution, Igor, gave me the idea.
I used ProcessMonitor and filtered with Process is "msiexec.exe" and Path ends with ".msi".
I found the msi in:
C:\ProgramData\Downloaded Installations\{41A70E83-DA5D-4CA6-9779-73C9330E3D13}\IQProtector64.msi
I have an (PowerBuilder) application (let's call it MyApp.exe) in a folder with a sub-directory that has all the required dlls. I am able to run this application, by adding the application path and associated path variable to Windows App Paths registry key.
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\MyApp.EXE]
"Path"="C:\\Prog32\\MyAPP;C:\\Prog32\\MyAPP\\DLL\\;"
#="C:\\Prog32\\MyApp\\MyApp.EXE"
The above runs file. I didn't even have to register DLLs.
If possible, I would like to run it using a batch file though, as users may install multiple versions of the same application in separate folders. When I tried to do the same thing in a batch file, it cannot find the DLLs.
#SETLOCAL
SET CURDIR=%~dp0
CD %CURDIR%
PUSHD %CURDIR%
SET PATH=%CURDIR%;%CURDIR%\dll;%PATH%
start "" %CURDIR%\myApp.exe
POPD
ENDLOCAL
I created this batch in the same directory as the executable, MyApp.exe. I was expecting it would find the DLLs, same way App Paths PATH setting did. The Batch file errors out not being able to find the DLLs. Do we need to register DLLs in this case? Why is it treated differently?
Notes:
If I copied all the required DLLs to the same directory as the executable (without a DLL sub-directory), it runs fine without needing to worry about PATH or registering dlls.
We used to use installShield to install before, but admins have automated scripts to copy files, they shied away from InstallShield programs after the first install. I am trying to refine the process, so what they copy will be simplified.
Thanks in advance for all your valuable comments and suggestions.-Sam
Why is it treated differently?
Because Windows is a mess when searching for libraries. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586.aspx#search_order_for_desktop_applications
There are many elements to how the search order is determined, but in general it is like this
Check for the library...
already loaded in memory
on the KnownDLL list
in the application's directory
in the System directory
in the 16-bit System directory
in the Windows directory
in the current working directory
in the directories listed in the PATH environment variable
Overall I would agree with what MSDN states on their DLL Redirection page
It is good practice to install application DLLs in the same directory that contains the application
However, if using sub-folders is how you want to organize your application,
you might take a look into using Application Manifests. Something else to try would be to set the library directory as the working directory
#ECHO off
SETLOCAL
SET "CURDIR=%~dp0"
PUSHD "%CURDIR%\dll"
start "" /D "%CURDIR%\dll" "%CURDIR%\myApp.exe"
POPD
ENDLOCAL
when i save java file error is you dont have permission to save in this location contact the administrator to obtain permission on window7
Don't store application data in the "Program Files" directory.
It is very bad design and regular users don't have write access to that directory (for a very good reason).
So even if you changed your settings locally to open up the door for viruses your application won't run on other computers.
Besides: storing a Java file in the JDK directory serves no purpose at all.
Btw: your uppercase letters are broken, as well as the dot or the comma...
That's normal - jdk/bin is the installation directory of the JDK, regular users cannot (and should not) write files there. You'll have the same problem on Linux/Unix and on Mac OS X, where installation directories are off-limits to regular users.
Write your files to the users home directory (System property "user.home", works across platforms), or let the user choose where you save stuff.
Bin directory do not allow directly to save program in it.
it is so simple, just save your .java file on desktop and then copy paste it in Bin. done ;)
If the file can't save directly to c:\program files\java\jdk1.8.0\bin\
Solution:-
Click start Menu type Notepad command in run run as administrator
Right click the Notepad run as Administrator, then type the program file can save directly to c:\program files\java\jdk1.8.0\bin\
Just try it......