Uninstall script broke my Terminal

[txgraeme]

Hello, I'm having a problem with my terminal app and hoping people here can offer some advice. I bought one of those USB wifi dongles, had to find the driver files online and accidentally tried the wrong one at one point. The uninstall script for the driver has an unfortunate persistent effect and now each time I need to use the terminal it tries to run the uninstall script and exit the shell window. ('New Command' still works, but also appends the uninstall script before running any input command).

Here's the entire thing (after clicking on Terminal.app):


I've tried switching shell types and restarting, no change. When I try to edit the shell opening script, I see the uninstall script being magically added to the top lines. It's beyond my ability to figure it out, so hoping someone here knows how to track it down and remove it. Thanks!

[machine notes: iMac 2,2 450mhz; OSX 10.4.11 tiger; bash]

 

[Lastic]

You can try with this link https://superuser.com/questions/23265/mac-terminal-changed-my-shell-now-cant-start-it

Let me know if it helped, otherwise will have to look at other solutions.

 

[txgraeme]

Thanks so much for the reply! I wasn't smart enough to figure out if any of that applied to my situation. Tried to enact the solutions shown but none seemed to take. Is there one in particular that seems more applicable?

 

[XaPHER]

Can you upload a screencap of the terminal preferences window?

 

[NoBoMac]

A couple of places to look...

Go to Terminal > Preferences.

Under the General tab, there is a "Shells Open With": make sure "Command" is not selected.

Under Profiles, select the Shell sub-tab: make sure Run Command is not selected (if selected, can erase the command listed, just to be safe).

If not there, maybe something got placed into one of the startup files for the command shell. Since using Bash, those files will be in your home/user folder: .bashrc, .bash_profile, .bash_login, .profile. Look at those and see if the command is buried in there.

(And yes, there are periods in front of the file names, and will be hidden in Finder [and Terminal for that matter: would need to do a "ls -a" command line to show the folder's hidden files])

 

[Lastic]

Indeed check the things posted above , another one to check mentioned in the link is :

1. Open System Preferences.app
2. Go to the Accounts Preference Pane
3. If required unlock the padlock
4. Hold control and click or right click on your account in the list of accounts.
5. Choose Advanced Options...
6. Change the value where it says Login shell: to the path to the bash shell you want to use.

Here is what mine says (default /bin/bash)

 

[txgraeme]

Had some more time to work on the imac, and here is the Terminal Preferences dialog.


I've tried some other shell types but all have this same problem. I'm going to try to find a hidden profile based on that list provided above, it's a bit annoying because I have to run a new command for each command line entry. Checking directories takes a while.

 

[txgraeme]

Well, the hidden script didn't seem to be in the usual cases (~/.bash_profile, ~/.profile, /etc/bashrc). Mostly things look in good shape for the hidden files in the user home directory. The bash.history doesn't show anything to me, just a lot of failed uninstall scripts

 

[XaPHER]

It may not be directly related to the shell, if I think about it. Are you having problems with the OS otherwise? Does it also happen with another user account?

Can you look inside /Library/launchdaemons and /Library/launchdaemons and their ~/Library/ counterparts for any launchd script that can relate?

If you can't find anything,.. You might want to search by contents on your drive for a file containing the uninstaller command. Better use something else like easyfind since spotlight won't really help. There's an Easyfind version that should work on tiger still available here:

http://www.tucows.com/preview/321132/EasyFind

 

[txgraeme]

Hello people, thanks again for the tips. I think XaPHER's latest suggestion is probably where I need to start looking at. I'm hoping to tackle it this weekend.

In the meantime, I've found a workaround by using the Xterm program inside the X11 app. I'll keep trying to crack it and will report back when I find the solution.

 

[B S Magnet]

Hello people, thanks again for the tips. I think XaPHER's latest suggestion is probably where I need to start looking at. I'm hoping to tackle it this weekend.

In the meantime, I've found a workaround by using the Xterm program inside the X11 app. I'll keep trying to crack it and will report back when I find the solution.

By chance, did you open and look through the driver's uninstaller script in a utility like TextWrangler, BBEdit, or vi/emacs/nano/pico, to see which directories are called out in its routine? This is where I might start to determine where the script’s commands traversed (i.e., the directories) to remove or change items in its script when you ran it.

Also, adding one more thing:
The Terminal preferences in Tiger for my clamshell G3, contrary to the screencap you posted earlier, is set to radio button option 1, "Execute the default login shell using /usr/bin/login", not the second option of a filled in "/bin/bash". Have you tried that selection in the process of ironing out what might have gone amiss?

 

[txgraeme]

Xapher, thanks for the thoughtful tips. I followed your advice and looked in the suggested places but couldn't track down the source of the problem. Of course, it's a lot of space to cover so I'm planning to make another pass. Hopefully it will become apparent.

Regarding Terminal preferences, I did switch out of the top radio button when the problem originally started. They have different behaviors, which I didn't fully appreciate until you asked. The first option gives me a response like this:

The second gives me this:


I'm using the second button because it also allows me to use a workaround, by sending a dummy process to background (&) it gives me control of the CLI again. After that it behaves normally, which thankfully makes this problem more of an inconvenience. I'm still trying to track down the issue, but it's no longer impacting functionality.