ini files and making all settings "relative"

[Sir_SiLvA]

Seems this is not my day, first my tests were incomplete and I made a public fool of myself, sniff

Sorry was never my intention - all I wanted to show was how Env-Vars are Handled (at least >W2k)...

I guess I had better jump out of the cellar window asap.

If you do so plz make a movie of it

Think positiv it could have been worse...
Perhaps tomorrow is your day (ups... is that a monday?...)

[Hacker]

karlchen,

Removed the offending color tags.

Thanks, much better.

Hacker (Moderator)

[karlchen]

Hi, Sir_Silva.

I have no idea which os you use, but at xp with sp2 you are 100% wrong...

WinXP Prof Sp1 German.

You are right about cmd.exe. I was using 4NT V5.0. And 4NT.EXE interprets %COMMANDER_PATH% as an empty string, because it has not been defined.
How undefined variables are interpreted by a shell is more a matter of convention than a matter of bugs. Or are you seriously suggesting that 4NT is buggy because it treats an undefined variable as an empty string? (Edit 21.02.2005: I tend to plead that the most logical reaction would be to reject undefined variables under all circumstances thus revealing typing errors?!)
But you cannot be completely right about cmd.exe. It behaves as you say on the command line.
Yet inside batch files this works as I expect it:
if "%_4ver%"=="" goto CMDEXE
_4ver is undefined outside 4NT, and inside a batchfile cmd.exe says that "%_4ver%"="", not that "%_4ver%"="%_4ver%".
And inside a batchfile the command echo "%_4ver%" writes two double quotes on the screen, not "%_4ver%".
So, cmd.exe seems to be not too consistent in its way of treating undefined variables.
(Yet, this is definetely too far offtopic now, so I suggest to postpone it to another Sunday afternoon when my girl friend is out to work.)

can say you are only 95% wrong

Hm, I do not really believe that 5% of all Windows users use 4NT, the percentage is probably much lower.
But very likely the Win98 users will increase my percentage to 5%.

you're starting TC allways with typing in a dosbox

Nope, just when I am trying out different command line parameters. Else I launch it from the Windos Quick Launch Bar and most programmes from inside TC.

So, I correct what I learnt today:
+ Some newer Windows implementations do not try to expand undefined variables, but pass them to a programme unmodified.
+ This is true for Explorer as well as cmd.exe (for cmd.exe partially).
+ 4NT is not a Microsoft programme and may not conform to Microsoft conventions under all circumstances.
+ Edit 21.02.2005: Si tacuisses philosophos mansises or something like that, anyway, trying to prove other people are doing something in a wrong way without thorough testing will only prove what a fool I am myself
+ I must not use color formatting in this forum.

Regards,
Karl
--
Gone downstairs to the cellar and about to jump out of that window ...

[karlchen]

Ok, after we have spent a lot of posts on side issues and special cases like the TC ini-files being in the %COMMANDER_PATH% - yes, I know, my fault - perhaps we might come back to the initial issue in ebone's message and give a concise, commonly usable anser?

Here is my attempt to keep it concise:

ebone's first question was,

I'm having trouble getting totalcmd.exe /i=myinifile.ini to work.

Answer:
Add a valid path specification to the "/i=" parameter.
Common form: /I="<drive>:\<path to the ini-file>\myinifile.ini".
If your ini-file resides in the TC programme directory, you may also try this form: /I="%COMMANDER_PATH%\myinifile.ini"
Note:
%COMMANDER_PATH% will not work on older Windows versions and on TC versions prior to 6.x.

ebone's second question was,

Is it possible to alter TC's ini file to make the paths "relative" (a subfolder of the TC folder)

Starting with V6.x, the TC variable COMMANDER_PATH points to the TC programme directory. You may modify path specifications in your INI-files to reference %COMMANDER_PATH%.
Starting with V6.5x TC knows a number of additonal path variables which you may find in this message by ICFU

Kind regards,
Karl

[Sir_SiLvA]

How undefined variables are interpreted by a shell is more a matter of convention than a matter of bugs. Or are you seriously suggesting that most *nix shells are buggy because they treat an undefined variable as an empty string?

If any shell translates a call like "programm %Param%" to "programm """ , yes than that shell has imho a bug

Sorry but if "%Param%"=="" <Do Something> [1] is something
completly different than Programm %Param% [2] plz don't mixed that!

in [1] the System MUST resolve %Param% if it resolves %Param% (which is empty) in [2] its a bug !...

try my demo %Commander_Path% (which is empty) is not resolved by Windows
but ie %temp% (which is not empty) is resolved...
I hope you see and understand the importance of this difference

[ghisler(Author)]

OK, let's make this clear:
/i=wincmd.ini

Will make TC look in the WINDOWS directory.

/i=.\wincmd.ini

Will make TC look in the PROGRAM directory. This is special, TC converts the .\ to the program dir at startup.

/i=\wincmd.ini

Should be avoided - makes look TC in the root of the current drive, so if you switch to another drive, TC will look in the wrong directory!