I tried to modify the open default command for .bat and .cmd files on Windows in order to open the Windows terminal instead of the legacy cmd.exe.
My modification to the user registry was:
(I had to use TotalReg from Pavel Yosifovitch to change the default value to REG_EXPAND_SZ).
The same default value was used for the batfile class.
The above definitions work almost properly.
There is a little issue though: when I now run a .bat or a .cmd file, the command line for wt.exe uses “legacy DOS 8.3 paths”, as well as the current working directory.
If my definition for the open command simply uses wt.exe instead of "%localappdata%\Microsoft\WindowsApps\wt.exe", then the problem disappears.
Is there a way to use the absolute path and still get the non-8.3 behavior?
When using %1, the shell tries to guess if the target supports long filenames. If you use %L, the shell always uses the long filename if the target is 32 or 64-bit. 16-bit applications presumably still get the short name?
%L is not officially documented anywhere but a Microsoft employee listed them in a comment here...
Related
Where are the commands located for Command Prompt? I know this is possible in Linux, but what about windows?
I want to rename certain commands so I can make my own using the original name.
Im doing this on a 32bit Windows XP if that helps.
More specifically, where can I find the tree command?
https://superuser.com/questions/312926/windows-equivalent-of-which-command-in-linux
in windows 7 there's the where command.
You can overwrite the standard commands, but this will break a lot of stuff.
You would also have to modify your path environment variable
in windows 7 tree is located in C:\Windows\System32\tree.com
This might be a useful site for you
http://ss64.com/nt/
Use a bat file of the same name to override an inbuilt external command. Some commands are internal so you have to specify .bat. Also if calling the overridden program specify the extension.
There are two types of commands in Windows command prompt. The internal commands are built-in inside the command processor program, that is called cmd.exe. You may inspect such commands if you open cmd.exe file with an Hex editor, or even directly with Notepad (although doing that requires a lot of patience!); to know the location of cmd.exe file, type: set comspec. Examples of internal commands are DIR, COPY, TYPE, MD, etc. (the simplest ones) and all Batch-file commands, like GOTO, IF, FOR, REM, etc. There is no way to change the name of an internal command, unless you modify the cmd.exe file (for example, using the same Hex editor) that, although possible, is NEVER recommended!!!
The external commands reside in disk files with .com or .exe extension that are grouped in certain subdirectories, usually in C:\Windows\System or C:\Windows\System32; these subdirectories must appear in %PATH% variable in order to execute the external commands directly in the command prompt. You may locate the folder where an executable file resides using the following command, that review folders included in PATH variable only (you can not use wild-cards in this case):
for %a in (tree.com tree.exe) do #echo/%~$PATH:a
You may directly change the name of any command-name.exe file; however, this practice is not recommended. A simpler option is create a Batch file with the same name of a standard command (and .bat extension) and place it in a folder that will be included in PATH variable before the standard commands folder (or in the current directory). For example, create a file named tree.bat and place it in C:\Users\MyName\MyCommands; then, modify PATH variable this way: path=C:\Users\MyName\MyCommands;C:\Windows;C:\Windows\System32. If you need to use the standard tree command inside your tree.bat file, just include the proper extension: tree.com.
I'm trying to create a .cfg file for bcc32 compiler and I'm following the instructions. I have installed correctly and placed an environment path as instructed but when I type "edit bcc32.cfg" into the command prompt it says that edit isn't a valid command? What am I supposed to do?
You could also create a .bat file, edit.bat, to replace the 16-bit edit program (removed because x64 windows flavors won't run it) which would launch your favorite editor.
#echo off
notepad %1
#echo on
This is what I wound up doing as a simple patch so I could carry on the way I always had for the most part. Just type:
edit myfile.ext
in the command prompt to use it.
Note: notepad is not my favorite editor - this is just an example that will work with stock windows.
Note 2: #echo off and #echo on are shown for clarity. You may also shorten this by omitting the echo statements and simply placing the # before the command to be silenced.
#notepad %1
I just use notepad (since they took out the edit command) from the command window like so:
C:\Borland\BCC55\bin> notepad bcc32.cfg
The file will open in notepad for editing. When you've finished editing the file, save it and you're done.
I have found this works for seeing in-window text of a complete file, on a 64bit machine. Once your path is set in cmd prompt, type the word type... followed by "filename" do you see how I used the quotes around the filename only!
type "filename"
You type it just like this (changing filename for your files name) and you will be able to see the entire file text in the cmd window. Not sure how to edit from here on but maybe someone can figure it out from here and tell me.
Assuming you're using Windows 7 (where edit.exe and edlin.exe have been removed):
Use powershell.exe instead of cmd - thereby edit will be available via command line.
Take a look at: http://en.wikipedia.org/wiki/Windows_PowerShell
simple answer....
if your using an old version of windows (xp e.t.c...) you would be able to use edit
but since your using new version of windows, Microsoft has updated and removed the commands that they think are not relevant e.g.. (msg, edit) depending if its a bit32 bit64 or bit82...
Operating system: Windows XP SP3
Trying to define commands to open some file-types from context menu or directly from explorer and having the following problem:
standard "C:\Program Files\SQLite ODBC Driver\sqlite3.exe" "%1" isn't working if file is in directory that contains cyrillic (non-ASCII) characters;
command "C:\Program Files\SQLite ODBC Driver\sqlite3.exe" "%~s0" isn't working because specified argument template unfortunately is only for batch files;
variant with creating batch file with previous command is ugly and unneficient.
Is there a right or convenient way to open files with non-ASCII characters in path?
Without ugly magic I mean.
UPDATE:
I think that "C:\Dir one\0016~1\file.sqlite" format would work.
%L key isn't working too.
Found the solution. Still ugly but it mades the deal.
...used a command like:
short.cmd "myapp.exe" "%1"
where short.cmd contains the line
start %~s1 %~s2
This then converts the app name and the filename to short versions, and
executes as desired - but there is a command window that pops up briefly in
there (running the START command)
Link: Context menu shell commands %1, %L parameters
I want to set an alias to my installation of firefox so I can easily start a web page, the problem is that I dont want the script to be system dependent.
Namely I want it to be able to run on a linux distribution where the command to start firefox is already mapped to 'firefox' and can easily be run that way through bash, but on my windows machine I cant seem to get it to assign to the same variable.
I saw that I could set it to '%firefox%' via the set command but that's not quite what I want.
I believe creating aliases is possible on a windows environment because the version of svn that I use auto-installed and was able to assign itself to 'svn'. Anyone know what was involved in them being able to get their alias working, or a similar way to alias a command?
If you include your Firefox path in the %PATH% environment variable, you can start FF with "firefox". Under Windows, you should edit the system-wide settings (see this link).
AFAIK, there is nothing similar to aliases under DOS/Windows (except the %firefox% way you mentioned, too). The 'svn' command you talked about most likely is the same thing, a 'svn.exe' and its path included to %PATH%.
This is a bit restrictive, as you can only use the original filename to launch a program, but you can work around this by creating a batch file in the program's path that launches the program, f.e. a FF.BAT that contains "firefox %1".
Alternatively, you can place a batch file in a path that already is in %PATH%, f.e. the Windows directory. That way, you don't have to modify %PATH%.
As I understand it, .bat is the old 16-bit naming convention, and .cmd is for 32-bit Windows, i.e., starting with NT. But I continue to see .bat files everywhere, and they seem to work exactly the same using either suffix. Assuming that my code will never need to run on anything older than NT, does it really matter which way I name my batch files, or is there some gotcha awaiting me by using the wrong suffix?
From this news group posting by Mark Zbikowski himself:
The differences between .CMD and .BAT as far as CMD.EXE is concerned
are: With extensions enabled, PATH/APPEND/PROMPT/SET/ASSOC in .CMD
files will set ERRORLEVEL regardless of error. .BAT sets ERRORLEVEL
only on errors.
In other words, if ERRORLEVEL is set to non-0 and then you run one of those commands, the resulting ERRORLEVEL will be:
left alone at its non-0 value in a .bat file
reset to 0 in a .cmd file.
Here is a compilation of verified information from the various answers and cited references in this thread:
command.com is the 16-bit command processor introduced in MS-DOS and was also used in the Win9x series of operating systems.
cmd.exe is the 32-bit command processor in Windows NT (64-bit Windows OSes also have a 64-bit version). cmd.exe was never part of Windows 9x. It originated in OS/2 version 1.0, and the OS/2 version of cmd began 16-bit (but was nonetheless a fully fledged protected mode program with commands like start). Windows NT inherited cmd from OS/2, but Windows NT's Win32 version started off 32-bit. Although OS/2 went 32-bit in 1992, its cmd remained a 16-bit OS/2 1.x program.
The ComSpec env variable defines which program is launched by .bat and .cmd scripts. (Starting with WinNT this defaults to cmd.exe.)
cmd.exe is backward compatible with command.com.
A script that is designed for cmd.exe can be named .cmd to prevent accidental execution on Windows 9x. This filename extension also dates back to OS/2 version 1.0 and 1987.
Here is a list of cmd.exe features that are not supported by command.com:
Long filenames (exceeding the 8.3 format)
Command history
Tab completion
Escape character: ^ (Use for: \ & | > < ^)
Directory stack: PUSHD/POPD
Integer arithmetic: SET /A i+=1
Search/Replace/Substring: SET %varname:expression%
Command substitution: FOR /F (existed before, has been enhanced)
Functions: CALL :label
Order of Execution:
If both .bat and .cmd versions of a script (test.bat, test.cmd) are in the same folder and you run the script without the extension (test), by default the .bat version of the script will run, even on 64-bit Windows 7. The order of execution is controlled by the PATHEXT environment variable. See Order in which Command Prompt executes files for more details.
References:
cmd.exe
command.com
wikipedia: Comparison of command shells
These answers are a bit too long and focused on interactive use. The important differences for scripting are:
.cmd prevents inadvertent execution on non-NT systems.
.cmd enables built-in commands to change Errorlevel to 0 on success.
Not that exciting, eh?
There used to be a number of additional features enabled in .cmd files, called Command Extensions. However, they are now enabled by default for both .bat and .cmd files under Windows 2000 and later.
Bottom line: in 2012 and beyond, I recommend using .cmd exclusively.
No - it doesn't matter in the slightest. On NT the .bat and .cmd extension both cause the cmd.exe processor to process the file in exactly the same way.
Additional interesting information about command.com vs. cmd.exe on WinNT-class systems from MS TechNet (http://technet.microsoft.com/en-us/library/cc723564.aspx):
This behavior reveals a quite subtle
feature of Windows NT that is very
important. The 16-bit MS-DOS shell
(COMMAND.COM) that ships with Windows
NT is specially designed for Windows
NT. When a command is entered for
execution by this shell, it does not
actually execute it. Instead, it
packages the command text and sends it
to a 32-bit CMD.EXE command shell for
execution. Because all commands are
actually executed by CMD.EXE (the
Windows NT command shell), the 16-bit
shell inherits all the features and
facilities of the full Windows NT
shell.
RE: Apparently when command.com is invoked is a bit of a complex mystery;
Several months ago, during the course of a project, we had to figure out why some programs that we wanted to run under CMD.EXE were, in fact, running under COMMAND.COM. The "program" in question was a very old .BAT file, that still runs daily.
We discovered that the reason the batch file ran under COMMAND.COM is that it was being started from a .PIF file (also ancient). Since the special memory configuration settings available only through a PIF have become irrelevant, we replaced it with a conventional desktop shortcut.
The same batch file, launched from the shortcut, runs in CMD.EXE. When you think about it, this makes sense. The reason that it took us so long to figure it out was partially due to the fact that we had forgotten that its item in the startup group was a PIF, because it had been in production since 1998.
Still, on Windows 7, BAT files have also this difference : If you ever create files TEST.BAT and TEST.CMD in the same directory, and you run TEST in that directory, it'll run the BAT file.
C:\>echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
C:\Temp>echo echo bat > test.bat
C:\Temp>echo echo cmd > test.cmd
C:\Temp>test
C:\Temp>echo bat
bat
C:\Temp>
Since the original post was regarding the consequences of using the .bat or .cmd suffix, not necessarily the commands inside the file...
One other difference between .bat and .cmd is that if two files exist with the same file name and both those extensions, then:
entering filename or filename.bat at the command line will run the .bat file
to run the .cmd file, you have to enter filename.cmd
everything working in a batch should work in a cmd; cmd provides some extensions for controlling the environment.
also, cmd is executed by in new cmd interpreter and thus should be faster (not noticeable on short files) and stabler as bat runs under the NTVDM emulated 16bit environment
.cmd and .bat file execution is different because in a .cmd errorlevel variable it can change on a command that is affected by command extensions. That's about it really.
I believe if you change the value of the ComSpec environment variable to %SystemRoot%system32\cmd.exe(CMD) then it doesn't matter if the file extension is .BAT or .CMD. I'm not sure, but this may even be the default for WinXP and above.
The extension makes no difference.
There are slight differences between COMMAND.COM handling the file vs CMD.EXE.
a difference:
.cmd files are loaded into memory before being executed. .bat files execute a line, read the next line, execute that line...
you can come across this when you execute a script file and then edit it before it's done executing. bat files will be messed up by this, but cmd files won't.