Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

start /tab hangs

D

David Marcus

Jun
789
7
If I do

start /tab /pgm "%_cmdspec"

Take Command hangs and I have to close it. Same if I do

start /tab php C:\Mine\Progs\PriceCheck\Code\Test.php

where php is an alias for "C:\Program Files%@if[%@max[%_wow64,%_x64] == 1, (x86)]\PHP\php.exe".

Strangely, the command did just work once, but is now hanging again. A few times, I've gotten a tab, but with another window on top of the tab. If I try to move the covering window, it moves back to where it was when I release it. Clicking the tab's X makes the covering window go away.

Both commands work fine without "/tab".

TCC 12.10.66 Windows Vista [Version 6.0.6002]. Also tried TCC 12.10.66 x64 Windows 7 [Version 6.1.7601] with the same results.
 
On Wed, 25 May 2011 14:08:17 -0400, David Marcus <> wrote:

|If I do
|
|start /tab /pgm "%_cmdspec"
|
|Take Command hangs and I have to close it.

When I try that, TCMD doesn't hang but the result is rather ugly. The new tab
window is partially created; it's tab contains only the "X"; in the client part
of the tab window there's what looks like a console window ... with empty title
bar ... it can even be dragged away from TCMD (but only a little before it snaps
back). Whatever this window is, it's nearly dead ... doesn't redraw, doesn't
accept input ... but can be closed with the "X" on the tab.
 
On Wed, 25 May 2011 14:54:38 -0400, vefatica <> wrote:

|On Wed, 25 May 2011 14:08:17 -0400, David Marcus <> wrote:
|
||If I do
||
||start /tab /pgm "%_cmdspec"
||
||Take Command hangs and I have to close it.
|
|When I try that, TCMD doesn't hang but the result is rather ugly. The new tab
|window is partially created; it's tab contains only the "X"; in the client part
|of the tab window there's what looks like a console window ... with empty title
|bar ... it can even be dragged away from TCMD (but only a little before it snaps
|back). Whatever this window is, it's nearly dead ... doesn't redraw, doesn't
|accept input ... but can be closed with the "X" on the tab.

And X-ing it (as just mentioned above) leaves a zombie hidden TCC. And
Tab\DetachTab cleans up TCMD but the detached console doesn't become visible; it
can be re-attached but when that's done, it's in the same sorry state described
in my previous post.
 
From: David Marcus
| If I do
|
| start /tab /pgm "%_cmdspec"
|
| Take Command hangs and I have to close it. Same if I do
|
| start /tab php C:\Mine\Progs\PriceCheck\Code\Test.php
|
| where php is an alias for
| "C:\Program Files%@if[%@max[%_wow64,%_x64] == 1, (x86)]\PHP\php.exe".

I presume TCC is running in a TCMD tab when you do this. BTW, the proper format of your alias is "C:\Program Files%@if[%@max[%_wow64,%_x64] == 1, (x86),]\PHP\php.exe" - note the extra comma between the ) and the ]. I would, however, do the definition in TCSTART once, so the test would not be performed each time the alias is executed.

Rex, the user wants to locate the root of the default installation directory tree of 32-bit programs, which is different for Win32 and Win64. Is there a parameter for @SHFOLDER[] to do that? If not, perhaps a new internal variable, e.g., _PROGFILES32, or a new parameter value for @SHFOLDER[] - one not passed directly to a Windows API - could be added in the future.
--
Steve
 
Steve Fabian said:
I would, however, do the definition in TCSTART once, so the test would not be performed each time the alias is executed.
Click to expand...
I've been putting "unalias *" in most of my btm files to avoid accidental conflicts. So, I wanted a way to have some aliases in one place and then use them in various btm files. The choices seemed to be "alias /r" or "call". I've been using the former. The latter might be preferable.
 
From: David Marcus
| I've been putting "unalias *" in most of my btm files to avoid
| accidental conflicts. So, I wanted a way to have some aliases in one
| place and then use them in various btm files. The choices seemed to
| be "alias /r" or "call". I've been using the former. The latter might
| be preferable.

If you use local aliases, your scheme is fine, regardless of which method you use for reloading aliases (though keystroke aliases are sometimes mangled by ALIAS/R). However, if you use global aliases, AND there are times when you have more than one instance of TCC running (e.g., you pipe to a TCC command, batch file or alias), UNALIAS * may inadvertently destroy all of your global aliases, any SETLOCAL commands notwithstanding. One of the possible sequences of events to do that is below, where A and B are two independent TCC instances.

A: setlocal - saves global aliases as of this instant in a place local to A
A: unalias * - deletes all global aliases
B: setlocal - saves the (now empty) table of global aliases in a place local to B
(1) ...
A: endlocal (or quit) - restores global aliases as saved by A above
(2) ...
B: endlocal (or quit) - restores global aliases as saved by B above: empty table!

Notes:
(1) at this point B runs with whatever global aliases are defined by A, not the defaults
(2) at this point B runs with the default aliases
(3) forcible reloading of aliases at the termination of A has the same effect as ENDLOCAL, forcing B to use them for the remainder of its operation
(4) forcible reloading of aliases at the termination of B restores your normal environment, unlike an explicit or implied ENDLOCAL would.

Summary: if it is possible that multiple instances of TCC run concurrently, you should either use only LOCAL aliases, or - as I do - assume the all your aliases are always in effect when coding batch programs, and not play with them; in critical cases you can always force the unmodified internal commands by using the * prefix.
--
HTH, Steve
 
From: rconn
| Steve Fabian:
|| Rex, the user wants to locate the root of the default installation
|| directory tree of 32-bit programs, which is different for Win32 and
|| Win64. Is there a parameter for @SHFOLDER[] to do that?
|
| 42.

That does not work in Win32. I meant a single parameter value which - if Windows uses its default directory structure - returns
"C:\Program Files" in Win32, but
"C:\Program Files (x86)" in Win64
--
Steve
 
Steve Fabian said:
That does not work in Win32. I meant a single parameter value which - if Windows uses its default directory structure - returns "C:\Program Files" in Win32, but "C:\Program Files (x86)" in Win64
Click to expand...

Presumably, if %@SHFOLDER[42] returns nada, you could use the value of %PROGRAMFILES ...?
 
Steve Fabian said:
That does not work in Win32. I meant a single parameter value which - if Windows uses its default directory structure - returns
"C:\Program Files" in Win32, but
"C:\Program Files (x86)" in Win64
Click to expand...
I just tried it on Vista 32 bit and Windows 7 64 bit and it does do that. So, what do you mean it doesn't work?
 
From: David Marcus
| Steve Fabian:
|| That does not work in Win32. I meant a single parameter value which -
|| if Windows uses its default directory structure - returns
|| "C:\Program Files" in Win32, but
|| "C:\Program Files (x86)" in Win64
|
| I just tried it on Vista 32 bit and Windows 7 64 bit and it does do
| that. So, what do you mean it doesn't work?

The value of %@shfolder[42] on my 32-b WinXP SP3 system is an empty string.
--
Steve
 
From: rconn
| Steve Fabian:
|| That does not work in Win32. I meant a single parameter value which -
|| if Windows uses its default directory structure - returns
|| "C:\Program Files" in Win32, but
|| "C:\Program Files (x86)" in Win64

| Windows does not provide an API for that.

That's why I suggested a mechanism within TCC to combine different API calls depending on platform, with a value independent of platform type.

|(Presumably because of the not-unreasonable expectation that it wouldn't be useful.)

That's because MS does not want anyone to use portable code! OTOH TCC users like portability!
--
Stev
 
Steve Fabian said:
From: rconn
|(Presumably because of the not-unreasonable expectation that it wouldn't be useful.)

That's because MS does not want anyone to use portable code! OTOH TCC users like portability!
Click to expand...
Kind of expecting a lot from Microsoft for them to have provided such a thing before they thought of 64 bit. Or, did you want them to add it to XP via a service pack?

But, I don't understand Rex's comment.
 
From: David Marcus
| Steve Fabian:
|| However, if you use global aliases,...
|
| I know. That's the reason I switched to local aliases.
|
|
| Quote:
|| assume the all your aliases are always in effect when coding batch
|| programs, and not play with them
|
| You've never changed an alias? That's impressive.

I change aliases all the time, but not within batch files. On rare occasion a batch file includes an alias which is locally defined and used, but (1) the alias name is always orthogonal to all of my standard aliases, and (2) the implied ENDLOCAL at the termination of the batch file deletes it.

OTOH to assist in the changing of global aliases, I have a small batch file to edit the alias definition files. It first saves the aliases, calls the editor, and if any of the alias definition files changed, loads the new aliases, and displays the list of changes (deletions, additions and modifications). To make the customization for my two systems (laptop and desktop) easy, I have one generic definition file, and one system-specific one for each system. There is also a batch file to load the keystroke aliases (also run when reloading aliases). The alias editing program also synchronizes the laptop and desktop, provided both are connected to my LAN.
--
Steve
 
Well, yes, that's the problem. If you "change aliases all the time", then you are "play[ing] with them". Unfortunately, my memory isn't good enough to remember what aliases I've used in all the btm files I have and to recall if changing a global alias might break something. So, I try to reduce the interconnectedness.
 
From: David Marcus
| From: Steve Fabian
|| From: rconn
||| (Presumably because of the not-unreasonable expectation that it
||| wouldn't be useful.)
||
|| That's because MS does not want anyone to use portable code! OTOH TCC
|| users like portability!
|
| Kind of expecting a lot from Microsoft for them to have provided such
| a thing before they thought of 64 bit. Or, did you want them to add
| it to XP via a service pack?

It would have been just as easy for MS to use a new name for the root directory of 64-b programs, and allow the "C:\Program Files" directory to be used for 32-b programs.

| But, I don't understand Rex's comment.

My interpretation is that MS expects every user to update to the latest version of Windows, even if the one they already have does everything they want to do, and even if it requires new hardware and using the old, perfectly functional system to poison the nearest garbage dump, so that all your systems are identical - hence everything you do is automatically "portable".
--
Steve
 
Steve Fabian said:
It would have been just as easy for MS to use a new name for the root directory of 64-b programs, and allow the "C:\Program Files" directory to be used for 32-b programs.
Click to expand...

That wouldn't completely solve the current problem since I do have some apps that are 32 bit on 32 bit Windows and 64 bit on 64 bit Windows. So, doing it the way you suggest, those would be in different directories. At the moment, there are a lot fewer of those, of course.
 
From: David Marcus
| Well, yes, that's the problem. If you "change aliases all the time",
| then you are "play[ing] with them". Unfortunately, my memory isn't
| good enough to remember what aliases I've used in all the btm files I
| have and to recall if changing a global alias might break something.
| So, I try to reduce the interconnectedness.

When I say "change aliases", under most circumstances it means "add a new one", or - if a in a new version a command has additional options, which I want to make the default - add the option with a condition test for TCC version. I am a great believer in backward compatibility, for the same reason you have: I don't want to screw up 15-year old batch files that I still use unmodified. OTOH if a command or option etc. is no longer available, I am forced to search all my batch files to see what needs to be fixed anyway. Grep and FFIND are your friends there.
--
Steve
 
From: David Marcus
| From: Steve Fabian
|| It would have been just as easy for MS to use a new name for the root
|| directory of 64-b programs, and allow the "C:\Program Files"
|| directory to be used for 32-b programs.
|
| That wouldn't completely solve the current problem since I do have
| some apps that are 32 bit on 32 bit Windows and 64 bit on 64 bit
| Windows. So, doing it the way you suggest, those would be in
| different directories. At the moment, there are a lot fewer of those,
| of course.

Of course not. Just better backward compatibility. However, unless you want to install both the 32b and the 64b version of a program on your Win64 platform, most programs allow you to select the installation path, and you can use the same path on your Win32 system for the 32b version as on your Win64 system for the 64b version, thus allowing you to use the same alias on both. Alternately, you can add the actual path to the MS variable AppPath, and just use the filename - TCC will find it for you!
--
Steve
 
Steve Fabian said:
Alternately, you can add the actual path to the MS variable AppPath, and just use the filename - TCC will find it for you!
Click to expand...
@shfolder solves the problem without having to edit the registry or having to tell lots of programs to install into a different directory than the default.
 
On 2011-05-25 20:08, David Marcus wrote:

> start /tab /pgm "%_cmdspec"
>
> Take Command hangs and I have to close it. Same if I do
>
> start /tab php C:\Mine\Progs\PriceCheck\Code\Test.php
>
> where php is an alias for "C:\Program Files%@if[%@max[%_wow64,%_x64] == 1, (x86)]\PHP\php.exe".
>
> Strangely, the command did just work once, but is now hanging again. A few times, I've gotten a tab, but with another window on top of the tab. If I try to move the covering window, it moves back to where it was when I release it. Clicking the tab's X makes the covering window go away.
>
> Both commands work fine without "/tab".
Click to expand...

Same here, even if you just do "start /tab". A 'blank' console Windows pops up, obscuring Take Command. This is on Windows 7 x64.
 
If I run a btm file containing the two lines

start /tab
start /tab

in TCC 12.10.67 running in a Take Command tab (on Windows Vista [Version 6.0.6002]), I get the strange extra window.
 
rconn said:
But why would you want to do that?
Click to expand...
I'm running an app that takes a while to run. I actually need to run the app twice. I've got a dual-core processor, so running two copies works just fine. So, I thought I'd run them in tabs to keep them out of the way while they run, but so once they finish, I can see if they wrote any error messages, etc. I was starting them manually, but was doing this often, so I wrote a btm file. Thus running into the bug.

My actual btm starts the apps, but I posted the simpler version to demonstrate the problem. My workaround is to not run them in tabs.
 
On Tue, 31 May 2011 16:11:53 -0400, David Marcus <> wrote:

|If I run a btm file containing the two lines
|
|start /tab
|start /tab
|
|in TCC 12.10.67 running in a Take Command tab (on Windows Vista [Version 6.0.6002]), I get the strange extra window.

When I do that I get a total of 4 **new** tabs.
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate