Easy way to get the directory where the current TCC.EXE resides?

[vefatica]

I'm using %@left[-7,%comspec] but that seems kludgy. I looked for an internal variable and didn't find one.

 

[Rodolfo]

What about "%@path[%comspec]"?
I do not know if You have to quote it.
regards
Rodolfo Giovanninetti

 

[w_krieger]

cdd %comspec%\.. is fine enough for me.

 

[Joe Caverly]

E:\Utils>echo %@path[%_cmdspec]
C:\Program Files\JPSoft\TCMD32\

Joe

 

[Charles Dye]

cdd %comspec%\.. is fine enough for me.

If you're feeling terse, you can omit the CDD and the second percent sign.

 

[samintz]

I think @Joe Caverly's use of _cmdspec vs COMSPEC is better IMO. COMSPEC is just an environment variable that can be changed even though you are running TCC. The internal variable will always point to TCC.

 

[samintz]

If you always start TCC from the same place, the _startpath variable could work too.

 

[vefatica]

I think @Joe Caverly's use of _cmdspec vs COMSPEC is better IMO. COMSPEC is just an environment variable that can be changed even though you are running TCC. The internal variable will always point to TCC.

Thanks, @samintz. You're right about that. And thanks @Joe Caverly and @Rodolfo. If I ever used _CMDSPEC it had to be a couple decades ago.

I wrote a BTM to make editing PATH easier ... split it into parts in a tmpfile, edit the file, put it back together again, set it. Is there something built-in to do that? And I wanted to use TCEDIT because everyone has it. I couldn't figure out a nice way to use the internal TCEDIT command and wait for the editor to exit (without getting a second instance of TCC). So I'm using TCEDIT.EXE directly and I needed a path to it. Any ideas on that?

I also thought of /A(ppend) and /P(repend) options for PATH to do a limited version of that without an editor. Good idea? I suppose I could make my BTM do that (optionally).

 

[Joe Caverly]

Not a solution, but from 2014...

Remove a semicolon-separated directory from the path

On occasion, I have programs in my path that conflict with other programs that I am wanting to use. For example, the hbmk2.exe program in c:\hb32\bin has it's own version of the MinGW compilers, while I use the MinGW compiler in C:\MinGW for other development applications. There are also times...

jpsoft.com

Joe

 

[samintz]

I assume ESET isn't an option? I use ESET all the time. The downside is cursor movement is terribly slow when you have long paths. But append and prepend are very easy with ESET.

 

[Joe Caverly]

Hey @vefatica,
Could you do something like this;

path /n | tcedit

Modify the path in TCEdit,
save to STDOUT,
and then do something with it?

Joe

 

[Joe Caverly]

@vefatica said:

I couldn't figure out a nice way to use the internal TCEDIT command and wait for the editor to exit (without getting a second instance of TCC).

@setlocal
@echo off
path /n | tcedit
waitfor tcedit
endlocal

Ref: WAITFOR - Wait for an app to exit or wait for input idle

Joe

 

[vefatica]

Hey @vefatica,
Could you do something like this;

path /n | tcedit

Modify the path in TCEdit,
save to STDOUT,
and then do something with it?

View attachment 4420

Joe

Too hard!

 

[samintz]

For a lot of these one-off types of things, I use the clipboard.

path /n | tcedit
do p in @clip: (set newp=%newp;%p)
set PATH=%@right[-1,%newp]

 

[vefatica]

For a lot of these one-off types of things, I use the clipboard.

path /n | tcedit
do p in @clip: (set newp=%newp;%p)
set PATH=%@right[-1,%newp]

I don't follow that. How does anything get into CLIP:?

 

[samintz]

I don't follow that. How does anything get into CLIP:?

You would edit in TCEDIT, then Ctrl+A, Ctrl+C. Then exit TCEDIT. I just showed the steps I take. You would need a waitfor before the do if you were to put that in a BTM or library.

 

[vefatica]

You would edit in TCEDIT, then Ctrl+A, Ctrl+C. Then exit TCEDIT. I just showed the steps I take. You would need a waitfor before the do if you were to put that in a BTM or library.

OK, I get it now. That's too much for the user to remember. I have this (so far). No doubt, there will be more changes.

:: PATHEDIT.BTM
setlocal

if "%1" == "/?" goto syntax
if "%1" == "/A" (shift & goto append)
if "%1" == "/P" (shift & goto prepend)

set before=%temp\pathedit_before.tmp
set after=%temp\pathedit_after.tmp

path /n > %before
start /wait /pgm "%@path[%_cmdspec]\tcedit.exe" %before
:: below, the second replace gets rid of a
:: trailing ';' which could be just left there
tpipe ^
    /input=%before ^
    /output=%after ^
    /replace=0,0,0,0,0,0,0,0,0,\r\n,; ^
    /replace=4,0,0,0,0,0,0,0,0,";\Z",""
set path=%@line[%after,0]
goto done

:append
    :: don't add a second ';' (not really necessary)
    set semicolon=%@if["%@right[1,%path]" == ";",,;]
    set path=%[path]%[semicolon]%1$
goto done

:prepend
    set path=%1$;%path
goto done

:syntax
    echo Usage: PATHEDIT.BTM [[/A(ppend) ^| /P(repend)] string]^r^n
    echo ^tWithout /A or /P, interactive using TCEDIT.EXE
    echo ^tDo not quote string
    echo ^tString can be of the form dir1;dir2[...]
goto done

:done
    endlocal path

 

[w_krieger]

for those eho use 4nt, tcc, tc, tci, tc34, comspec is set by the previous commmnd peocessor, tci is not a command processor v8.01 and v 35 used in the test.,

 

[JohnQSmith]

Why not just Prepend with...

set PATH=C:\New\Directory\Here;%PATH%

and Append with...

set PATH=%PATH%;C:\New\Directory\Here

I've done it that way since MS-DOS 4.01.

Edit: I think the discussion (or my interpretation of it) went sideways halfway through the thread and I answered the wrong question...

 

[AnrDaemon]

1. Long %PATH% (more specifically, very long environment block, which is most often caused by long %PATH% specifically) could cause programs to crash or behave otherwise unexpectedly.
2. Adding %PATH% entry for each single executable is just silly. Add them to AppPaths registry key and save yourself a couple of brain cells.
3. Wash your hands after toilet. And wash your %PATH% after each program update/install. Many like to add unwanted entries in there.