How to? User specific TCSTART (etc) files

[p.f.moore]

If I'm reading the documentation correctly, assuming no command line options are specified, TCC looks for TCMD.INI in the program directory or %LOCALAPPDATA%. From there, it finds the other files it needs (TCSTART, TCEXIT) either via INI directives, or by looking alongside the executable. But there is no way to locate TCSTART alongside the INI file, i.e. in %LOCALAPPDATA% (or in any other user-specific location) without hard-coding the path (and hence the specific user ID).

I can't use environment variables in TCMD.INI. I could have a TCSTART.BTM in the program directory that invokes %LOCALAPPDATA%\JPSoft\TCSTART.BTM, but I am trying to avoid putting anything in the program directory, for both backup reasons and because doing so needs elevation. Also doing so would be potentially confusing, because it would ignore alternative file extensions.

Have I missed a way of having all of my TCC startup files in a per-user location, such that the files do not need to hard-code the location path (reference via environment variables is fine) and I don't have to require specific command line parameters? I'm surprised it is not easier to do this, given the increased lockdown of the Program Files directory in recent versions of Windows.

I'm currently testing this in TCC/LE 13, but if there's a solution in TCC 16, that's fine too as I'm looking at this as part of deciding whether or not to switch back to TCC (I've been using powershell for a while) so getting the upgrade is an option.

Paul

 

[Steve Fabian]

There are default locations on a per-user AND a per-installation basis, but I have NONE of mine there. I explicitly specify the full path of both the executable and of the .INI file. These do not need to conform to any naming rules (except the program should have extension .EXE). In turn, the .INI file allows explicit specification of the path of the TCSTART file; its name is fixed: TCSTART.EXE. The syntax is:

drive:\path\tcc.exe /@drive:\path\filename.ext
or
drive:\path\tmd.exe /@drive:\path\filename.ext

Beware!
1/ TCMD and TCC have different, independently specified .INI files
2/ If you start TCMD, by default it starts the same version of TCC with the default location for its .INI file. The [Tabn] sections of the TCMD.INI can be used to specify what program and how and where to start the console programs which provide TCMD's power. For each console tab you can specify the start directory and the start command line, just like the TCC above.

 

[p.f.moore]

Thanks, Steve. I want to avoid using explicit specification of the ini filename, because I frequently start thee command processor "by hand" (tcc.exe in a run-style box) and having to remember to add @path would be a pain. Also, I move my settings between accounts on occasion, so having a "portable" self-contained setup saves me having to do a lot of messy file editing when I do.

You say that there are default locations on a per-user and a per-installation basis. I know about the ones for the ini file, but are there per-user default locations for TCSTART/TCEXIT as well? I couldn't find them mentioned in the documentation - could you give me a pointer? Thanks.

 

[djspits]

You're almost there. The only way NOT to specify the TCMD.INI location is by putting it in a default location. In fact, you can put your TCSTART anywhere you like. You only need to set your TCStartPath ini-directive to the right path. If TCMD.INI is on %LOCALAPPDATA then it is already in a per-user location.

If you move to a different account it has a fresh %LOCALAPPDATA location with no TCMD.INI and hence no TCStartPath value. If your startup files and source lib are in a central location you can reuse them. You do have to write the ini however, once for every account that you use. If you use a portable version of TC then you can write a batch to do even that automatically.

Cheers, DJ

 

[p.f.moore]

I don't think I'm being quite clear enough. What I want is to have my "profile" (for want of a better word) all in one location - %LOCALAPPDATA% is fine, but not necessary (it's a good choice because it's the only place outside of the application directory that TCC looks for the ini file without needing customised command line arguments). In that directory I want to keep my ini file and TCSTART/TCEXIT, and any files that are used to support those two. The reason for this is so that I can keep my profile under version control, on somewhere like github.

That's easy enough, by setting TCStartPath. But critically, I want to not have hard-coded paths anywhere, so that my profile is portable. Otherwise I have to modify my ini file after each checkout (or use the same absolute path for every checkout). That doesn't seem to be possible, as TCStartPath appears not to be able to use relative filenames, nor can it use environment variables.

The only remaining option I can see is to use TCC in portable mode. That's not ideal, though, as it puts the "profile" and the application in the same location (which again makes version controlling my profile scripts a problem.

Thanks for the comments, though - I'd forgotten about portable mode (even though it's not quite what I want).

Paul

 

[Steve Fabian]

Obviously we have quite different uses for TCC. I have several custom .INI files each with a unique TCStartPath to perform special applications. For generic use I try to minimize differences. Also, I do not want the vagaries of differing Windows nomenclatures when specifying directories for the same use to effect my operations. I want MY files always in the same place, no matter which version of Windows. Windows versions come and go, with no thought to people doing the same jobs as last year and the year before. So I use a semiautomated process to install user-transparent hotkeys.

TCStartPath specifies a directory where the TCSTART program is sought. This path obeys the usual rules of path building - whether or not drive is specified, absolute v. relative path, etc. Always based on the directory specified in either the shortcut (.LNK) file, or with the /D option of the START command of TCC.

As to the flexibility of no hard coded paths, my solution is simple. I have only ONE master path. All other paths are relative to that master path. The master path is one hierarchy level up from the location of TCSTART.BTM. This works equally well from a USB drive (whose drive letter is variable) as from the C\ drive.

 

[djspits]

Having a single set of startup files in a central location is sensible thing to strive for. It does have its drawbacks though, but in this case at least vctrl is made easy.

Assuming the reliable availability of your central storage location, for you to be able to use that set from multiple machines and/or multiple accounts, all your copies of TCMD.INI must point to the same central location. That is, all TCStartPath entries must be identical, so there is no need for relative entries or variables in the entry values.

However, the tcmd.ini cannot be a part of that profile itself. TCMD looks for them only in standard locations, unless you specify an alternate location. Again, if you put the alternate location in a lnk-file, as Steve suggested, IMHO your objection seems to go away.

But, if you don't want to use that solution, there is another way out of this paradox. If you're interested,..

DJ

 

[Steve Fabian]

Back to the world of time-shared systems... Why bother with personal computers?

 

[p.f.moore]

I'm afraid I'm baffled and somewhat frustrated. I don't seem to be explaining the constraints/limitations of my environment very well, as the suggestions seem to be aimed at something very different from my environment. The technical details are helpful, and thanks for them, but they don't really apply for me.

Let me try two options. First I'll explain what I (think I) must have, non-negotiable. This to be assumed as essential requirements, no matter how "silly" they seem. The question here is simply "is this possible?" An answer of "No" is fine, although "almost, but you need to do X and Y that violate your requirements" is acceptable (and obviously "Yes" is perfect :)). After that, I'll try to explain the constraints that lead me to believe I need what I do - maybe someone will see an alternative approach that fits those constraints. That would be great, but I have been trying to do this (for multiple applications) for many years, so I'm not hopeful...

OK. What I need:

1. My configuration files (INI, TCSTART, TCEXIT, any bat files called by these) all in a single directory
2. No absolute reference to the location of that directory, other than via an environment variable (preferably a system one like LOCALAPPDATA, but one that I set once in the system environment variables would be OK).
3. The files should not be in the program directory.

This would all be relatively simple if TCMD.INI allowed TCStartPath to use environment variables or relative filenames. My "almost there" solution will be to hard-code the pathname in TCMD.INI and edit it on each environment. This is not a one-off edit, unfortunately, as replicating changes (see below) will replicate the TCStartPath setting, unfortunately, so it'll be an edit on every settings change. That's the real reason I'm resisting doing this.

I'm not sure I see how LNK files help, as they can't use relative filenames or environment variables in their definition.

And why I need this:

1. I work on multiple machines (never less than 2, sometimes as many as 4), which have no shared storage, not even a USB drive (I'm notorious for forgetting to bring my USB stick with me between environments).
2. Machines do not have a common storage layout (my work PC has at times required me to store all my data on the D drive, and at other times only had a C drive...)
3. As is hinted at by the above, rebuilds and hence reinstalls are sufficiently frequent that streamlining the install process is important to me.
4. I want to synchronise my working environment between the various PCs so that things like my common aliases are available everywhere.
5. My preferred tool for synchronisation is a distributed VCS, either git (using github as central storage) or Mercurial (with bitbucket). My machines do all have access to github/bitbucket. They don't have access to "shared disk" services like dropbox.
6. I do edit my configuration fairly frequently - both things in the INI file and stuff in TCSTART.
7. I run TCC in multiple ways (command line, shortcut, run-box type applications, from other code) so having to specify a particular command argument would be error-prone and probably impractical.

The impression I'm getting is that TCStartPath does have to be a hard-coded absolute location and that's the end of it. I won't be able to make my config fully relocatable, so I need to look outside of TCC for a way to avoid trashing TCStartPath whenever I resync my config. Is that a fair summary?

Paul

 

[Steve Fabian]

Question 1: Is it possible for all of your machines to have an identically named subdirectory, in which to store your work files?

Question 2: Is it permissible to have a program run when you first start that sets up the operational environment for all subsequent operations? (Whole environment, not environment variables.)

 

[thorsten]

I have very similar requirements to yours and I'm using this set-up since 2005:
1. Synchronization does not work. You will spend too much time synchronizing or troubleshooting why some files weren't synchronized

2. Thus you need either a shared, central location (network share, DropBox) or a USB drive. Dropbox is not an option because you can't run files from there, and network shares are not always accessible or available.

3. So the only option left is a USB drive. The only way not to forget your thumb drive at home or losing it is by wearing it around your neck. If you put it in your wallet, your key ring or whatever you will lose or forget it.

4. you will find out that it makes sense not only to put configuration files but also binaries on your drive and run in from there. Despite common believes, quality USB thumb drives (Sandisk) will not wear out from writing. I have been using thumb drives for years, running 90% of all my applications from them, for ten or fifteen hours per day.

5. put alll ini and btm start files in Take Command's program directory. Try to use absolute paths without the drive ("\program files\take command" for instance) where ever you can.

6. use a launcher like PStart to run your applications

 

[p.f.moore]

Question 1: Is it possible for all of your machines to have an identically named subdirectory, in which to store your work files?

Question 2: Is it permissible to have a program run when you first start that sets up the operational environment for all subsequent operations? (Whole environment, not environment variables.)

Answer 1: No. As I say, on at least one occasion I've had to work on a machine with only a D drive I had access to. And some of my machines have only a C drive.
Answer 2: Yes, but I'd question what you mean by "have a program run" and "when you first start". Assuming you mean automatically run something on boot-up, then yes, it's permissible. But I don't see where you're going with this (scripted editing of a file would need to be rerun after I sync, for instance - and I bet I forget :-)) If you mean manually run whenever I start TCC then it's permissible, but I see no point - I might as well just replace TCSTART with something I run manually in that case.

Paul

 

[p.f.moore]

I have very similar requirements to yours and I'm using this set-up since 2005:
1. Synchronization does not work. You will spend too much time synchronizing or troubleshooting why some files weren't synchronized

2. Thus you need either a shared, central location (network share, DropBox) or a USB drive. Dropbox is not an option because you can't run files from there, and network shares are not always accessible or available.

3. So the only option left is a USB drive. The only way not to forget your thumb drive at home or losing it is by wearing it around your neck. If you put it in your wallet, your key ring or whatever you will lose or forget it.

4. you will find out that it makes sense not only to put configuration files but also binaries on your drive and run in from there. Despite common believes, quality USB thumb drives (Sandisk) will not wear out from writing. I have been using thumb drives for years, running 90% of all my applications from them, for ten or fifteen hours per day.

5. put alll ini and btm start files in Take Command's program directory. Try to use absolute paths without the drive ("\program files\take command" for instance) where ever you can.

6. use a launcher like PStart to run your applications

Sync using github has always worked fine for me. The only problem I've ever had is with programs that don't make it easy to write relocatable configurations. I know from experience that USB drives don't work for me. Apart from me forgetting, I've had PCs with insufficient USB ports, as well as PCs where I'm not allowed to plug in a USB drive. I have a portable setup as a fallback, but I cannot rely on it as my only working environment.

This feels like it's a lost cause. As I've said, the only blocker is the need for an absolute path for TCStartPath. And I don't expect this to be something that changes soon, given that it's been like this for 16 releases now. So I think I'll look for a solution external to TCC - git post-checkout hooks or something. Or just not bother. It all feels a bit like too much hard work for the benefit.

Thanks to all for the help and information, though.
Paul

 

[Steve Fabian]

Answer 1: No. As I say, on at least one occasion I've had to work on a machine with only a D drive I had access to. And some of my machines have only a C drive.

Sorry, my question was misunderstood. Restated, I ask if your environment can have a subdirectory hierarchy with a fixed set of names, even though the higher levels are different. For example, could you put all of your JPsoft-related files in a tree named JPSOFT, with different access paths. I have C:\JPSOFT and F:\JPSOFT on hard drives, and x:\_ROOT\JPSOFT on USB drives, where x: depends on which USB slot is used.

Sync using github has always worked fine for me. The only problem I've ever had is with programs that don't make it easy to write relocatable configurations. I know from experience that USB drives don't work for me. Apart from me forgetting, I've had PCs with insufficient USB ports, as well as PCs where I'm not allowed to plug in a USB drive. I have a portable setup as a fallback, but I cannot rely on it as my only working environment.

For insufficient USB ports the simple solution is a USB hub. Under $20 for a 7-port hub, with its own power. For lack of permission to use USB devices there is no cure. I had to work for customers who permitted no external device to be attached, too - as a consultant. Network security prevailed over network functionality.

This feels like it's a lost cause. As I've said, the only blocker is the need for an absolute path for TCStartPath. And I don't expect this to be something that changes soon, given that it's been like this for 16 releases now. So I think I'll look for a solution external to TCC - git post-checkout hooks or something. Or just not bother. It all feels a bit like too much hard work for the benefit.
l

As I wrote, TCStartPath need not be absolute, it may be relative - but you need to know its relationship to the start directory of TCC. In all my usage they are the same directory, so the directive TCStartPath=. works.

Another alternative is not to use TCStartPath (or more generally not to have a file named TCSTART), instead, make an explicit MYSTART.BTM file; it can be specified e.g. using system-level environment variables.

 

[p.f.moore]

Sorry, my question was misunderstood. Restated, I ask if your environment can have a subdirectory hierarchy with a fixed set of names, even though the higher levels are different.

Ah, I see. Yes, that would be possible. Would I need the software installed under that hierarchy as well? That's less ideal, but still possible - I just prefer to separate config and executables.

As I wrote, TCStartPath need not be absolute, it may be relative - but you need to know its relationship to the start directory of TCC. In all my usage they are the same directory, so the directive TCStartPath=. works.

Oh! I think I see - you mean relative to the working directory when I start TCC. I just checked, and that works - although it's not really helpful to me, as I start subshells from all sorts of directories while I'm working, so the startup working directory is essentially random. (I can see it'd be useful if you started TCC from a link every time, though).

Another alternative is not to use TCStartPath (or more generally not to have a file named TCSTART), instead, make an explicit MYSTART.BTM file; it can be specified e.g. using system-level environment variables.

But unless I'm missing something, I'd need to run MYSTART manually whenever I started a shell? Certainly doable, but not really what I'm after.

Thanks again - I think I've found a solution external to TCC, so this is mostly theoretical now, but interesting nevertheless.

 

[Steve Fabian]

You can still separate code and data - into different subtrees under the umbrella of the main one.