My PATH var is not honored in TCs command line?

[Gerdd]

I suspect I am not fully understanding something here:

I have a directory structure like this:

Projects
Projects\Proj1
Projects\Proj2
Projects\proj3
(etc.)

The idea is that anything that all projects should be able to access will live in the projects directory. Thus, by adding ..\; to the path variable all of that will be accessible from any of the projects.

That used to work well in DOS and as far as I recall in older versions of Windows.

It still works well in a command prompt window, including the one opened by Commands->Open command prompt window.

It doesn't from the command prompt line at the bottom of the TC window.

to check the path I tried to use the set command to list all environment variables: set >sets.txt

and yes, the path variable looks like this:

PATH= ..\;C:\ (etc.)

So it should work, shouldn't it?

But my seg.cmd in the projects directory is not found if I use it without the path, but all is well when I type ..\seg (in other words if I explicitly mention the path to the seg.cmd file.)

[white]

PATH= ..\;C:\ (etc.)

So it should work, shouldn't it?

Confirmed that it doesn't work except when using noclose.exe (use Shift+Enter instead of Enter).

[Gerdd]

Confirmed that it does indeed work with Shift+Enter (noclose.exe?) but then the window stays open (that is actually useful in some other circumstances I sometimes encounter - have I ever read about that? It rings vaguely familiar ... - one of the advantages of "linear documentation" - the old style manual that you start reading on page 1 and continue until there are no more pages - at which time you have read everything there is. With today's help systems we are never sure if we have been everywhere that's worth visiting - oh, well!)

Okay, but joking aside, is there a way to rig this so it does work "the normal way"?

[white]

Okay, but joking aside, is there a way to rig this so it does work "the normal way"?

Don't think so. Perhaps Mr. Ghisler will fix it.

[ghisler(Author)]

I'm not parsing the path variable myself, I'm just using Windows functions like ShellExecuteEx which do that. Maybe they don't like ".." as a path.
Noclose.exe calls CreateProcess, maybe it handles the path variable differently.

[Gerdd]

Okay, the hint about noclose.exe is helpful.

@ghisler(author) - it turns out that ".." as a path element still works in Windows 10 (can't say about 11 yet) but not in the TC command line - when I use "Shift-Enter" to invoke noclose it does indeed work but leaves the command prompt open, as advertised.

Now my objective was to trim down the number of activities (keystrokes, mouse actions, etc.) for the workflow. So, typing "..\" in front of the command (which works) or using "shift-enter" and then closing the window (Which also works) are "works-arounds"

So is the next one: adding "&&exit" to the command - either when typing it in or as part of the cmd file - will close the window that "shift-enter" (noclose.exe) keeps open.

Assuming my sample command "seg %1" these are the options I tried:

seg %1 -> "file not found"
..\seg %1 -> works
seg %1 (Shift-Enter) -> works but leaves window open
seg %1 && exit (Shift-Enter) -> works, closes window but is now the biggest extra effort :-{
adding the "&& exit" string into seg.cmd is another workaround that will close the "unwanted" window but still requires the "shift-enter"

I assume that what noclose.exe does is to start a "cmd /K" which then honours the path variable.
Whatever method is invoked when using just the enter key doesn't seem to do that. Maybe what could help here is a "close.exe" that gets invoked in this case and starts a "cmd /C" session, which then should also honour the path variable.

(as an aside, I have also - in the distant past - successfully used "..\.." and ..\..\.." as path elements.)

Another aside: built-in "internal" commands (implemented as part of cmd.exe) are also not found when used on the TC command line (without "shift-enter")

And yes, I suspect that the "ShellExecuteEx" vs. "CreateProcess" is actually the issue here. The question is am I expecting too much or is that a fixable item?

[white]

2Gerdd
You may want to define aliases for any commands you miss. See: https://www.ghisler.ch/wiki/index.php?title=Alias

You could define an alias "seg" to start a user-defined command which starts "..\seg".
etc.

[Gerdd]

@white
True, but at the end of the day that would be a LOT of aliases ...

"seg" was just an example - the most recent example where I encountered this. I have been on TC (formerly known as WC) since somewhere around 1995 to 1998, and have recently neglected updating, so I was on V9.xx level until a week ago. Then, before getting on the forum I thought the least I could do is to try things out with the latest version before raising it here. I am quite impressed with the responses from the community here!

(Even this alias suggestion - which may not be realistic for the number of commands I would be looking at - is a good hint for other situations I can imagine.)