Welcome!

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

SignUp Now!

Clean install - squeaky clean

I have spent some time researching 'clean install' forums and web so I have made a serious effort before posting here.

I have tcmd v 15.1 and I am having a problem going back to default behavior. I use windows professional with all updates. I un-installed tcmd using the control panel, then re-installed using a fresh download of tcmd.
I was astonished to see that all of the problems that I caused by mucking around with options are still there! I feel like this is equivalent to draining your swimming pool, then re-filling it with all the dirt, leaves, and kiddy pee just like it was before. How can I do a "squeaky clean" install of tcmd?
 
Not sure exactly what you're referring to. The TCMD.INI file does not get deleted when you uninstall (this is by user request, as the normal behavior is to uninstall & reinstall, and users didn't want to lose all of their TCMD.INI settings). So if you want a "clean" installation, delete TCMD.INI after uninstalling Take Command.

The only other configuration options (for the TCMD window) are kept in the registry. Look for "HKEY_CURRENT_USER\Software\JP Software".
 
You may want to get TCSTART and TCEXIT as well:

Code:
ren "%_ininame" "%_tcstart" "%_tcexit" *.OLD
exit
 
I want to thank you for your quick reply, deleting what should normally be deleted by removal has given what I wanted. However, since I have had tcmd for some years (ver 8) I want to express my frustration with your product. I wasted more hours than I care to admit dealing with this problem. I have long felt that if the user interface and the documentation was up to snuff; many more people would buy this program. Your company does the equivalent of 'preaching to the choir' and does not properly focus on new users. Ask yourself, how many people who are not in some sort of IT job buy this program? Who could use tcmd from your documentation unless endless hours of tinkering were expended? I am one of those people.

I think it is obvious what I am referring to. tcmd behavior for unstalling is silent (!) and contrary to the English language. See a dictionary for 'remove'. Since your non-standard behavior is silent, I had no way to know that removal in the tcmd universe is not really removal. How was I supposed to know? There is no entry for 'uninstall' in your documentation. I have many programs that have customer modified settings and they post a dialog that says, in effect: "Do you want to keep user settings?". They provide a way to export settings to a file or move them to a 'backup' type folder for installing but I have never seen the 'removal' behavior of tcmd before, and I go back to the days long before Apple and Dos 1.0 when you had to push a button on every bit of the input register to set or clear that bit. I think JPSOFT has not kept up with user interface guidelines.

Still, I wish you well.
 
The problem is that these are all, at least potentially, user-created files. TCStart and TCExit are only user-created; the filenames and locations are not fixed. The .INI file is most often created by the OPTION command, but it too may have been supplied by the user (copied from another installation, made from scratch with a text editor) and it too can live in more than one place. So it's difficult for an automated uninstaller to know what to remove. (Rex could doubtless write his own uninstaller from scratch, but that would scuttle Microsoft certification....)

I personally like to keep all of it -- .INI file, TCStart and TCExit, plugin .DLL files, and other user-created files like Aliases.txt -- in the program's install directory, so removing the directory will get all of it. But that's just my preference; nothing sacred about it.

[Edit:] And yes, it would be a good idea to have a page on uninstallation in the help file.
 
The problem is that these are all, at least potentially, user-created files. TCStart and TCExit are only user-created; the filenames and locations are not fixed. The .INI file is most often created by the OPTION command, but it too may have been supplied by the user (copied from another installation, made from scratch with a text editor) and it too can live in more than one place. So it's difficult for an automated uninstaller to know what to remove. (Rex could doubtless write his own uninstaller from scratch, but that would scuttle Microsoft certification....)

I personally like to keep all of it -- .INI file, TCStart and TCExit, plugin .DLL files, and other user-created files like Aliases.txt -- in the program's install directory, so removing the directory will get all of it. But that's just my preference; nothing sacred about it.

[Edit:] And yes, it would be a good idea to have a page on uninstallation in the help file.

I think that you right in every respect, but you have failed to address the single issue most important issue that I brought up. You already know how to uninstall. You do not need to read the documentation. Signs are for people who do NOT know where they are going. Let me tell a short story (absolutely true in every detail) to illustrate this: I was in a state many miles from my home in a small town. I asked for directions. He told me to "turn right where the barbeque place used to be". It turned out that not only had a fire burned out the barbeque place five years earlier, but another business of entirely different nature was now standing there. His directions were fine for ninety-nine percent of the people who lived in that small town, but were perfectly ridiculous from my point of view. His presumption of knowledge on my part is exactly the same in nature as your presumption of my knowledge concerning the very thing I was asking about. This is circular logic. I would not have enquired about uninstallation if I already knew what you know.
I agree that the flexibility provided is justified. But that is not really the point I wanted the principals at JPSOFT to understand. Just like the guy who presumed that everybody in town has lived there all their life, you presume that everybody knows about this program, and the manual is just used to clarify the fine points of syntax or something of that nature. I use tcmd all the time to manage my shells, but I use cmd and PowerShell for the shells instead of tcc largely because of my frustrations with the manual and lack of examples. Look at the 'Hey Scripting Guy' site at Microsoft if you care to see what you do not provide. Remember that all their stuff is free. I think you are happy to serve your base customers and do not care much about English-Accounting majors like me who do not have an economic reason, like working in IT, to buy the program. I guess I am in the 'Power use' group. It will version 15 forever for me, unless your documentation and ui becomes better than that supplied with the free stuff.
 
I must have missed it. Do CMD and PowerShell have good manuals with lots of examples?
 
Oh, I agree with you that uninstallation deserves some discussion in the docs. No argument there.

However, we'll have to disagree about, in particular, PowerShell's documentation. One of the many things I dislike about that shell is that I find its documentation unhelpful, unenlightening, un-navigable, unreadable, and generally useless. Also, the help system appears to have been written in COBOL by a bored pre-teen who's never seen a real help system. If PowerShell's uninstaller has received more attention than Take Command's has, well, I suspect there's a reason for that....
 
Oh, I agree with you that uninstallation deserves some discussion in the docs. No argument there.

However, we'll have to disagree about, in particular, PowerShell's documentation. One of the many things I dislike about that shell is that I find its documentation unhelpful, unenlightening, un-navigable, unreadable, and generally useless. Also, the help system appears to have been written in COBOL by a bored pre-teen who's never seen a real help system. If PowerShell's uninstaller has received more attention than Take Command's has, well, I suspect there's a reason for that....

This is a 'straw man' argument, setup to divert attention to an off-subject topic so you can knock it down. The subject is the documentation for Tcmd. Also, you compare your work to a free product. Is it not reasonable to expect better work from a product that is paid for? I suggest the documentation for the EmEditor as an example of good documentation. You can download a free version if you care to.
I must have missed it. Do CMD and PowerShell have good manuals with lots of examples?
I think you did miss something. If you were at the Chevrolet dealer complaining about the air conditioning; would you accept "well, it works better than the air conditioning in a Yugo!" as a relevant answer? I think you would demand what you paid for, not what you did not pay for.

I would loath to compare my own work to free products or products with a poor reputation. Instead, I would compare my work to the best I could find, and see how I measure up.
 
Tristram, in the many years I have played with computers there are several things I've learned. The number one thing is always back check any uninstall. I have paid for many a program that does no totally uninstall. If you don't know this I would expect to find a lot of garbage on your system.

As to the documentation Rex does a good job though I to agree he like many others needs to to include a uninstall section in the help file. (Though I wouldn't fault his program because it's not there.) Other than that and very few other exceptions I find the Take Command documentation as good or better than most I've seen in the scripting world.
 
When you look at the help files of other products (AutoIt, xHarbour and PowerBASIC are three that come to mind), then the TCMD Help file is sorely lacking.

For example, each help topic should have the following sections;
Code:
Parameters
Return Value
Remarks
Related
See Also
Example

The example section should provide one or more examples of how to use the command/function/variable.

It should also have a button that you can click on [Open this Script] that will open the example script into the Take Command IDE.

Maybe I have been spoiled by the AutoIt, xHarbour and PowerBASIC help file(s), but that is the way help files should be designed.

Joe
 
I actually really like powershell's documentation.

Get-Help Command -Full

If you are new to powershell it can be a bit confusing though.
 

Similar threads

Back
Top