Several nitpicks and a crash in TCMD 11 x64 / Windows 7

[Juanma Barranquero]

C:\> ver /r

TCC 11,00,32 x64 Windows 7 [Version 6,1,7600]
TCC Build 32 Windows 7 Build 7600


- Missing feature #1 (and quite annoying): if the "TCSTART / TCEXIT Path" option is not set, TCC does not run a tcstart.btm file, unless there's a matching tcstart.btm program "in the same directory as your command processor". However, on Vista / W7 it would be better to check also (or instead) at %LOCALAPPDATA%\JPSoft, I think.

- Missing feature #2: the "TCSTART / TCEXIT Path" option does not support environment var expansion. It would be natural to set it to %LOCALAPPDATA%\JPSoft, but instead of that I have to set it to "C:\Users\MyUserName\AppData\Local\JPSoft". But the whole point of the *APPDATA variables is avoiding the need to specify these things in full.

- Bug: In fact, if you *set* it to %LOCALAPPDATA%\JPSoft, you get an error on restart:

Error on line 166 of C:\Users\MyUserName\AppData\Local\JPSoft\TCMD.INI:
     Invalid Path or file name for "TCStartPath"
Press any key when ready...
Error on line 173 of C:\Users\MyUserName\AppData\Local\JPSoft\TCMD.INI:
     Invalid path or file name for "4StartPath"
Press any key when ready...

and then, if you click on "Options / Configure TCC...", TCMD crashes.

BTW, missing feature #2 and the bug also apply to the TreePath option.

 

[rconn]

C:\> ver /r

- Bug: In fact, if you *set* it to %LOCALAPPDATA%\JPSoft, you get an error on restart:

Error on line 166 of C:\Users\MyUserName\AppData\Local\JPSoft\TCMD.INI:
     Invalid Path or file name for "TCStartPath"
Press any key when ready...
Error on line 173 of C:\Users\MyUserName\AppData\Local\JPSoft\TCMD.INI:
     Invalid path or file name for "4StartPath"
Press any key when ready...

and then, if you click on "Options / Configure TCC...", TCMD crashes.

BTW, missing feature #2 and the bug also apply to the TreePath option.

Not a bug; the .INI parser does not do variable expansion (and never has).

 

[Charles Dye]

- Missing feature #1 (and quite annoying): if the "TCSTART / TCEXIT Path" option is not set, TCC does not run a tcstart.btm file, unless there's a matching tcstart.btm program "in the same directory as your command processor". However, on Vista / W7 it would be better to check also (or instead) at %LOCALAPPDATA%\JPSoft, I think.

Unless and until Rex implements this, you can fake it by creating a short TCSTART.BTM in the Take Command program directory:

@echo off
if exist "%localappdata\jpsoft\tcstart.btm" call "%localappdata\jpsoft\tcstart.btm"

And similarly for TCEXIT, if you wish.

 

[Juanma Barranquero]

Not a bug; the .INI parser does not do variable expansion (and never has).

I wrote "missing feature" twice because I know it does not work (though it would be useful if it did, so consider it as a feature request).

But it's hard to dismiss the crash as other than a bug. Wrong input or setup shouldn't crash TCMD.

 

[Juanma Barranquero]

Unless and until Rex implements this, you can fake it by creating a short TCSTART.BTM in the Take Command program directory:

@echo off
if exist "%localappdata\jpsoft\tcstart.btm" call "%localappdata\jpsoft\tcstart.btm"

And similarly for TCEXIT, if you wish.

I had resorted to using hardcoded PATHs instead of %LOCALAPPDATA%, but your idea is better. Thanks.

 

[Fross]

Re: Several nitpicks and a crash in TCMD 11 x64 / Windows 7

I'm not sure if you need a second for the feature request list, but I'd love
to see variable expansion in the INI file processing. I like to use the
same config files on multiple machines and being able to use environment
variables would really be useful.

Michael


On Tue, Dec 8, 2009 at 11:01 PM, Juanma Barranquero
<>wrote:

> Quote:
> Originally Posted by *Charles Dye* [image: View Post]<http://showthread.php?p=8101#post8101>
> Unless and until Rex implements this, you can fake it by creating a short
> TCSTART.BTM in the Take Command program directory:
>
> Code:
>
> @echo off
> if exist "%localappdata\jpsoft\tcstart.btm" call "%localappdata\jpsoft\tcstart.btm"
>
> And similarly for TCEXIT, if you wish.
> I had resorted to using hardcoded PATHs instead of %LOCALAPPDATA%, but
> your idea is better. Thanks.
>
>
>

 

[rconn]

> ---Quote (Originally by rconn)---
> Not a bug; the .INI parser does not do variable expansion (and never
> has).
> ---End Quote---
> I wrote "missing feature" twice because I know it does not work (though
> it would be useful if it did, so consider it as a feature request).
>
> But it's hard to dismiss the crash as other than a bug. Wrong input or
> setup shouldn't crash TCMD.

I cannot duplicate the crash. Do you have a TCMD.GPF file?

Rex Conn
JP Software

 

[rconn]

Re: Several nitpicks and a crash in TCMD 11 x64 / Windows 7

> I'm not sure if you need a second for the feature request list, but I'd
> love
> to see variable expansion in the INI file processing. I like to use
> the
> same config files on multiple machines and being able to use
> environment variables would really be useful.

The problem is that it would break existing .INI files that expect expansion
to be done later, not when TCMD.INI is being parsed at startup.

Rex Conn
JP Software

 

[Steve Fabian]

Re: Several nitpicks and a crash in TCMD 11 x64 / Windows 7

Rex Conn wrote:
| ---Quote---
|| I'm not sure if you need a second for the feature request list, but
|| I'd love to see variable expansion in the INI file processing. I
|| like to use the same config files on multiple machines and being able
|| to use environment variables would really be useful.
| ---End Quote---
|
| The problem is that it would break existing .INI files that expect
| expansion to be done later, not when TCMD.INI is being parsed at
| startup.

No, it would not break backward compatibility, because existing files
cannot contain variables to be expanded.

Similarly, I'd like to see .INI file expansion to accept relative
paths, as they did in earlier versions of 4NT.EXE, and even 4DOS.COM.
In the old versions a directive like

include .\V06.INI

worked to include the file V06.INI located in the directory where 4NT
was started, regardless of the location of 4nt.exe.

A similar request arises for the "TCMD on a stick" case. Since the
drive letter of where TCMD or TCC starts cannot be predicted, and the
AUTORUN scheme does not provide control of the start-up directory, it
would be desirable to allow a new command-line option in the command
which starts TCC.EXE or TCMD.EXE - a copy of the /D option of the
START command of TCC. This option should accept paths that relative
paths, either based on the root directory of the stick, or on the
directory where the program itself is.
--
Steve

 

[Juanma Barranquero]

I cannot duplicate the crash. Do you have a TCMD.GPF file?

AFAICS, no TCMD.GPF file is being generated (at least, I don't see one on the TCMD directory).

However, the Windows crash reporter pops up and sends info to Microsoft. I could send you a copy of the crash files it generates (a 2MB crash dump and a couple small XML files).

To me, the bug is perfectly repeatable, BTW.

 

[Charles Dye]

I had resorted to using hardcoded PATHs instead of %LOCALAPPDATA%, but your idea is better. Thanks.

On second thought, %@SHFOLDER[26] might be better, unless LE compatibility is an issue.

 

[rconn]

Re: Several nitpicks and a crash in TCMD 11 x64 / Windows 7

> Rex Conn wrote:
> | ---Quote---
> || I'm not sure if you need a second for the feature request list, but
> || I'd love to see variable expansion in the INI file processing. I
> || like to use the same config files on multiple machines and being
> able
> || to use environment variables would really be useful.
> | ---End Quote---
> |
> | The problem is that it would break existing .INI files that expect
> | expansion to be done later, not when TCMD.INI is being parsed at
> | startup.
>
> No, it would not break backward compatibility, because existing files
> cannot contain variables to be expanded.

Not true -- the variables just cannot be expanded at startup time. Anything
that is parsed later (like DirColor) would break.

> Similarly, I'd like to see .INI file expansion to accept relative
> paths, as they did in earlier versions of 4NT.EXE, and even 4DOS.COM.
> In the old versions a directive like
>
> include .\V06.INI
>
> worked to include the file V06.INI located in the directory where 4NT
> was started, regardless of the location of 4nt.exe.

That cannot be done (because at startup the relative directory is *not*
where you think it is).

Rex Conn
JP Software

 

[Jim Cook]

Re: Several nitpicks and a crash in TCMD 11 x64 / Windows 7

> || I'm not sure if you need a second for the feature request list, but
> || I'd love to see variable expansion in the INI file processing. *I

> | The problem is that it would break existing .INI files that expect

> No, it would not break backward compatibility, because existing files
> cannot contain variables to be expanded.

It might break my INI file because it expects that the INI line will
be processed without expansion.

My specific case is a button:
B1=0,,4nt11,D:\,C:\4NT11\TCC.EXE /K `alias foo %@alias[foo] /R:?7`

--
Jim Cook
2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Sunday.

 

[Steve Fabian]

Re: Several nitpicks and a crash in TCMD 11 x64 / Windows 7

rconn wrote:
| Not true -- the variables just cannot be expanded at startup time.
| Anything that is parsed later (like DirColor) would break.

How about parsing variables only in directives which specify paths?

| ---Quote---
|| Similarly, I'd like to see .INI file expansion to accept relative
|| paths, as they did in earlier versions of 4NT.EXE, and even
|| 4DOS.COM. In the old versions a directive like
||
|| include .\V06.INI
||
|| worked to include the file V06.INI located in the directory where
|| 4NT was started, regardless of the location of 4nt.exe.
| ---End Quote---
| That cannot be done (because at startup the relative directory is
| *not* where you think it is).

OK, is there a way to specify paths that are independent of which drive TC
runs from? I've lately been trying the instance started by AUTORUN to use
the START command to bring up the working instance, but have not developed
that approach to be really robust.
--
Steve

 

[rconn]

Re: Several nitpicks and a crash in TCMD 11 x64 / Windows 7

> rconn wrote:
> | Not true -- the variables just cannot be expanded at startup time.
> | Anything that is parsed later (like DirColor) would break.
>
> How about parsing variables only in directives which specify paths?

Not without rewriting the command parser and .INI parser -- .INI parsing is
done (has to be done) before the rest of TCC is initialized, so the command
parser & variable expansion is not yet operative. I'd have to add a third
parser to handle preprocessing .INI directives, which would be (1) sizeable,
and (2) slow. (Vince will go berserk if the startup time increases
significantly.)

> | ---Quote---
> || Similarly, I'd like to see .INI file expansion to accept relative
> || paths, as they did in earlier versions of 4NT.EXE, and even
> || 4DOS.COM. In the old versions a directive like
> ||
> || include .\V06.INI
> ||
> || worked to include the file V06.INI located in the directory where
> || 4NT was started, regardless of the location of 4nt.exe.
> | ---End Quote---
> | That cannot be done (because at startup the relative directory is
> | *not* where you think it is).
>
> OK, is there a way to specify paths that are independent of which drive
> TC runs from? I've lately been trying the instance started by AUTORUN to
> use the START command to bring up the working instance, but have not
> developed that approach to be really robust.

I (still) don't understand why it's a problem to enter the full path, which
avoids all confusion.

Rex Conn
JP Software

 

[Steve Fabian]

Re: Several nitpicks and a crash in TCMD 11 x64 / Windows 7

rconn wrote:
| Not without rewriting the command parser and .INI parser -- .INI
| parsing is done (has to be done) before the rest of TCC is
| initialized, so the command parser & variable expansion is not yet
| operative. I'd have to add a third parser to handle preprocessing
| .INI directives, which would be (1) sizeable, and (2) slow. (Vince
| will go berserk if the startup time increases significantly.)

OK.

| I (still) don't understand why it's a problem to enter the full
| path, which avoids all confusion.

Because it is not constant. When you use the "inikey" version, it may
be drive D: or E: or J: etc. Similar issue (though much easier to
overcome) if you reorganize your system, and all of a sudden the
command processor and the initialization files are in a different
directory. I could possibly create essentially duplicated files, one
for each potential drive letter, but the issue would not be solved -
the command starting TC would still need to know which drive holds
the .INI files.

I presume that directory aliases are also unavailable during
directive processing.

Would paths which are relative to the root of the current drive work
in directives? E.g.:

TCStartPath=\__root\jpsoft

--
Steve

 

[rconn]

Re: Several nitpicks and a crash in TCMD 11 x64 / Windows 7

> I presume that directory aliases are also unavailable during
> directive processing.

Right -- since the alias storage and options are defined in TCMD.INI.

> Would paths which are relative to the root of the current drive work
> in directives? E.g.:
>
> TCStartPath=\__root\jpsoft

Yes.

Rex Conn
JP Software

 

[dim]

Re: Several nitpicks and a crash in TCMD 11 x64 / Windows 7

On 2009-12-09 17:22, rconn wrote:

> I (still) don't understand why it's a problem to enter the full path, which
> avoids all confusion.

At least for me, the reason is that I put my Take Command startup files
(tcmd.ini, tcstart/exit.btm, aliases and so on) in Subversion, to be
able to easily reuse them in different situations.

However, if the path to your profile differs, you still need to edit at
least the tcmd.ini file to fix the TCStartPath and/or 4StartPath
directives.

In my tcstart.btm I already use the construction:

alias /r "%@ShFolder[28]\JPSoft\Alias.txt"

to read my aliases file from the 'local app data' JPSoft folder.