How to? start command /tab option/switch

[fpefpe]

Hello -- I have a batch file start starts the GIT (bash) shell in a tab(ed) window using the /tab
switch.

When I run the bat file, the git shell is started as a un-attached window. I then did a simple test,

start "go" /tab /pgm cmd.exe

and that too started an un-attached window -- is there a way to track this down?

Thanks

 

[Charles Dye]

start "go" /tab /pgm cmd.exe

and that too started an un-attached window -- is there a way to track this down?

That works as expected for me....

 

[fpefpe]

That works as expected for me....

Hello –

Thanks for reply –

The issue seems to be connected with the option

Wow64FsRedirection=Yes

I am running the 32bit version of tcmd in a win7/64bit system. I use a plugin that uses 32bit dll – so that is why I am not using the 64bit version of tcmd

using the options menu this value is set by the option

Win64 File System Redirection –

I assumed that if checked (which set the value in the ini file to “yes” ) means that if you “cd” to

c:\windows\system32

you get the “real” system32 sub-dir -- not sysWOW64 – but this is not the case – is actually “does” the redirection to sysWOW64 – if the option is unchecked (ini value is now “no” ) the “cdd” get you to (the real)

c:\windows\system32

I did a test – I have XPMODE on the system. The command to run the vm is wmwindow.exe which resides in the “real” system32 directory

when the option is unchecked, “Which” locates wmwindow, checked it does not

Now the /tab switch

when redirection is NOT turn on ( option “checked” ) the tab option of start works – otherwise it does not

Thanks for looking at this

 

[Charles Dye]

I am running the 32bit version of tcmd in a win7/64bit system. I use a plugin that uses 32bit dll – so that is why I am not using the 64bit version of tcmd

Which plugin? If it's one of mine, I probably have a 64-bit build available.

 

[fpefpe]

Which plugin? If it's one of mine, I probably have a 64-bit build available.

No -- It's one that I wrote .... It maps a dialect of rexx that is not supported natively by tcmd -- I am going top see if I can move to to regina if possible

I think the question I need to ask is redirection option working as designed?

Thanks again

 

[rconn]

The issue seems to be connected with the option

Wow64FsRedirection=Yes

I am running the 32bit version of tcmd in a win7/64bit system. I use a plugin that uses 32bit dll – so that is why I am not using the 64bit version of tcmd

using the options menu this value is set by the option

Win64 File System Redirection –

I assumed that if checked (which set the value in the ini file to “yes” ) means that if you “cd” to

c:\windows\system32

you get the “real” system32 sub-dir -- not sysWOW64 – but this is not the case – is actually “does” the redirection to sysWOW64 – if the option is unchecked (ini value is now “no” ) the “cdd” get you to (the real)

Not reproducible here. I'm 99.9% sure you've got this backwards (otherwise we'd have hundreds or thousands of reports, not one).

Are you sure you're using the TCMD.INI you think you are? (And note that there are two places where this option is set; one for TCMD and one for TCC.)

 

[fpefpe]

Not reproducible here. I'm 99.9% sure you've got this backwards (otherwise we'd have hundreds or thousands of reports, not one).

Are you sure you're using the TCMD.INI you think you are? (And note that there are two places where this option is set; one for TCMD and one for TCC.)

Hello --

Thanks for the reply --

I have a copy of tcmd.ini in the same directory that tcc.exe and tcmd.exe are in --

Here is my tcmd.ini with the section names and the value of the "wow" setting ( with the other lines removed for this question )

With this setting the "cd" / "which" can't find vmwindows.exe in the system32 directory

[primary]
Wow64FsRedirection=Yes
[Secondary]
[Debugger]
[Watch]
[EnvironmentVariables]
[TakeCommand]
Wow64FsRedirection=Yes
[ListView]
[4NT]
Wow64FsRedirection=Yes