# CD_ENTER makes wacky things happen

#### vefatica

I have this setup.

Code:
v:\> alias e

setlocal
set noexist=0
do i=1 to %#
if not exist %[%i] set noexist=%@eval[%noexist + 1]
enddo
iff %noexist GT 0 then
do i=1 to %noexist
touch /c /q %[%i]
enddo
endiff

v:\> alias cd_enter
v:\cdenter.btm

v:\> type v:\cdenter.btm
@echo off
echo %%1 is %1
echo The current directory is %_cwd

And it seems to work OK, including the builtin unknown command mechanism.

Code:
v:\> cd empty\
%1 is V:\empty
The current directory is V:\empty

v:\empty> cd ..
%1 is V:\
The current directory is V:\

v:\> foo
TCC: Unknown command "foo"

v:\>

Now I'll use the "e" alias to open v:\cdenter.btm in the editor. I'll close it without making any changes.

Code:
v:\> e v:\cdenter.btm

And now I'll try the CD_ENTER alias and I'll also enter a bogus command. Observe how the CD_ENTER alias no longer works, and that the built-in nknown command mechanism has gone bananas.

Code:
v:\> cd empty\

v:\empty> cd ..

v:\> foo
TCC: V:\cdenter.btm [0]  Unknown command "foo"

v:\>

My global alias list is intact. If I start a new instance all's well until I use the "e" alias (on any file!). Regardless of what file I open with "e", the unknown command mechanism goes berserk.

If I don't have CD_ENTER set, all's well (including my "e" alias).

#### vefatica

I can only guess that there's some sort of internal confusion between CD_ENTER (which I'm using) and UNKNOWN_CMD (which I'm not using).

I don't have a clue why my "e" alias triggers it.

#### vefatica

Here's another screwy one.

Code:
v:\> e test.bat

v:\> foo
TCC: Unknown command "foo"

v:\> alias cd_enter v:\cdenter.btm

v:\> foo
TCC: Unknown command "foo"

v:\> e test.bat

v:\> foo
TCC:  [11]  Unknown command "foo"

#### vefatica

In a nutshell ... if an alias points to a BTM and that BTM has a SETLOCAL without an ENDLOCAL then executing that alias screws up the CD_ENTER alias and the built-in unknown_cmd mechanism (and probably ohter things). Here's a simplified test.

The set-up:

Code:
v:\> alias cd_enter
v:\cdenter.btm

v:\> type cdenter.btm
@echo off
echo This is CDENTER.BTM

v:\> alias xx
test.btm

v:\> type test.btm
setlocal

See that CD_ENTER and the builtin unknown_cmd mechanism are OK.

Code:
v:\> empty\
This is CDENTER.BTM

v:\empty> cd -
This is CDENTER.BTM

v:\> foo
TCC: Unknown command "foo"

Now run the alias which whose BTM has a SETLOCAL but no ENDLOCAL.

Code:
v:\> xx

Now see that CD_ENTER and the builtin unknown_cmd mechanism are messed up.

Code:
v:\> empty\

v:\empty> cd -

v:\> foo
TCC: V:\cdenter.btm [0]  Unknown command "foo"

v:\>

So I guess an alias calling a BTM which has a SETLOCAL but no ENDLOCAL is (for now) a no-no.

#### Jay Sage

The operation of the CD_ENTER alias is so bizarre that I'm waiting to hear what Rex has to say. I think that it cannot be dealt with without access to the source code.

I didn't mention another strange thing earlier. When I included an "echo %_cwd" command in the alias, it reported the new directory, as expected. But the "dir" command showed the contents of the previous directory (actually the previous directory on the same drive in the case where a drive change occurred).

Because I have had some problems with my new computer being too fast, I even tried inserting a one-second delay before the "dir" command to allow everything to settle down, and it still showed the old directory rather than the new one.

I really like the feature , but there are serious problems with the implementation.

#### vefatica

You're quite right. _CWD gives the new directory while (a subsequent) DIR is in the old directory. I would have thought it impossible.

Code:
v:\> alias cd_enter
v:\cdenter.btm

v:\> type v:\cdenter.btm
echo CWD is %_CWD
dir /k /m zzzz*

v:\> empty\
CWD is V:\empty
TCC: (Sys) V:\cdenter.btm [2]  The system cannot find the file specified.
"V:\zzzz*"

v:\empty> cd -
CWD is V:\
TCC: (Sys) V:\cdenter.btm [2]  The system cannot find the file specified.
"V:\empty\zzzz*"

v:\>

#### rconn

Vince - the problem with your BTM files & CD_ENTER is caused by your batch syntax (albeit a rather obscure conflict).

Your tpad.btm file is invoking your cdenter.btm file during its (implicit) ENDLOCAL processing (which restores the current directory saved by SETLOCAL). But since you didn't put a CALL in your cd_enter alias, it's chaining to cdenter.btm. That puts the batch parser in a difficult position - tpad.btm has just been replaced by cdenter.btm, which bollixes up the remainder of the ENDLOCAL processing & the batch file never exits. You're back at the command line, but TCC thinks that it's still executing a batch file (try "echo %_batch).

#### vefatica

See the simplified version in post #4. Does that explanation also hold there?

#### vefatica

See the simplified version in post #4. Does that explanation also hold there?
I imagine it does. Is it safe/advisable to always use CALL in any alias that runs a BTM?

#### rconn

Unless you know that you want your batch file in the alias to replace the batch file you call it from, yes, you'd better use CALL.

#### rconn

See the simplified version in post #4. Does that explanation also hold there?
Yes.

Replies
1
Views
399
Replies
1
Views
865
Replies
2
Views
910
Replies
2
Views
751
Replies
8
Views
2K
Replies
9
Views
3K
Replies
4
Views
2K
Replies
2
Views
2K
Replies
16
Views
223
Replies
2
Views
400
Replies
3
Views
613
Replies
6
Views
970
Replies
8
Views
2K
Replies
15
Views
4K
Replies
1
Views
101