Does the Windows Command Prompt search somewhere other than those locations specified by the PATH variable when launching application programs?

Clash Royale CLAN TAG#URR8PPP

up vote
31
down vote

favorite

11

I tried the following experiment.

Before I start, I checked the PATH variable from cmd, which has the following value:

Path=C:Program Files (x86)InteliCLS Client;C:Program FilesInteliCLS Client;%SystemRoot%system32;%SystemRoot%;%SystemRoot%System32Wbem;%SYSTEMROOT%System32WindowsPowerShellv1.0;C:ProgramDataLenovoReadyApps;C:Program FilesMicrosoft SQL Server110ToolsBinn;C:Program FilesMicrosoft SQL Server120ToolsBinn;C:Program Files (x86)Windows LiveShared;C:Program Files (x86)SkypePhone;C:Program Files (x86)IntelIntel(R) Management Engine ComponentsDAL;C:Program FilesIntelIntel(R) Management Engine ComponentsDAL;C:Program Files (x86)IntelIntel(R) Management Engine ComponentsIPT;C:Program FilesIntelIntel(R) Management Engine ComponentsIPT;C:Program Files (x86)Calibre2;C:Program FilesIntelWiFibin;C:Program FilesCommon FilesIntelWirelessCommon;

At first, I thought that cmd only looks for executables in the directories contained in the PATH variable, so I randomly picked an application - winword.exe (Microsoft Word), and tried to launch it from the command line:

start winword

But to my surprise, the program launches! The reason I'm surprised is because I've searched through all the directories in the PATH variable for the exe file called 'winword' but all my searches came up empty!

I've therefore concluded that the command prompt must have known to search in places other than those specified in the PATH variable to look for executables.

So obviously, the next thing I did was to look for the precise location where the 'winword' executable file is located. It turns out that winword.exe is located here:

C:Program FilesMicrosoft Office 15rootoffice15

Hence giving me the idea that maybe CMD automatically looks through ProgramFiles and ProgramFiles(x86) (and all their subdirectories) when executing the 'start' command? Which led to me trying to launch another application installed on my computer, Audacity, with the exe file located at:

C:Program Files (x86)Audacity

Again, to my surprise, Audacity failed to launch when I typed:

start audacity

at the command line.

I've then added the directory containing audacity.exe to PATH:

set path=%path%;C:Program Files (x86)Audacity

after which i tried launching audacity again:

start audacity

Well, not surprisingly, Audacity launched.

What I want to know is where exactly does the command prompt look for executables? Why is it that winword.exe launches even when the directory containing it not part of PATH, but the same thing isn't true for audacity.exe?

I tried other applications too. Chrome and Firefox works when I use the start command.

UPDATE: I am running Windows version 6.3.9600 (Windows 8.1)

windows command-line environment-variables path

share|improve this question

edited Aug 23 at 5:38

asked Aug 23 at 5:18

Anthony

27426

• 
  
  
  

  
  

  
  
  
  
  
  

  
  The core of in my answer to Kyle Delaney's question from about a year and a half ago addresses this question too.
  – TOOGAM
  Aug 25 at 6:42
  

  
  
  
  

add a comment | 

up vote
31
down vote

favorite

11

I tried the following experiment.

Before I start, I checked the PATH variable from cmd, which has the following value:

Path=C:Program Files (x86)InteliCLS Client;C:Program FilesInteliCLS Client;%SystemRoot%system32;%SystemRoot%;%SystemRoot%System32Wbem;%SYSTEMROOT%System32WindowsPowerShellv1.0;C:ProgramDataLenovoReadyApps;C:Program FilesMicrosoft SQL Server110ToolsBinn;C:Program FilesMicrosoft SQL Server120ToolsBinn;C:Program Files (x86)Windows LiveShared;C:Program Files (x86)SkypePhone;C:Program Files (x86)IntelIntel(R) Management Engine ComponentsDAL;C:Program FilesIntelIntel(R) Management Engine ComponentsDAL;C:Program Files (x86)IntelIntel(R) Management Engine ComponentsIPT;C:Program FilesIntelIntel(R) Management Engine ComponentsIPT;C:Program Files (x86)Calibre2;C:Program FilesIntelWiFibin;C:Program FilesCommon FilesIntelWirelessCommon;

At first, I thought that cmd only looks for executables in the directories contained in the PATH variable, so I randomly picked an application - winword.exe (Microsoft Word), and tried to launch it from the command line:

start winword

But to my surprise, the program launches! The reason I'm surprised is because I've searched through all the directories in the PATH variable for the exe file called 'winword' but all my searches came up empty!

I've therefore concluded that the command prompt must have known to search in places other than those specified in the PATH variable to look for executables.

So obviously, the next thing I did was to look for the precise location where the 'winword' executable file is located. It turns out that winword.exe is located here:

C:Program FilesMicrosoft Office 15rootoffice15

Hence giving me the idea that maybe CMD automatically looks through ProgramFiles and ProgramFiles(x86) (and all their subdirectories) when executing the 'start' command? Which led to me trying to launch another application installed on my computer, Audacity, with the exe file located at:

C:Program Files (x86)Audacity

Again, to my surprise, Audacity failed to launch when I typed:

start audacity

at the command line.

I've then added the directory containing audacity.exe to PATH:

set path=%path%;C:Program Files (x86)Audacity

after which i tried launching audacity again:

start audacity

Well, not surprisingly, Audacity launched.

What I want to know is where exactly does the command prompt look for executables? Why is it that winword.exe launches even when the directory containing it not part of PATH, but the same thing isn't true for audacity.exe?

I tried other applications too. Chrome and Firefox works when I use the start command.

UPDATE: I am running Windows version 6.3.9600 (Windows 8.1)

windows command-line environment-variables path

share|improve this question

edited Aug 23 at 5:38

asked Aug 23 at 5:18

Anthony

27426

• 
  
  
  

  
  

  
  
  
  
  
  

  
  The core of in my answer to Kyle Delaney's question from about a year and a half ago addresses this question too.
  – TOOGAM
  Aug 25 at 6:42
  

  
  
  
  

add a comment | 

up vote
31
down vote

favorite

11

up vote
31
down vote

favorite

11

11

I tried the following experiment.

Before I start, I checked the PATH variable from cmd, which has the following value:

Path=C:Program Files (x86)InteliCLS Client;C:Program FilesInteliCLS Client;%SystemRoot%system32;%SystemRoot%;%SystemRoot%System32Wbem;%SYSTEMROOT%System32WindowsPowerShellv1.0;C:ProgramDataLenovoReadyApps;C:Program FilesMicrosoft SQL Server110ToolsBinn;C:Program FilesMicrosoft SQL Server120ToolsBinn;C:Program Files (x86)Windows LiveShared;C:Program Files (x86)SkypePhone;C:Program Files (x86)IntelIntel(R) Management Engine ComponentsDAL;C:Program FilesIntelIntel(R) Management Engine ComponentsDAL;C:Program Files (x86)IntelIntel(R) Management Engine ComponentsIPT;C:Program FilesIntelIntel(R) Management Engine ComponentsIPT;C:Program Files (x86)Calibre2;C:Program FilesIntelWiFibin;C:Program FilesCommon FilesIntelWirelessCommon;

At first, I thought that cmd only looks for executables in the directories contained in the PATH variable, so I randomly picked an application - winword.exe (Microsoft Word), and tried to launch it from the command line:

start winword

But to my surprise, the program launches! The reason I'm surprised is because I've searched through all the directories in the PATH variable for the exe file called 'winword' but all my searches came up empty!

I've therefore concluded that the command prompt must have known to search in places other than those specified in the PATH variable to look for executables.

So obviously, the next thing I did was to look for the precise location where the 'winword' executable file is located. It turns out that winword.exe is located here:

C:Program FilesMicrosoft Office 15rootoffice15

Hence giving me the idea that maybe CMD automatically looks through ProgramFiles and ProgramFiles(x86) (and all their subdirectories) when executing the 'start' command? Which led to me trying to launch another application installed on my computer, Audacity, with the exe file located at:

C:Program Files (x86)Audacity

Again, to my surprise, Audacity failed to launch when I typed:

start audacity

at the command line.

I've then added the directory containing audacity.exe to PATH:

set path=%path%;C:Program Files (x86)Audacity

after which i tried launching audacity again:

start audacity

Well, not surprisingly, Audacity launched.

What I want to know is where exactly does the command prompt look for executables? Why is it that winword.exe launches even when the directory containing it not part of PATH, but the same thing isn't true for audacity.exe?

I tried other applications too. Chrome and Firefox works when I use the start command.

UPDATE: I am running Windows version 6.3.9600 (Windows 8.1)

windows command-line environment-variables path

share|improve this question

edited Aug 23 at 5:38

asked Aug 23 at 5:18

Anthony

27426

I tried the following experiment.

Before I start, I checked the PATH variable from cmd, which has the following value:

Path=C:Program Files (x86)InteliCLS Client;C:Program FilesInteliCLS Client;%SystemRoot%system32;%SystemRoot%;%SystemRoot%System32Wbem;%SYSTEMROOT%System32WindowsPowerShellv1.0;C:ProgramDataLenovoReadyApps;C:Program FilesMicrosoft SQL Server110ToolsBinn;C:Program FilesMicrosoft SQL Server120ToolsBinn;C:Program Files (x86)Windows LiveShared;C:Program Files (x86)SkypePhone;C:Program Files (x86)IntelIntel(R) Management Engine ComponentsDAL;C:Program FilesIntelIntel(R) Management Engine ComponentsDAL;C:Program Files (x86)IntelIntel(R) Management Engine ComponentsIPT;C:Program FilesIntelIntel(R) Management Engine ComponentsIPT;C:Program Files (x86)Calibre2;C:Program FilesIntelWiFibin;C:Program FilesCommon FilesIntelWirelessCommon;

At first, I thought that cmd only looks for executables in the directories contained in the PATH variable, so I randomly picked an application - winword.exe (Microsoft Word), and tried to launch it from the command line:

start winword

But to my surprise, the program launches! The reason I'm surprised is because I've searched through all the directories in the PATH variable for the exe file called 'winword' but all my searches came up empty!

I've therefore concluded that the command prompt must have known to search in places other than those specified in the PATH variable to look for executables.

So obviously, the next thing I did was to look for the precise location where the 'winword' executable file is located. It turns out that winword.exe is located here:

C:Program FilesMicrosoft Office 15rootoffice15

Hence giving me the idea that maybe CMD automatically looks through ProgramFiles and ProgramFiles(x86) (and all their subdirectories) when executing the 'start' command? Which led to me trying to launch another application installed on my computer, Audacity, with the exe file located at:

C:Program Files (x86)Audacity

Again, to my surprise, Audacity failed to launch when I typed:

start audacity

at the command line.

I've then added the directory containing audacity.exe to PATH:

set path=%path%;C:Program Files (x86)Audacity

after which i tried launching audacity again:

start audacity

Well, not surprisingly, Audacity launched.

What I want to know is where exactly does the command prompt look for executables? Why is it that winword.exe launches even when the directory containing it not part of PATH, but the same thing isn't true for audacity.exe?

I tried other applications too. Chrome and Firefox works when I use the start command.

UPDATE: I am running Windows version 6.3.9600 (Windows 8.1)

windows command-line environment-variables path

share|improve this question

edited Aug 23 at 5:38

asked Aug 23 at 5:18

Anthony

27426

share|improve this question

share|improve this question

edited Aug 23 at 5:38

edited Aug 23 at 5:38

edited Aug 23 at 5:38

asked Aug 23 at 5:18

Anthony

27426

asked Aug 23 at 5:18

Anthony

27426

asked Aug 23 at 5:18

Anthony

27426

27426

• 
  
  
  

  
  

  
  
  
  
  
  

  
  The core of in my answer to Kyle Delaney's question from about a year and a half ago addresses this question too.
  – TOOGAM
  Aug 25 at 6:42
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  The core of in my answer to Kyle Delaney's question from about a year and a half ago addresses this question too.
  – TOOGAM
  Aug 25 at 6:42
  

  
  
  
  

The core of in my answer to Kyle Delaney's question from about a year and a half ago addresses this question too.
– TOOGAM
Aug 25 at 6:42

The core of in my answer to Kyle Delaney's question from about a year and a half ago addresses this question too.
– TOOGAM
Aug 25 at 6:42

add a comment | 

5 Answers
5

active

oldest

votes

up vote
43
down vote

At first, I thought that cmd only looks for executables in the directories contained in the PATH variable, so I randomly picked an application - winword.exe (Microsoft Word) and tried to launch it from the command line:

The reason winword.exe worked is that a registry key exists which defined the path to Microsoft Word (Winword.exe). A similar key exists for Firefox.exe and Chrome.exe if those applications are installed.

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths
HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionApp Paths

What I want to know is where exactly does the command prompt look for executables?

System PATH Variable, User PATH Variable, and the various keys within ..App Paths. I was able to confirm that Audacity does not create a key for itself when it's installed.

When the ShellExecuteEx function is called with the name of an
executable file in its lpFile parameter, there are several places
where the function looks for the file. We recommend registering your
application in the App Paths registry subkey. Doing so avoids the need
for applications to modify the system PATH environment variable.

• The current working directory.


• The Windows directory only (no subdirectories are searched).


• The WindowsSystem32 directory.


• Directories listed in the PATH environment variable.


• Recommended: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

Source: Application Registration

share|improve this answer

answered Aug 23 at 6:33

Ramhound

17.4k145574

add a comment | 

up vote
14
down vote

From the command prompt, if you just enter WinWord it fails to run.

If you enter START WinWord it runs.

The Start command is key here.

When you try to execute a file through the start command, Command Prompt does not perform any searching. Instead, it passes the file name (and arguments) over to Windows itself (via the ShellExecuteEx API call), which must then search for the file's location. There are several places it searches in the following order:

• The current working directory.




• The Windows directory only (no subdirectories are searched).




• The WindowsSystem32 directory.




• Directories listed in the PATH environment variable.




• Recommended:
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

WinWord is in that registry key. The key is there to keep PATH from getting too long.

share|improve this answer

edited Aug 23 at 16:11

MrWhite

1,57631937

answered Aug 23 at 6:26

Larryc

38216

• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  Please cite and quote all sources. Unless you wrote the search order from memory, you should have cited your source, which indicated the list and the order which it's searched.
  – Ramhound
  Aug 23 at 6:51
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  The source would be my notes from something I was working on a couple years ago. I don't know where I picked it up back then, web pages come and go.
  – Larryc
  Aug 23 at 20:14
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  You got them from the same documentation everyone else got them from.
  – Ramhound
  Aug 23 at 21:03
  

  
  
  
  

add a comment | 

up vote
6
down vote

The program (when you specify its module name without drive/path in command prompt) in Windows command processor (CMD.EXE) can be started when found:

• by PATH environment variable (both executable and its hardlink/softlink/shortcut with the same name)




• by DOSKEY alias




• by application path from HKLMSoftwareMicrosoftWindowsCurrentVersionApp Paths or HKCUSoftwareMicrosoftWindowsCurrentVersionApp Paths (when using start command)

Using this knowledge (especially the last one) you can create your own aliases convenient for you. For example you can create HKCUSoftwareMicrosoftWindowsCurrentVersionApp Pathsau.exe with default value of C:Program Files (x86)AudacityAudacity.exe and start this application simply by typing start au in command prompt.

share|improve this answer

edited Aug 23 at 6:09

answered Aug 23 at 6:00

Akina

1,0217

add a comment | 

up vote
0
down vote

While the other answers are likely to be the specific reason in your case, there is also another answer to your question which could have been the case for some other applications: in the same place you were looking, but with different file extensions.

You specifically said that you were searching for files with extension exe. Windows will also attempt to execute files of other extensions.

Another environment variable that comes into play when executing a command is the variable PATHEXT. This is a ;-delimited list of file extensions to attempt to execute. If you echo PATHEXT you might see something like .COM;.EXE;.BAT;.CMD;.VBS;... (etc.). Some applications use these other file types as their end-user entry point. It is much less common, but it happens. I have used several major commercial products which start from .BAT scripts. To use one of them as an example, I can start it with the command standalone even though there is no standalone.exe... instead, it has a standalone.bat.

Some of the extensions I have on the PATHEXT I'm looking at right now I have never had an application use. Ones that I have run into much more commonly (but obviously not as much as exe) are: .com, .bat, .vbs, .js, .jar. The first two are windows batch script files, and the other three are file types for specific programming languages which are run from scripts or virtual machines instead of from exes (respectively: visual basic, javascript, and java).

share|improve this answer

answered Aug 24 at 0:13

Aaron

1264

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Down-voter care to comment (I know it's usually futile to ask, but sometimes I get a response)? Did I make a mistake somewhere?
  – Aaron
  Aug 24 at 16:42
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Not me, but at a wild guess it's because while PATHEXT and PATH, are both related to getting things running, they are somewhat orthogonal in their respective tasks. PATH specifies where to look for things to run, and is what the OP was asking, while PATHEXT specifies what can be run.
  – dgnuff
  Aug 24 at 19:14
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @dgnuff Interesting, since that was my point: OP specifically worded the question in a way that begged for a frame challenge... in SE terms, they were asking an "XY question" by making an assumption that the file being run was not in the places that were already being searched on the path. Anyway, thanks.
  – Aaron
  Aug 27 at 14:37
  

  
  
  
  

add a comment | 

up vote
0
down vote

start winword does not tell the command prompt to launch winword. It tells the command prompt to launch start with argument winword. Start uses its own methods to find winword.

Just winword tells the command prompt to launch winword. And if you try that, since winword is not on the PATH, it doesn't launch.

share|improve this answer

answered Aug 26 at 15:43

Eric Towers

1514

add a comment | 

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "3"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1351532%2fdoes-the-windows-command-prompt-search-somewhere-other-than-those-locations-spec%23new-answer', 'question_page');

);

Post as a guest

Name Email

5 Answers
5

active

oldest

votes

5 Answers
5

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
43
down vote

At first, I thought that cmd only looks for executables in the directories contained in the PATH variable, so I randomly picked an application - winword.exe (Microsoft Word) and tried to launch it from the command line:

The reason winword.exe worked is that a registry key exists which defined the path to Microsoft Word (Winword.exe). A similar key exists for Firefox.exe and Chrome.exe if those applications are installed.

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths
HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionApp Paths

What I want to know is where exactly does the command prompt look for executables?

System PATH Variable, User PATH Variable, and the various keys within ..App Paths. I was able to confirm that Audacity does not create a key for itself when it's installed.

When the ShellExecuteEx function is called with the name of an
executable file in its lpFile parameter, there are several places
where the function looks for the file. We recommend registering your
application in the App Paths registry subkey. Doing so avoids the need
for applications to modify the system PATH environment variable.

• The current working directory.


• The Windows directory only (no subdirectories are searched).


• The WindowsSystem32 directory.


• Directories listed in the PATH environment variable.


• Recommended: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

Source: Application Registration

share|improve this answer

answered Aug 23 at 6:33

Ramhound

17.4k145574

add a comment | 

up vote
43
down vote

At first, I thought that cmd only looks for executables in the directories contained in the PATH variable, so I randomly picked an application - winword.exe (Microsoft Word) and tried to launch it from the command line:

The reason winword.exe worked is that a registry key exists which defined the path to Microsoft Word (Winword.exe). A similar key exists for Firefox.exe and Chrome.exe if those applications are installed.

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths
HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionApp Paths

What I want to know is where exactly does the command prompt look for executables?

System PATH Variable, User PATH Variable, and the various keys within ..App Paths. I was able to confirm that Audacity does not create a key for itself when it's installed.

When the ShellExecuteEx function is called with the name of an
executable file in its lpFile parameter, there are several places
where the function looks for the file. We recommend registering your
application in the App Paths registry subkey. Doing so avoids the need
for applications to modify the system PATH environment variable.

• The current working directory.


• The Windows directory only (no subdirectories are searched).


• The WindowsSystem32 directory.


• Directories listed in the PATH environment variable.


• Recommended: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

Source: Application Registration

share|improve this answer

answered Aug 23 at 6:33

Ramhound

17.4k145574

add a comment | 

up vote
43
down vote

up vote
43
down vote

At first, I thought that cmd only looks for executables in the directories contained in the PATH variable, so I randomly picked an application - winword.exe (Microsoft Word) and tried to launch it from the command line:

The reason winword.exe worked is that a registry key exists which defined the path to Microsoft Word (Winword.exe). A similar key exists for Firefox.exe and Chrome.exe if those applications are installed.

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths
HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionApp Paths

What I want to know is where exactly does the command prompt look for executables?

System PATH Variable, User PATH Variable, and the various keys within ..App Paths. I was able to confirm that Audacity does not create a key for itself when it's installed.

When the ShellExecuteEx function is called with the name of an
executable file in its lpFile parameter, there are several places
where the function looks for the file. We recommend registering your
application in the App Paths registry subkey. Doing so avoids the need
for applications to modify the system PATH environment variable.

• The current working directory.


• The Windows directory only (no subdirectories are searched).


• The WindowsSystem32 directory.


• Directories listed in the PATH environment variable.


• Recommended: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

Source: Application Registration

share|improve this answer

answered Aug 23 at 6:33

Ramhound

17.4k145574

At first, I thought that cmd only looks for executables in the directories contained in the PATH variable, so I randomly picked an application - winword.exe (Microsoft Word) and tried to launch it from the command line:

The reason winword.exe worked is that a registry key exists which defined the path to Microsoft Word (Winword.exe). A similar key exists for Firefox.exe and Chrome.exe if those applications are installed.

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths
HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionApp Paths

What I want to know is where exactly does the command prompt look for executables?

System PATH Variable, User PATH Variable, and the various keys within ..App Paths. I was able to confirm that Audacity does not create a key for itself when it's installed.

When the ShellExecuteEx function is called with the name of an
executable file in its lpFile parameter, there are several places
where the function looks for the file. We recommend registering your
application in the App Paths registry subkey. Doing so avoids the need
for applications to modify the system PATH environment variable.

• The current working directory.


• The Windows directory only (no subdirectories are searched).


• The WindowsSystem32 directory.


• Directories listed in the PATH environment variable.


• Recommended: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

Source: Application Registration

share|improve this answer

answered Aug 23 at 6:33

Ramhound

17.4k145574

share|improve this answer

share|improve this answer

answered Aug 23 at 6:33

Ramhound

17.4k145574

answered Aug 23 at 6:33

Ramhound

17.4k145574

answered Aug 23 at 6:33

Ramhound

17.4k145574

17.4k145574

add a comment | 

add a comment | 

up vote
14
down vote

From the command prompt, if you just enter WinWord it fails to run.

If you enter START WinWord it runs.

The Start command is key here.

When you try to execute a file through the start command, Command Prompt does not perform any searching. Instead, it passes the file name (and arguments) over to Windows itself (via the ShellExecuteEx API call), which must then search for the file's location. There are several places it searches in the following order:

• The current working directory.




• The Windows directory only (no subdirectories are searched).




• The WindowsSystem32 directory.




• Directories listed in the PATH environment variable.




• Recommended:
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

WinWord is in that registry key. The key is there to keep PATH from getting too long.

share|improve this answer

edited Aug 23 at 16:11

MrWhite

1,57631937

answered Aug 23 at 6:26

Larryc

38216

• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  Please cite and quote all sources. Unless you wrote the search order from memory, you should have cited your source, which indicated the list and the order which it's searched.
  – Ramhound
  Aug 23 at 6:51
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  The source would be my notes from something I was working on a couple years ago. I don't know where I picked it up back then, web pages come and go.
  – Larryc
  Aug 23 at 20:14
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  You got them from the same documentation everyone else got them from.
  – Ramhound
  Aug 23 at 21:03
  

  
  
  
  

add a comment | 

up vote
14
down vote

From the command prompt, if you just enter WinWord it fails to run.

If you enter START WinWord it runs.

The Start command is key here.

When you try to execute a file through the start command, Command Prompt does not perform any searching. Instead, it passes the file name (and arguments) over to Windows itself (via the ShellExecuteEx API call), which must then search for the file's location. There are several places it searches in the following order:

• The current working directory.




• The Windows directory only (no subdirectories are searched).




• The WindowsSystem32 directory.




• Directories listed in the PATH environment variable.




• Recommended:
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

WinWord is in that registry key. The key is there to keep PATH from getting too long.

share|improve this answer

edited Aug 23 at 16:11

MrWhite

1,57631937

answered Aug 23 at 6:26

Larryc

38216

• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  Please cite and quote all sources. Unless you wrote the search order from memory, you should have cited your source, which indicated the list and the order which it's searched.
  – Ramhound
  Aug 23 at 6:51
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  The source would be my notes from something I was working on a couple years ago. I don't know where I picked it up back then, web pages come and go.
  – Larryc
  Aug 23 at 20:14
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  You got them from the same documentation everyone else got them from.
  – Ramhound
  Aug 23 at 21:03
  

  
  
  
  

add a comment | 

up vote
14
down vote

up vote
14
down vote

From the command prompt, if you just enter WinWord it fails to run.

If you enter START WinWord it runs.

The Start command is key here.

When you try to execute a file through the start command, Command Prompt does not perform any searching. Instead, it passes the file name (and arguments) over to Windows itself (via the ShellExecuteEx API call), which must then search for the file's location. There are several places it searches in the following order:

• The current working directory.




• The Windows directory only (no subdirectories are searched).




• The WindowsSystem32 directory.




• Directories listed in the PATH environment variable.




• Recommended:
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

WinWord is in that registry key. The key is there to keep PATH from getting too long.

share|improve this answer

edited Aug 23 at 16:11

MrWhite

1,57631937

answered Aug 23 at 6:26

Larryc

38216

From the command prompt, if you just enter WinWord it fails to run.

If you enter START WinWord it runs.

The Start command is key here.

When you try to execute a file through the start command, Command Prompt does not perform any searching. Instead, it passes the file name (and arguments) over to Windows itself (via the ShellExecuteEx API call), which must then search for the file's location. There are several places it searches in the following order:

• The current working directory.




• The Windows directory only (no subdirectories are searched).




• The WindowsSystem32 directory.




• Directories listed in the PATH environment variable.




• Recommended:
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

WinWord is in that registry key. The key is there to keep PATH from getting too long.

share|improve this answer

edited Aug 23 at 16:11

MrWhite

1,57631937

answered Aug 23 at 6:26

Larryc

38216

share|improve this answer

share|improve this answer

edited Aug 23 at 16:11

MrWhite

1,57631937

edited Aug 23 at 16:11

MrWhite

1,57631937

edited Aug 23 at 16:11

MrWhite

1,57631937

1,57631937

answered Aug 23 at 6:26

Larryc

38216

answered Aug 23 at 6:26

Larryc

38216

answered Aug 23 at 6:26

Larryc

38216

38216

• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  Please cite and quote all sources. Unless you wrote the search order from memory, you should have cited your source, which indicated the list and the order which it's searched.
  – Ramhound
  Aug 23 at 6:51
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  The source would be my notes from something I was working on a couple years ago. I don't know where I picked it up back then, web pages come and go.
  – Larryc
  Aug 23 at 20:14
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  You got them from the same documentation everyone else got them from.
  – Ramhound
  Aug 23 at 21:03
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  Please cite and quote all sources. Unless you wrote the search order from memory, you should have cited your source, which indicated the list and the order which it's searched.
  – Ramhound
  Aug 23 at 6:51
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  The source would be my notes from something I was working on a couple years ago. I don't know where I picked it up back then, web pages come and go.
  – Larryc
  Aug 23 at 20:14
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  You got them from the same documentation everyone else got them from.
  – Ramhound
  Aug 23 at 21:03
  

  
  
  
  

7

7

Please cite and quote all sources. Unless you wrote the search order from memory, you should have cited your source, which indicated the list and the order which it's searched.
– Ramhound
Aug 23 at 6:51

Please cite and quote all sources. Unless you wrote the search order from memory, you should have cited your source, which indicated the list and the order which it's searched.
– Ramhound
Aug 23 at 6:51

The source would be my notes from something I was working on a couple years ago. I don't know where I picked it up back then, web pages come and go.
– Larryc
Aug 23 at 20:14

The source would be my notes from something I was working on a couple years ago. I don't know where I picked it up back then, web pages come and go.
– Larryc
Aug 23 at 20:14

5

5

You got them from the same documentation everyone else got them from.
– Ramhound
Aug 23 at 21:03

You got them from the same documentation everyone else got them from.
– Ramhound
Aug 23 at 21:03

add a comment | 

up vote
6
down vote

The program (when you specify its module name without drive/path in command prompt) in Windows command processor (CMD.EXE) can be started when found:

• by PATH environment variable (both executable and its hardlink/softlink/shortcut with the same name)




• by DOSKEY alias




• by application path from HKLMSoftwareMicrosoftWindowsCurrentVersionApp Paths or HKCUSoftwareMicrosoftWindowsCurrentVersionApp Paths (when using start command)

Using this knowledge (especially the last one) you can create your own aliases convenient for you. For example you can create HKCUSoftwareMicrosoftWindowsCurrentVersionApp Pathsau.exe with default value of C:Program Files (x86)AudacityAudacity.exe and start this application simply by typing start au in command prompt.

share|improve this answer

edited Aug 23 at 6:09

answered Aug 23 at 6:00

Akina

1,0217

add a comment | 

up vote
6
down vote

The program (when you specify its module name without drive/path in command prompt) in Windows command processor (CMD.EXE) can be started when found:

• by PATH environment variable (both executable and its hardlink/softlink/shortcut with the same name)




• by DOSKEY alias




• by application path from HKLMSoftwareMicrosoftWindowsCurrentVersionApp Paths or HKCUSoftwareMicrosoftWindowsCurrentVersionApp Paths (when using start command)

Using this knowledge (especially the last one) you can create your own aliases convenient for you. For example you can create HKCUSoftwareMicrosoftWindowsCurrentVersionApp Pathsau.exe with default value of C:Program Files (x86)AudacityAudacity.exe and start this application simply by typing start au in command prompt.

share|improve this answer

edited Aug 23 at 6:09

answered Aug 23 at 6:00

Akina

1,0217

add a comment | 

up vote
6
down vote

up vote
6
down vote

The program (when you specify its module name without drive/path in command prompt) in Windows command processor (CMD.EXE) can be started when found:

• by PATH environment variable (both executable and its hardlink/softlink/shortcut with the same name)




• by DOSKEY alias




• by application path from HKLMSoftwareMicrosoftWindowsCurrentVersionApp Paths or HKCUSoftwareMicrosoftWindowsCurrentVersionApp Paths (when using start command)

Using this knowledge (especially the last one) you can create your own aliases convenient for you. For example you can create HKCUSoftwareMicrosoftWindowsCurrentVersionApp Pathsau.exe with default value of C:Program Files (x86)AudacityAudacity.exe and start this application simply by typing start au in command prompt.

share|improve this answer

edited Aug 23 at 6:09

answered Aug 23 at 6:00

Akina

1,0217

The program (when you specify its module name without drive/path in command prompt) in Windows command processor (CMD.EXE) can be started when found:

• by PATH environment variable (both executable and its hardlink/softlink/shortcut with the same name)




• by DOSKEY alias




• by application path from HKLMSoftwareMicrosoftWindowsCurrentVersionApp Paths or HKCUSoftwareMicrosoftWindowsCurrentVersionApp Paths (when using start command)

Using this knowledge (especially the last one) you can create your own aliases convenient for you. For example you can create HKCUSoftwareMicrosoftWindowsCurrentVersionApp Pathsau.exe with default value of C:Program Files (x86)AudacityAudacity.exe and start this application simply by typing start au in command prompt.

share|improve this answer

edited Aug 23 at 6:09

answered Aug 23 at 6:00

Akina

1,0217

share|improve this answer

share|improve this answer

edited Aug 23 at 6:09

edited Aug 23 at 6:09

edited Aug 23 at 6:09

answered Aug 23 at 6:00

Akina

1,0217

answered Aug 23 at 6:00

Akina

1,0217

answered Aug 23 at 6:00

Akina

1,0217

1,0217

add a comment | 

add a comment | 

up vote
0
down vote

While the other answers are likely to be the specific reason in your case, there is also another answer to your question which could have been the case for some other applications: in the same place you were looking, but with different file extensions.

You specifically said that you were searching for files with extension exe. Windows will also attempt to execute files of other extensions.

Another environment variable that comes into play when executing a command is the variable PATHEXT. This is a ;-delimited list of file extensions to attempt to execute. If you echo PATHEXT you might see something like .COM;.EXE;.BAT;.CMD;.VBS;... (etc.). Some applications use these other file types as their end-user entry point. It is much less common, but it happens. I have used several major commercial products which start from .BAT scripts. To use one of them as an example, I can start it with the command standalone even though there is no standalone.exe... instead, it has a standalone.bat.

Some of the extensions I have on the PATHEXT I'm looking at right now I have never had an application use. Ones that I have run into much more commonly (but obviously not as much as exe) are: .com, .bat, .vbs, .js, .jar. The first two are windows batch script files, and the other three are file types for specific programming languages which are run from scripts or virtual machines instead of from exes (respectively: visual basic, javascript, and java).

share|improve this answer

answered Aug 24 at 0:13

Aaron

1264

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Down-voter care to comment (I know it's usually futile to ask, but sometimes I get a response)? Did I make a mistake somewhere?
  – Aaron
  Aug 24 at 16:42
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Not me, but at a wild guess it's because while PATHEXT and PATH, are both related to getting things running, they are somewhat orthogonal in their respective tasks. PATH specifies where to look for things to run, and is what the OP was asking, while PATHEXT specifies what can be run.
  – dgnuff
  Aug 24 at 19:14
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @dgnuff Interesting, since that was my point: OP specifically worded the question in a way that begged for a frame challenge... in SE terms, they were asking an "XY question" by making an assumption that the file being run was not in the places that were already being searched on the path. Anyway, thanks.
  – Aaron
  Aug 27 at 14:37
  

  
  
  
  

add a comment | 

up vote
0
down vote

While the other answers are likely to be the specific reason in your case, there is also another answer to your question which could have been the case for some other applications: in the same place you were looking, but with different file extensions.

You specifically said that you were searching for files with extension exe. Windows will also attempt to execute files of other extensions.

Another environment variable that comes into play when executing a command is the variable PATHEXT. This is a ;-delimited list of file extensions to attempt to execute. If you echo PATHEXT you might see something like .COM;.EXE;.BAT;.CMD;.VBS;... (etc.). Some applications use these other file types as their end-user entry point. It is much less common, but it happens. I have used several major commercial products which start from .BAT scripts. To use one of them as an example, I can start it with the command standalone even though there is no standalone.exe... instead, it has a standalone.bat.

Some of the extensions I have on the PATHEXT I'm looking at right now I have never had an application use. Ones that I have run into much more commonly (but obviously not as much as exe) are: .com, .bat, .vbs, .js, .jar. The first two are windows batch script files, and the other three are file types for specific programming languages which are run from scripts or virtual machines instead of from exes (respectively: visual basic, javascript, and java).

share|improve this answer

answered Aug 24 at 0:13

Aaron

1264

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Down-voter care to comment (I know it's usually futile to ask, but sometimes I get a response)? Did I make a mistake somewhere?
  – Aaron
  Aug 24 at 16:42
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Not me, but at a wild guess it's because while PATHEXT and PATH, are both related to getting things running, they are somewhat orthogonal in their respective tasks. PATH specifies where to look for things to run, and is what the OP was asking, while PATHEXT specifies what can be run.
  – dgnuff
  Aug 24 at 19:14
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @dgnuff Interesting, since that was my point: OP specifically worded the question in a way that begged for a frame challenge... in SE terms, they were asking an "XY question" by making an assumption that the file being run was not in the places that were already being searched on the path. Anyway, thanks.
  – Aaron
  Aug 27 at 14:37
  

  
  
  
  

add a comment | 

up vote
0
down vote

up vote
0
down vote

While the other answers are likely to be the specific reason in your case, there is also another answer to your question which could have been the case for some other applications: in the same place you were looking, but with different file extensions.

You specifically said that you were searching for files with extension exe. Windows will also attempt to execute files of other extensions.

Another environment variable that comes into play when executing a command is the variable PATHEXT. This is a ;-delimited list of file extensions to attempt to execute. If you echo PATHEXT you might see something like .COM;.EXE;.BAT;.CMD;.VBS;... (etc.). Some applications use these other file types as their end-user entry point. It is much less common, but it happens. I have used several major commercial products which start from .BAT scripts. To use one of them as an example, I can start it with the command standalone even though there is no standalone.exe... instead, it has a standalone.bat.

Some of the extensions I have on the PATHEXT I'm looking at right now I have never had an application use. Ones that I have run into much more commonly (but obviously not as much as exe) are: .com, .bat, .vbs, .js, .jar. The first two are windows batch script files, and the other three are file types for specific programming languages which are run from scripts or virtual machines instead of from exes (respectively: visual basic, javascript, and java).

share|improve this answer

answered Aug 24 at 0:13

Aaron

1264

While the other answers are likely to be the specific reason in your case, there is also another answer to your question which could have been the case for some other applications: in the same place you were looking, but with different file extensions.

You specifically said that you were searching for files with extension exe. Windows will also attempt to execute files of other extensions.

Another environment variable that comes into play when executing a command is the variable PATHEXT. This is a ;-delimited list of file extensions to attempt to execute. If you echo PATHEXT you might see something like .COM;.EXE;.BAT;.CMD;.VBS;... (etc.). Some applications use these other file types as their end-user entry point. It is much less common, but it happens. I have used several major commercial products which start from .BAT scripts. To use one of them as an example, I can start it with the command standalone even though there is no standalone.exe... instead, it has a standalone.bat.

Some of the extensions I have on the PATHEXT I'm looking at right now I have never had an application use. Ones that I have run into much more commonly (but obviously not as much as exe) are: .com, .bat, .vbs, .js, .jar. The first two are windows batch script files, and the other three are file types for specific programming languages which are run from scripts or virtual machines instead of from exes (respectively: visual basic, javascript, and java).

share|improve this answer

answered Aug 24 at 0:13

Aaron

1264

share|improve this answer

share|improve this answer

answered Aug 24 at 0:13

Aaron

1264

answered Aug 24 at 0:13

Aaron

1264

answered Aug 24 at 0:13

Aaron

1264

1264

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Down-voter care to comment (I know it's usually futile to ask, but sometimes I get a response)? Did I make a mistake somewhere?
  – Aaron
  Aug 24 at 16:42
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Not me, but at a wild guess it's because while PATHEXT and PATH, are both related to getting things running, they are somewhat orthogonal in their respective tasks. PATH specifies where to look for things to run, and is what the OP was asking, while PATHEXT specifies what can be run.
  – dgnuff
  Aug 24 at 19:14
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @dgnuff Interesting, since that was my point: OP specifically worded the question in a way that begged for a frame challenge... in SE terms, they were asking an "XY question" by making an assumption that the file being run was not in the places that were already being searched on the path. Anyway, thanks.
  – Aaron
  Aug 27 at 14:37
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Down-voter care to comment (I know it's usually futile to ask, but sometimes I get a response)? Did I make a mistake somewhere?
  – Aaron
  Aug 24 at 16:42
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Not me, but at a wild guess it's because while PATHEXT and PATH, are both related to getting things running, they are somewhat orthogonal in their respective tasks. PATH specifies where to look for things to run, and is what the OP was asking, while PATHEXT specifies what can be run.
  – dgnuff
  Aug 24 at 19:14
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @dgnuff Interesting, since that was my point: OP specifically worded the question in a way that begged for a frame challenge... in SE terms, they were asking an "XY question" by making an assumption that the file being run was not in the places that were already being searched on the path. Anyway, thanks.
  – Aaron
  Aug 27 at 14:37
  

  
  
  
  

Down-voter care to comment (I know it's usually futile to ask, but sometimes I get a response)? Did I make a mistake somewhere?
– Aaron
Aug 24 at 16:42

Down-voter care to comment (I know it's usually futile to ask, but sometimes I get a response)? Did I make a mistake somewhere?
– Aaron
Aug 24 at 16:42

Not me, but at a wild guess it's because while PATHEXT and PATH, are both related to getting things running, they are somewhat orthogonal in their respective tasks. PATH specifies where to look for things to run, and is what the OP was asking, while PATHEXT specifies what can be run.
– dgnuff
Aug 24 at 19:14

Not me, but at a wild guess it's because while PATHEXT and PATH, are both related to getting things running, they are somewhat orthogonal in their respective tasks. PATH specifies where to look for things to run, and is what the OP was asking, while PATHEXT specifies what can be run.
– dgnuff
Aug 24 at 19:14

@dgnuff Interesting, since that was my point: OP specifically worded the question in a way that begged for a frame challenge... in SE terms, they were asking an "XY question" by making an assumption that the file being run was not in the places that were already being searched on the path. Anyway, thanks.
– Aaron
Aug 27 at 14:37

@dgnuff Interesting, since that was my point: OP specifically worded the question in a way that begged for a frame challenge... in SE terms, they were asking an "XY question" by making an assumption that the file being run was not in the places that were already being searched on the path. Anyway, thanks.
– Aaron
Aug 27 at 14:37

add a comment | 

up vote
0
down vote

start winword does not tell the command prompt to launch winword. It tells the command prompt to launch start with argument winword. Start uses its own methods to find winword.

Just winword tells the command prompt to launch winword. And if you try that, since winword is not on the PATH, it doesn't launch.

share|improve this answer

answered Aug 26 at 15:43

Eric Towers

1514

add a comment | 

up vote
0
down vote

start winword does not tell the command prompt to launch winword. It tells the command prompt to launch start with argument winword. Start uses its own methods to find winword.

Just winword tells the command prompt to launch winword. And if you try that, since winword is not on the PATH, it doesn't launch.

share|improve this answer

answered Aug 26 at 15:43

Eric Towers

1514

add a comment | 

up vote
0
down vote

up vote
0
down vote

start winword does not tell the command prompt to launch winword. It tells the command prompt to launch start with argument winword. Start uses its own methods to find winword.

Just winword tells the command prompt to launch winword. And if you try that, since winword is not on the PATH, it doesn't launch.

share|improve this answer

answered Aug 26 at 15:43

Eric Towers

1514

start winword does not tell the command prompt to launch winword. It tells the command prompt to launch start with argument winword. Start uses its own methods to find winword.

Just winword tells the command prompt to launch winword. And if you try that, since winword is not on the PATH, it doesn't launch.

share|improve this answer

answered Aug 26 at 15:43

Eric Towers

1514

share|improve this answer

share|improve this answer

answered Aug 26 at 15:43

Eric Towers

1514

answered Aug 26 at 15:43

Eric Towers

1514

answered Aug 26 at 15:43

Eric Towers

1514

1514

add a comment | 

add a comment | 

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1351532%2fdoes-the-windows-command-prompt-search-somewhere-other-than-those-locations-spec%23new-answer', 'question_page');

);

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email