Shortcut/start-up folder nonsense

[vefatica]

I have a desktop shortcut to TCCv19 which specifies

Start in: g:\tc19

With this line in TCSTART

CDD .

the shortcut causes TCC to start in g:\.
When I comment that line, it starts in g:\tc19 (as it should in both cases).

Yes, there's really only one '.' after the CDD.

 

[Alpengreis]

It seems, the tcstart.btm takes always "as INTERNAL variable" the main dir and it's not related to a defined dir in a shortcut.

For your case ...
tcstart takes "c:\" except you define a dir for cdd

Then CDD . from "C:\" is "C:\"!

If you set nothing, then tc(start) is relatet to the defined dir in shortcut ("start in DIR").

You can test this with following tcstart ...

cdd

 

[vefatica]

Whet internal variable? I'm not using TCMD. The shortcut is to TCC.EXE. If I use "CDD" in TCSTART, it starts in the shortcut-specified directory. If I use "CDD ." in TCSTART, it starts in the root of the shortcut-specified directory. I have duplicated the behavior on another machine.

And I have watched it happen with WinDbg. With "g:\tc19" (or "g:\tc19\") specified in the shorcut, and "CDD ." in TCSTART, it issues SetCurrentDirectoryW(L"g:\").

This is unlike TCC 18, 17, 16, ...

 

[vefatica]

OK, forget about shortcuts. Use the Start\Run mechanism (Win-R).

Start\Run\g:\tc19\tcc.exe ...

With "CDD ." in TCSTART.BTM, it starts in "g:\".
Without "CDD ." in TCSTART.BTM, it starts in "g:\tc19".

And I related the WinDbg experiment wrongly. Normally, started by WinDbg (Open Executable) TCC starts in

c:\program files\debugging tools for windows (x86)

With "CDD ." in TCSTART.BTM, it starts in

c:\

Here's TCC calling SetCurrentDirectoryW(L"C:\").

 

[Alpengreis]

I had described only the behaviour. Not meant a REAL variable (because this I had it included it in "" signs) as pseudo text ;-) forget the word variable). Also not, if it's right or not right or about not the same in versions before and so far ...

My intention was to let you know that it's ALWAYS (it seems so at least) the main dir of related drive (in your case g:\ (not c:\ as I had wrote above) - EXCEPT you set a dir with CDD. So it's not related to the POINT after the CDD command (or even CD). Regardless of TCC or TCMD.

But you know it now, as I can see ...

Or in other words:

If you make this tcstart.btm ...

cdd "g:\tc19\"
cdd .

you should be in g:\tc19


or if you make this tcstart.btm ...

cdd

you should receive the following ...

G:\
[G:\tc19]

 

[vefatica]

Every one of my TCSTARTs, going back to version 11 contain "CDD .". For each one of them except v19, if I navigate with Explorer to its home directory (g:\tc11, ..., g:\tc18) and double click TCC.EXE, it starts up in that home directory. If I do the same with v19, it starts in g:\.

 

[Alpengreis]

yep, but not the "." is the problem!

The command itself is the problem (cdd OR cd) or whatever ...

make your tcstart.btm without the "." (means only a "CDD") and you will see the main dir G:\

or what is the result with this tcstart ...

cdd "g:\tc19\"
cdd .

?

it seems the CDD / CD ... receives NOT the right path ...

 

[Alpengreis]

or as last try (sorry - it's a bit difficult for me in english unfortunately)

1) if you remove your "cdd ." tcc should start in the defined dir from your shortcut
2) if you define a path in tcstart.btm - tcc start with this path, then a "cdd ." later is no problem
3) if you have only a "cdd" then you see the related main dir and THIS IS THE PROBLEM, not especially the "."!

Please make really my examples from above.

then you can see: not the "." is the problem, the problem begins "earlier".

I hope, you understand, what I mean :-)

 

[vefatica]

1. Correct. If I remove "CDD ." TCC starts in the shortcut-specified directory.
2. I don't know what you mean by "define a path in tcstart.btm"
3. No. If I have only "CDD", TCC starts in the shortcut-specified directory. But the CDD command itself reports the root directory. When I remove the '.' from the TCSTART below, and leave only "CDD", it starts like this (which makes no sense to me).

G:\  (the output of CDD)
g:\tc19>  (my prompt, $p$g$s

Here's my TCSTART.BTM.

@ECHO OFF
IF %_PIPE == 1 ( CURSOR OFF & QUIT )
IF %_TRANSIENT == 1 QUIT
ECHO.
CDD .

 

[Alpengreis]

2. I don't know what you mean by "define a path in tcstart.btm"

I mean if you define for example "cdd g:\tc19" - then a following "cdd ." is correct (because not the "." itself is the problem).

3. No. If I have only "CDD", TCC starts in the shortcut-specified directory. But the CDD command itself reports the root directory.

This IS what I meant. I had not said, you are not in the desired dir. But CDD shows you the incorrect received path.

When I remove the '.' from the TCSTART below, and leave only "CDD", it starts like this (which makes no sense to me).

G:\  (the output of CDD)
g:\tc19>  (my prompt, $p$g$s

Yep, I knew that. It's because the path was not received correctly (main dir only).

See: as soon if you use CDD (OR CD) WITHOUT A FOLLOWING PATH in your tcstart.btm, it has the main dir path (in your scenario "G:\"). Regardless if it has the "." or not.

means:
- if you make a "cdd .": "cdd ." from "G:\" is "G:\"
- if you set explicit a path before in your tcstart.btm - for ex. "cdd g:\", the path is correct for following commands, INCLUSIVE a "cdd ."
- if you don't use "cdd ." (or "cd .") in your tcstart.btm, it receives the path ("start in") from your shortcut.

BTW: the same problem is (for ex.) with "CDD .." because it "has" the main directory. In your case not relevant, because you are only one step "deeper" than main dir. But I have tested it with a more deep dir structure.

 

[w_krieger]

If you mean to start in the tcc directory, you might use cdd %@path[%comspec]

The windows shell makes heavy use of %%L, but if you put '.' as the directory, it's pretty much letting the system pick the path.
You could do like I do, and store values in the registry, and use cd %@regquery[HKLM\Software\Wendy\cdata] to change to the cdata directory.

 

[vefatica]

'.' has always meant the current directory. "CDD ." has long been a way to get the start-up directory at the end of the directory history (which may not be necessary today). I can only trace it back to 4NT v8, but I'm sure it goes back much farther than that.

Putting a change of directory in TCSTART would be disastrous for just about anyone.

 

[Jay Sage]

Putting a change of directory in TCSTART would be disastrous for just about anyone.

Why do you say that? I have always included a line at the end of TCSTART of the form CDD 'MyFavoriteStartingDirectory'. That has worked just fine.

However, with that line in TCSTART, I cannot use the new version-19 feature of cloning TCC. That's why I've been asking how specify where TCC tabs in TCMD start up by default or how I can determine in TCSTART that cloning is taking place so that I can skip various commands. In fact, I wonder why a cloned TCC even runs TCSTART, which often has commands that could interfere with the cloning.

 

[vefatica]

Why do you say that? I have always included a line at the end of TCSTART of the form CDD 'MyFavoriteStartingDirectory'. That has worked just fine.

You must have it protected somehow. Otherwise, a child TCC, say in a pipe, might very well be expecting to be in the same directory as its parent, and not be there.

I don't know why this discussion has drifted so. Quite simply, "CDD ." in TCSTART.BTM doesn't work the way it has for ages. It now does something inexplicable, and it screws up shortcut-specified start-up directories and Explorer's habit of starting EXEs you double-click on in the folder where the double-click occurred.

 

[Jay Sage]

You must have it protected somehow. Otherwise, a child TCC, say in a pipe, might very well be expecting to be in the same directory as its parent, and not be there.

At the beginning of TCSTART, I use code with %_transient, %_pipe, and %_ide to skip out. I wish there were a variable %_clone that would let me skip stuff in that situation.

As for your original issue, we've all been waiting for Rex to comment. Either there is a bug that Rex will fix, or he'll have a cogent explanation for it. But it certainly seems bizarre.

 

[vefatica]

I think your idea of _CLONE was an excellent one. It could be either 0 (not a clone) or the PID of the cloned process.

 

[rconn]

I have a desktop shortcut to TCCv19 which specifies

Start in: g:\tc19

With this line in TCSTART

CDD .

the shortcut causes TCC to start in g:\.
When I comment that line, it starts in g:\tc19 (as it should in both cases).

It's not a TCC issue (the relevant code is the same in V19 & V18); Microsoft broke it in VS2015. I can hack around it but first I want to find out if they did it deliberately.

p.s.: It doesn't have anything to do with the various theories in this thread -- the problem is that Microsoft isn't setting the "=D:=xxx" environment variable correctly.

 

[vefatica]

the problem is that Microsoft isn't setting the "=D:=xxx" environment variable correctly.

Yeah, that's easy to see now that I know to look for it. I'm a bit surprised that TCC uses those strings to determine its own startup directory.

Who provides those strings ... the CRT? And who maintains them ... the CRT? And how is it decided which drives to mention there (counting SUBSTs, I have 14 drive letters)? Explorer has none of those strings. A newly started TCC has these (V: is a SUBST):

=C:=C:\
=G:=G:\
=V:=V:\

A TextPad running right now has these.

=C:=C:\
=G:=G:\tc19
=L:=L:\
=V:=V:\

 

[vefatica]

Speaking of the (seemingly dinosaur-ish) notion of each drive having a current directory, does anyone still use it? I never liked it, even in the days of DOS and 4DOS ... never learned to capitalize on it.

Can the current directory on some drive be set without actually going there?

 

[rconn]

Speaking of the (seemingly dinosaur-ish) notion of each drive having a current directory, does anyone still use it? I never liked it, even in the days of DOS and 4DOS ... never learned to capitalize on it.

Can the current directory on some drive be set without actually going there?

Yes, with CD.

 

[rconn]

Yeah, that's easy to see now that I know to look for it. I'm a bit surprised that TCC uses those strings to determine its own startup directory.

Who provides those strings ... the CRT? And who maintains them ... the CRT? And how is it decided which drives to mention there (counting SUBSTs, I have 14 drive letters)? Explorer has none of those strings. A newly started TCC has these (V: is a SUBST):

TCC does not use those strings to determine its startup directory. It uses those strings to determine the current directory on the default drive when you pass it a ".". They are essential (like, really, really essential) for CMD compatibility and to run a few bajillion existing batch files.

The run time library sets those strings; it's up to the app to maintain them.

And yes, people use them all the time to do things like copying from one drive to another without having to enter the full pathnames.