Troubleshooting CMD: Issue with Running .exe Files Using PATH

[yungman]

Hi

I am learning Command Line CMD. I cannot do what this video do in searching and running an executable file(.exe). This is the video:


If you start watching at about 2:30. It talked about how to make the CMD to run the .exe file not in the current directory by first run "PATH". My problem is my executable file Directory.exe is in a folder called Directory on Desktop. When I type path, there is no path to Desktop and I cannot run the Directory.exe. It will not find it. BUT if I actually go to the Directory, it will run as show in the screen shot below.

As you can see I followed the instruction in the video and it doesn't work. But if I change directory to the right place, I ran the program.

Please tell me what I did wrong.

Thanks

 

[Frabjous]

Path just lists the value of the environment variable path. You didn’t change anything.

 

[yungman]

Path just lists the value of the environment variable path. You didn’t change anything.

Can you explain, I have no idea what you mean. I just follow what the video said. I am not familiar with CMD at all, just started learning.

What is value of the environment variable path?

Thanks

 

[Frabjous]

When you type path it gives you the current value of the environment variable path. This is the first command you ran in your example.
The environment variable path is a list of directories to search in for an executable.
The video you posted shows how to add directories to your path (modify the environment variable path) through the gui (not cmd) at ~5:50.

 

[yungman]

When you type path it gives you the current value of the environment variable path. This is the first command you ran in your example.
The environment variable path is a list of directories to search in for an executable.
The video you posted shows how to add directories to your path (modify the environment variable path) through the gui (not cmd) at ~5:50.

You mean in order to make this work, I have to go and add the path first before this can work? That's not useful at all!!! I was stuck before 5:50. He just said I can do it in early part of the video. I notice he has the path showing and I don't have it on my computer. I did not know I have to create the path before that.

This is not useful then unless I have to run the file all the time.

Thanks

 

[jedishrfu]

There exists an environment variable called PATH that you can change. You need to add the path C:\\Users\yungman\Desktop to the PATH string in order for the command shell to find it. Windows actually separates the PATH into two parts, one for the system ie for all users and one for the currently logged on user.

There is a properties dialog that allows you to edit the path in a permanent way:

https://www.maketecheasier.com/what-is-the-windows-path/

One thing to note: the path order dictates the exe/dll search order so basically two exe/dll files of the same name and both in separate directories that are in the path string are ambiquous and the command shell will choose one or the other and this is not always obvious.

Bottom line is make sure the exe filename is unique along all exes on the path string. Make sure you haven't superceded a system DLL file either.

Another thing to note on some windows OS platforms the system path had a hard limit of 256 chars whereas the user path could go upto to 4096. I'm sure they must have fixed this undocumented limit by now but I'm throwing this out there for posterity.

DLL libraries were found using the path as well so avoid name clashes.

---

As an aside, some years ago like 20+ I was working on an InstallShield script for our product on WIndows NT. We would routinely add stuff to the system PATH variable for all users of the product on a machine. Initially it was just three directories for EXE files, DLL files and some other executable related stuff.

However as our product had product commands, runnable example/demo code and user developed code we needed to add 9 directories and as luck would have it, when added to the system PATH could and did exceed the 256 character limit.

It wouldn't have been a major problem if we had added the directories to the end of the PATH but instead we added to the beginning as we wanted our stuff to run first in case there was a name conflict of a local EXE with the same name as our demo code.

Upon rebooting the machine, we discovered to our chagrin that the 256 limit meant we had pushed the system level DLL libraries the 256 character limit of the system PATH string meaning the system failed to find the system DLLs and the system failed to boot.

Fortunately for me, my coworker roommate had asked for a snapshot of my environment the week before because of issues he was having with his machine and this proved to save the day. I didn't have to reinstall my whole OS and other developer software to fix it.

 

[yungman]

When you type path it gives you the current value of the environment variable path. This is the first command you ran in your example.
The environment variable path is a list of directories to search in for an executable.
The video you posted shows how to add directories to your path (modify the environment variable path) through the gui (not cmd) at ~5:50.

Hi, I follow the instruction of 5:50 and created the new path to Directory folder where the Directory.exe in. You can see in the CMD that I have the path this time. BUT it still didn't work as shown.

I verify and manually type cd Desktop, then cd Directory. Then I type in Directory.exe. It works as shown.

I don't know what I did wrong. I follow all the steps to add the path. You can see it shows at the last line when I type "path" above.

What else goes wrong this time?

Thanks

 

[Mark44]

Please tell me what I did wrong.

In your screen shot, the current directory is apparently C:\Users\yungm and the prompt is C:\Users\yungm> When you added Directory to the command window prompt, it didn't recognize this command. The reason is that there is no such command. There is one called dir, which is short for directory.
Here's a link to a website that lists the Windows CMD window commands -- https://www.lifewire.com/list-of-command-prompt-commands-4092302#Command Prompt Commands List

If your goal is to learn about Windows command prompt window commands, you need to have some documentation on the handy.

 

[yungman]

In your screen shot, the current directory is apparently C:\Users\yungm and the prompt is C:\Users\yungm> When you added Directory to the command window prompt, it didn't recognize this command. The reason is that there is no such command. There is one called dir, which is short for directory.
Here's a link to a website that lists the Windows CMD window commands -- https://www.lifewire.com/list-of-command-prompt-commands-4092302#Command Prompt Commands List

If your goal is to learn about Windows command prompt window commands, you need to have some documentation on the handy.

WOW, there's so many commands!!

I already learn and move on from the post you quoted, Now my problem is described in post #7.

Thanks

 

[Tom.G]

There was (is?) an IBM publication titled:
Disk Operating System Version 3.30 (1987)
Technical Reference

The publication # is 80X0945

It explains each available command in COMMAND.COM (CMD).
You can probably find a copy with a Google search for 80X0945.

If you Google search for: 80X0945 pdf
there are many downloadable PDF files of that publication.

For later versions, see if you can find:
MS-DOS 6 Quick Reference (1993)
ISBN 1-56529-137-9 or ISBN 1-56529-279-0
(publisher: QUE Corporation)

Up & Running with DOS 6.2 (2nd edition, 1993)
ISBN 0-7821-1443-1
(publisher: SYBEX Inc.)

Have Fun,
Tom

 

[FactChecker]

You didn't add the correct thing to PATH. You forgot the "yungm"

 

[yungman]

You didn't add the correct thing to PATH. You forgot the "yungm"

Yes, I went back and check, I forgot "yungm". It's working now.

Thanks

 

[yungman]

The video is a 9 part series, I finished 8 already. So far I see everything can be done in Windows GUI, what is the big advantage using CMD? I read a lot that people into IT that dig deep into operating system, virus removal etc prefer to use CMD, why?

I don't know CMD, just wonder what is the hype? Is this just a teaser to bigger and better things? If so, what is the next step for me to study?

Thanks

 

[jedishrfu]

With the command shell and some clever programming you can construct any software script to do whatever task you want.

As an example, I wrote a script recently to move files in a directory into a time-like directory tree because I was having trouble locating some information in my email files so I created a time-based directory tree:

./my-email/year-2020/01-january/23-thursday -- for files created on monday 01/23/2020
./my-email/year-2021/02-february/10-wednesday -- for files created on wednesday 02/10/2021

I could then find all files created in a given year or in a given month by name... Notice I used nn-monthname so that they would sort in month order in a GUI display of the directories. Similary nn-dayname for sorting in day order but with a name for searching by day of the week.

Take a look at shell scripts to see what folks can do.

Memory-wise one can remember the commands better and access them faster by typing than can be done by gui stuff. GUIs were designed more for casual users unfamiliar with the command line and its commands.

As an example, deleting selected files can be done easily in a GUI where you first select the ones and then press the delete key to remove them. In contrast, unless they have a pattern like all temp files *.tmp or all files that begin with abc in a directory ala abc*.* then you'd need to manually type their names in an rm command

rm abc*.*    vs rm abc.c def.apl efg.julia ...

 

[jedishrfu]

As another example, I worked in a place where we didn't have easy access to a java IDE along with other restrictions. I developed a script to act as a frontend to vim.

Basically I could stay at the top directory on my project and enter a partial filename to my script xvim and it would present a list of files matching my partial name and then I could select the file of interest.

This avoided the common practice of using cd to navigate the directory tree to edit a specific file. Later I added a grep-like feature to present only those files matching my partial name, excluding other partial names and containing the following text. Basically a combo of find+grep+vim+diff

xvim java -test -f com.xyz.framewk      ## show all java files without test in the name using the com.xyz.framwk

1: ./filepath/one/FileOne.java...
2: ./filepath/two/FileTwo.java...
3: ./filepath/three/FileThree.java...

Enter a number or q to quit? 2

In addition, the script would make a backup of the java file and save it in the same directory and upon completion of my edits if any would do an exit file compare and delete the backup if nothing had changed. Changed files would show in the list in a different color (ie if a backup file was present too)

The xvim script would:

cp ./filepath/two/FileTwo.java ./filepath/two/FileTwo.java.old
vim ./filepath/two/FileTwo.java
diff ./filepath/two/FileTwo.java ./filepath/two/FileTwo.java.old
# code that checks if files are the same then remove ./filepath/two/FileTwo.java.old

Later, when my work was completed, I could ask the script to show me all source files that changed and show me the changes made in each file. From there, I could copy down the changes, return to my desk and add them in our official source tree.

I wrote it in a combination of awk script embedded in a bash script and later as a python script using ANSI codes to clear the screen, control text placement on the screen and colorize certain text.

 

[FactChecker]

I wrote it in a combination of awk script embedded in a bash script and later as a python script using ANSI codes to clear the screen, control text placement on the screen and colorize certain text.

This was typical of the days when a series of awk and sed steps could be strung together in a bash script to get complicated and tedious jobs done. I did a lot of conversions from FORTRAN and C to Ada that way. The development of Perl was a tremendous advance. Python is the current favorite language for scripts. (I still think that Perl was better for that type of scripting.)

 

[yungman]

With the command shell and some clever programming you can construct any software script to do whatever task you want.

As an example, I wrote a script recently to move files in a directory into a time-like directory tree because I was having trouble locating some information in my email files so I created a time-based directory tree:

./my-email/year-2020/01-january/23-thursday -- for files created on monday 01/23/2020
./my-email/year-2021/02-february/10-wednesday -- for files created on wednesday 02/10/2021

I could then find all files created in a given year or in a given month by name... Notice I used nn-monthname so that they would sort in month order in a GUI display of the directories. Similary nn-dayname for sorting in day order but with a name for searching by day of the week.

Take a look at shell scripts to see what folks can do.

Memory-wise one can remember the commands better and access them faster by typing than can be done by gui stuff. GUIs were designed more for casual users unfamiliar with the command line and its commands.

As an example, deleting selected files can be done easily in a GUI where you first select the ones and then press the delete key to remove them. In contrast, unless they have a pattern like all temp files *.tmp or all files that begin with abc in a directory ala abc*.* then you'd need to manually type their names in an rm command

rm abc*.*    vs rm abc.c def.apl efg.julia ...

This is way over my head. I just learned the very basic commands.

Question is why you do it in CMD, you can easily do the same thing in Windows GUI. It's a lot easier to play with files in Windows.

So far I can see is very often when the computer fails, it won't boot up to windows and just open the CMD window. I guess one has no choice but to check things in CMD to see what drive is dead and all that.

Thanks

 

[Mark44]

Question is why you do it in CMD, you can easily do the same thing in Windows GUI. It's a lot easier to play with files in Windows.

Not necessarily. For example, if you wanted to delete all PDF files in a specific directory, you could CD (change directory) to the directory in question, and then issue this prompt: del *.pdf. You wouldn't even have to navigate to that directory if you supplied the directory path. Granted, you could use File Explorer sort all the files by file type so that the PDFs would be in one clump, then highlight those files and hit the delete key. Also, there are a lot of things you can do with wild cards in CMD that would be harder to do in Windows File Explorer. It's also possible to create batch files that are essentially small programs that can perform various operations on files.

Since you're so new to using the command prompt (i.e., CMD window), you're not really in a good position to judge the relative merits of either approach.

 

[FactChecker]

Question is why you do it in CMD, you can easily do the same thing in Windows GUI. It's a lot easier to play with files in Windows.

About half of my career (and maybe all of my job security) was due to my ability to write scripts for processing massive amounts of files down through directories. I had script programs that would run for days and had to be monitored through weekends and holidays. Those programs solved some nightmares that people were having when they imagined doing them by hand in the Windows GUIs. And what would somebody do if he had to spend weeks at a GUI and could never make the mistake of clicking the wrong button?
In some cases, I am talking about maybe close to a million files.

 

[FactChecker]

Question is why you do it in CMD, you can easily do the same thing in Windows GUI. It's a lot easier to play with files in Windows.

Another reason to use CMD is this:
How many times have you gotten instructions from YouTube, Google, Microsoft help website, etc. on how to do a simple GUI process and found that you did not have the same options to click as the instructions said? I have that problem with at least half of my questions, even very simple ones. Now suppose you wanted to record an exact process so it could be repeated without fail. You can write commands for that.
IMHO, a script of commands is a far more reliable and repeatable way of recording a series of computer steps.