I'm currently trying to set up a batch file or something similar to run a search through a series of different file shares at my workplace.
I'm fairly new with CMD, but have managed to get what I'm looking for in one instance, and I'm now looking to apply that through several different files at once.
C:\Users\My Username> dir c:\Users\My Username\documents -path \appdata -prune -o *.xml /b /s >c:\users\My Username\documents\Filename
Above is the code I'm using currently to source from one file, omitting the Appdata file, as that was being returned & I didn't want its contents in the output.
However, this code above is simply a test that I've used; my end goal is to apply that to several different files accessible through the company, so for example,
DriveLetter:\SiteLocationFolder\SpecificFileShare\> dir DL:\SLF\SFS\ -path \UselessFolder -prune -o *xml /b /s >DL:\SLF\FileShareReportsFolder\
For the sake of anonymity, I've substituted in placeholder names in the file path.
My issue exists in that, in the Site Location Folder, all of the Specific File Shares are accessed through shortcuts, and I was wondering whether there was a string to allow CMD to run the dir through these shortcuts, or if I would instead have to run the batch file for each different Specific File Share?
The cmd.exe shell DIR command will not follow shortcuts in the same way as a link. If you must use Windows shortcuts, you might need to look into https://www.computerhope.com/forum/index.php?topic=80659.0
Another way would be to make links using the Windows mklink command. Use mklink /? to read about it. Search the net to learn the differences between links and junctions.
Related
i want to create a portable roblox but these bothers me
i am not so good at batch file but how to i run these exe under these directory i mean
if roblox has an update the "version-3bxxxxxxxx" will change and i cannot run the exe anymore
start "" "C:\Program Files (x86)\Roblox\Versions\version-3b33190189084158\RobloxPlayerLauncher.exe" -app
start "" "C:\Program Files (x86)\Roblox\Versions\version-3b33190189084158\RobloxPlayerLauncher.exe" -app
i try to search on the internet give nothing more =(
I hope you found the help you needed by now, sad no one responded after all this time. This is not as elegant, but I had the same issue and I did this as my solution:
cd\Progra~2\Roblox\Versions\version-* <-just need a "*" wildcard there
start RobloxPlayerLauncher.exe -app
Hope this helps others that want to run a batch file for programs like Discord and Roblox etc. as their directory names always change with updates.... The practice is annoying and I wish devs would consider end users setups.
rEd2k's answer is fine for use directly on the command line. With a batch script, you can automate it.
Search for the exact folder name with a for /d loop and use the found folder as working folder with the start command:
for /d %%a in ("C:\Program Files (x86)\Roblox\Versions\version-*") do set "rootdir=%%a"
start /d "%rootdir%" RobloxPlayerLauncher.exe -app
NOTE: if there is more than one matching folder (versions), rootdir will contain the last found folder (by string sorting on NTFS), which is probably good enough.
What paths are searched by start? Is this path list queryable via WMI, the registry, WSH shell folder constants, .NET methods, or any other Windows API?
In a cmd console, the start command is sort of magic. Say your default web browser is Firefox. You also have Chrome and Opera installed, but they are neither set as default, nor associated with any file types, nor in your %PATH%. Considering the following example:
start "" opera https://stackoverflow.com
... why does that work?
The reason this matters is that, for all the start command's strengths, it is still perilous to retrieve an application's PID or window handle when that application was launched with start. In a cmd environment I'd prefer to use wmic process call create in a for /F loop to capture the PID. So is there a way I can teach wmic process call create to launch "opera" or "iexplore" or "outlook" or "winword" or other applications as start can without fully qualifying the drive:\\path\\to\\executable?
I thought I was on to a solution by scanning HKLM\Software\Clients recursively for shell\open\command, then adding each referenced location temporarily to %PATH%:
rem // temp add installed clients to %PATH% to make "call :display" behave like "start"
setlocal enabledelayedexpansion
for %%a in (HKLM HKCU) do for /f "tokens=2*" %%I in (
'REG QUERY %%a\Software\Clients /s /f command /k /ve ^| find "(Default)"'
) do if "%%~I"=="REG_EXPAND_SZ" (
if /i "%%~xJ"==".exe" (
if "!PATH:%%~J\..=!"=="!PATH!" path !PATH!;%%~J\..
) else for %%# in (%%J) do if /i "%%~x#"==".exe" (
if "!PATH:%%~#\..=!"=="!PATH!" path !PATH!;%%~#\..
)
) else (
if /i "%%~xJ"==".exe" (
if "!PATH:%%~dpJ=!"=="!PATH!" path !PATH!;%%~dpJ
) else (
for %%# in (%%J) do if /i "%%~x#"==".exe" (
if "!PATH:%%~dp#=!"=="!PATH!" path !PATH!;%%~dp#
)
)
)
endlocal & path %PATH%
That works reasonably well, but it still falls short of what start can access. For example:
start "" wordpad
works, whereas
wmic process call create "wordpad.exe"
fails.
I remember a discussion about this very topic either on DosTips.com or here on SO but I cannot find it. Hopefully somebody does so we can mark this question as a duplicate.
We know that the batch files will search the current directory and then the path variable to find an executable. The START command also searches the following Registry path
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
So you have a few options to find the executable.
You can use the WHERE command which searches the current directory and the directories in the PATH variable.
where notepad.exe
You can also just search the path variable with a FOR command.
for %%I in (notepad.exe) do echo %%~$PATH:I
And of course you can search the registry path as I mentioned above by doing a REG QUERY.
Edit2
This may be of interest regards to what you are doing (as opposed to why something works the way it does).
From a previous answer
Can I create shorthand names for use inside cmd?
See Doskey /?.
You could do this doskey cddesk=cd "%userprofile%\desktop"
Then type cddesk.
By putting all your macros in a batch file you can autoload. Of course
you could do this with batchfiles too.
From Technical Reference to the Windows 2000 Registry, Microsoft,
2000.
AutoRun HKCU\Software\Microsoft\Command Processor
Data type Range Default value
REG_SZ list of commands There is no default value for this entry.
Description
Contains commands which are executed each time you start Cmd.exe.
Also see this batchfile https://pastebin.com/A2qLw8r3 that list
special names.
In a command prompt start shell:desktop
Or in Start - Run (Winkey + R) just shell:desktop
Edit
I'll just add some caveats here.
This is about opening executables using Start command. A massive amount of rules apply to non executable files.
Not using Start CMD pre-processes the command line and sends a FQFN to CreateProcess - so it's CMD that searches the path not CreateProcess.
https://learn.microsoft.com/en-us/windows/desktop/shell/launch is the documentation for ShellExecute. Everything ends up calling CreateProcess https://learn.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessw. Plus CMD preprocessing is detailed here https://books.google.com.au/books/about/Windows_NT_Shell_Scripting.html?id=jrdQAAAAMAAJ&redir_esc=y. Also start /? provides documentation for all three ways to start files. A summary is here Command to run a .bat file
Some fun facts. CMD if it can't recognise a file extension will attempt to execute it. ShellExecute will content sniff unknown files https://learn.microsoft.com/en-us/windows/desktop/com/filetype-key.
quote from rojo: Thanks for the link dump. I'm struggling to understand how ShellExecute can save me from having to fully qualify path names though. That was my primary question. "To use ShellExecute or ShellExecuteEx, your application must specify the file or folder object that is to be acted on, and a verb that specifies the operation." It's the "specify the file or folder object" part that I'm asking about.
It uses the 6 steps under CreateProcess and if that turns up nothing it uses App Paths. If a verb is not specified the default verb is used (usually Open). See my answer here How do i automate the simulation of right clicking a file and selecting the first option using vbscript.
So it an intersection of 4 technologies. Compatibility with MSDos, changes made by IBM for OS/2 and updated by Microsoft for Windows 2000, the standard windows way of starting programs CreateProcess, and with Windows 95 we got shell functions which are based on OLE
quote from rojo: Snap! You're right! In PowerShell I was able to create a System.Diagnostics.Process object, set $ps.StartInfo.UseShellExecute = $true, and then start "wordpad" without any file extension or fully qualified path. Setting the .UseShellExecute property to $false caused the execution to fail. How interesting!
Currently this is how I have written the code in the batch file:
C:\ cd C:\abc\xyz\build-scripts-master
call setEnv.cmd
cmd ant do-clean
cmd ant do-dist
This is not working. It just executes the setEnv and breaks out. It does not run the remaining commands
Manually this is how it works:
I first go to the folder C:\abc\xyz\build-scripts-master through the Command Prompt
Then I type in setEnv, which is a windows command script, and hit return.
Then I type in ant do-clean
And then ant do-dist
I want to automate this process and hence was trying to achieve this using batch file.
Try the following:
#CD /D "C:\abc\xyz\build-scripts-master"
#Call setEnv.cmd
#Call ant.bat do-clean
#Call ant.bat do-dist
The latter two lines assume that ant.bat is located somewhere in the current working directory or %PATH%
It is not imperative that the directory path is doublequoted in this case, just good practice.You could continue not to use the .bat extension with ant. I've included it just to make it clear that it is a batch file, and should be Called in the same way as the setEnv batch file.
it didn't run the bat files because you didn't specify the files' location in the code. As it stands right now, the script expects the .bats to exist in the working directory or it has been placed in the folder. The only way it will run the files arbitrarily is if you had placed your working location in the system variables or set the Path to the folders location. I don't know if the cmd and call are needed. I have never used them in my scripts.
I am running a Jenkins project which runs under Windows. I have a dir to find a file (html file) from my directory. This shows up
reports\All Smoke_2018-01-23T084148.270-0600\TestLog.html
I know the first directory will always be "reports" and the file name will be TestLog.html. However, the middle directory (All Smoke_2018-01-23T084148.270-0600) will depend on the date and time. So what I want to do is
echo "some string" >> reports\*\TestLog.html
it will actually be more complicated than that. But it does not appear to allow me to use an * as a directory name (as Unix would).
Is there another way to refer to the file? I know find has /s which is how I find it and findstr also has a /b. But how can I get the file name to echo to it?
I am writing a batch file on my Windows 8.1 machine. In one section of my batch file I need to start a command prompt in the "current working directory".
So far, this is what my batch file looks like:
#echo OFF
set WORKING=%cwd%
start cmd.exe /K pushd %WORKING%
exit
Let's say the batch file is located in the folder C:\Temp\Utilities. If I open an explorer window and double click the batch file to run it everything works great. A new command prompt is created in the directory C:\Temp\Utilities. However, if I right-click the batch file and select Run as administrator the working directory is no longer the location of the batch file, it's C:\Windows\System32.
Similarly, if I create a shortcut to the batch file in a different folder (for example. C:\Temp) and repeat the two steps above the results are the same. If I double click the shortcut and run it as a normal user the working directory is what I would expect. (Note, the working directory for the shortcut it's whatever is set for "Start in" of the shortcut properties, not the location of the batch file.) If I right click the shortcut and run it as administrator I again get a command prompt opened to the folder C:\Windows\System32.
I assume this is a "bug" or "feature" (if you want to call it that) in Windows 8.1 and it probably happens because execution environments for programs run as administrator are forced to run in the System32 folder? (I remember with Windows 7 this did not happen so it must be a new feature to Windows 8.)
I found one way to fix the issue and stop the command prompt from starting in C:\Windows\System32. I did this by modifying the following line in the batch file:
set WORKING=%~dp0
Doing it this way sets the working directory to the location of the batch file. With this change, no matter how I run the batch file or the shortcut (administrator or normal) the working directory ends up being the same, C:\Temp\Utilities.
The problem with this solution is I don't want the working directory to always be the location of the batch file. If the batch file is run directly then it's okay but if I run it from a shortcut I need the working directory to be whatever is set in the "Start in" property of that shortcut. For example, if the batch file is located in the folder D:\Temp\Utilities this is what I need to happen regardless of whether I run as administrator or not:
Shortcut Location Start In Property Command Prompt Working Directory
-------------------- ------------------- ------------------------------------------
C:\Temp <undefined> D:\Temp\Utilities
C:\Data\bin C:\Data\bin C:\Data\bin
C:\Data\bin D:\Temp\Utilities D:\Temp\Utilities
What this means is I can't always use %~dp0 to set the working directory in my batch file. What I need is some way for the batch file to know if it was run either directly or by a shortcut. If the batch file is run directly then the working directory is easy to get, it's just the value of %cwd%. If the batch file is run by using a shortcut, I don't know how to get the "Start in" property inside the batch file.
Does anyone know how I can do these two things inside my batch file:
1. Check whether it was run directly or by a shortcut.
2. If run by a shortcut, get the "Start in" property of the shortcut that started it.
Thank you,
Orangu
UPDATE
I found sort-of a "hackish" way to fix the issue. For the shortcut I edited the "Target" field and changed it to the following:
cmd.exe /k pushd "C:\Temp" && "D:\Temp\Utilities\batchfile.bat"
Now the working directory can be obtained by calling %CD% in the batch file and this works for both administrator and normal users. It does not, however, work for the case when I run the batch file directly. I still need to use %~dp0 in that case.
I don't like this solution, however, because it requires me to manually change all shortcuts I make and it also makes the icon look like a cmd prompt icon rather than a batch file.
Have you already considered to not use shortcuts at all?
You could e.g. create a batchfile_exec.bat containing your call
REM optionally do
REM cd /D working_directory
REM if you want to force a special working directory
D:\Temp\Utilities\batchfile.bat
and replace all the shortcuts with batchfile_exec.bat. If you double-click batchfile_exec.bat, the working directory will be the one containing batchfile_exec.bat.
I personally don't like Windows shortcuts that much, because they are hard to handle within a revision control system. As you also noticed, it is very time consuming if you want to modify a lot of them.
By the way: If batchfile.bat was designed/written to be always run from the direcory where it is located, you might also consider to modify batchfile.bat to force that behaviour:
setlocal
cd /D %0\..
REM your original content
endlocal
In %0 the path to the batchfile is stored.
The trick is to assume that %0 is a directory and then to change one level lower based on that directory. With /D also the drive letter is changed correctly.
The cd command doesn't care if %0 is really a directory. In fact %d doesn't even have to exist (%0\dummy\..\.. would also work).
The setlocal command is to have the working directory being restored when batchfile.bat has finished (this would be good if batchfile.bat was called form another batch file).
I noticed that the endlocal command is not really necessary in this context since it is applied implicitly when batchfile.bat finishes.