14,000 hints and counting!

A subtle fix for hard-to-diagnose installer hangs
This one's probably only for UNIX geeks who have customized their tcsh (or bash) environment with a .cshrc (or .bashrc or similar) file. I just got done debugging why the Canon ip3000 printer driver installer was hanging in the middle of installation.

It turns out that I had aliased rm to rm -i, so I would not clobber files as easily. Unfortunately, the Canon installer used my tcsh environment in its script. This is bad form, I would say.

Inside the script was a section that tried to delete some files using rm. Since the alias was present, it was waiting for me to say y but, of course, that was futile since it was not being run in a Terminal window. I removed the alias I had in my .cshrc, and the installer worked fine.
•
• Currently 2.17 / 5
You rated: 4 / 5 (6 votes cast)

[8,476 views]

## Hint Options

A subtle fix for hard-to-diagnose installer hangs | 23 comments | Create New Account
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A subtle fix for hard-to-diagnose installer hangs
Authored by: jolinwarren on Jul 25, '05 09:27:40AM
You can put your alias in '.login' instead of '.cshrc'. The '.login' file is only run for login shells (which the installer script does not qualify as, presumably). From the man page for tcsh:

    Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on startup.

By putting your alias in '.login', you can continue to benefit from it in the terminal without causing installer problems.
A subtle fix for hard-to-diagnose installer hangs
Authored by: gidds on Jul 25, '05 04:39:21PM
Well, yes, but...

Environment variables are inherited by subshells (which is why .login, or .zlogin, is a good place for them). Aliases aren't. So any time your login shell happens to launch a subshell (e.g. when you shell out from vi or ftp or whatever), your aliases aren't available.

---
Andy/

A subtle fix for hard-to-diagnose installer hangs
Authored by: gunnmjk on Jul 25, '05 10:29:59AM

Instead of relying on rm -i, is there a way to make rm move files to the trash, and put that in the profile?

A subtle fix for hard-to-diagnose installer hangs
Authored by: spiralscratch on Jul 25, '05 04:48:30PM
It's usually considered unwise to have an existing command mapped to another via an alias. What you want would mean mapping 'rm' to 'mv'. You can, however, make up your own command names. Enter the following fine into your .bashrc file:
trash () { mv $1 ~/.Trash/ ; } Now, you can type in 'trash someitem', and that file or folder will be moved to your trash folder. A subtle fix for hard-to-diagnose installer hangs Authored by: Code Masseur on Aug 01, '05 10:16:10AM That tip for moving files to the trash folder seems neat, but how does it handle trashing files on other volumes / external disks? A subtle fix for hard-to-diagnose installer hangs Authored by: spiralscratch on Aug 01, '05 08:16:46PM Good point. Using this function on an object on a volume other than the one holding the user's home folder would move it to the local trash. Probably not ideal. That's what I get for knocking off that line in only a few minutes. It probably wouldn't be too hard to add some logic to the function to account for such volumes. (Or heck, go one more step further and just make it a true executable script and drop it in a bin folder somewhere.) A subtle fix for hard-to-diagnose installer hangs Authored by: jdtangney on Jul 26, '05 08:18:09PM Yes. Install osxutils. See http://osxutils.sourceforge.net/ A subtle fix for hard-to-diagnose installer hangs Authored by: geohar on Jul 25, '05 11:02:41AM As a side note, this is one reason why it annoys me when installers use a script that is bash or tcsh to perform installation tasks - they can and are easily screwed up by user customizations. Install scripts should use sh or perl. A subtle fix for hard-to-diagnose installer hangs Authored by: veloso on Jul 25, '05 07:03:37PM Messing with your environment is a time-honored way to break stuff. I know someone who replaced tar with gnutar on all our HP boxes, breaking pretty much every tar-based product on hp-ux. If you customize your environment, be willing to pay the price. I myself added a bunch of stuff to /etc/profille, but don't generally bother to alias stuff because of issues like this. A subtle fix for hard-to-diagnose installer hangs Authored by: liz4cps on Jul 25, '05 07:16:36PM Actually, if you write a csh shell script, you should include the -f flag in the first line of the script: #/bin/csh -f This -f is for fast and tells csh to ignore any .cshrc file. That was SOP back in the day. I thought it would be still, but various things have been lost over the years... The .login is not equivalent as it is only read in at login and is/was inteneded for environmental variables (eg to set the TERM and the speed of the connection (to the computer from your terminal!), etc). If you start up another shell (eg in another window, etc), it would not get aliases from the .login but would inherit the environment. So, the .cshrc was read in whenever a shell was started -- which used to happen if you just put a command in parens -- eg "bar | (cd ...; foo)". It looks like MacOS does treats each new window as a login shell though. It seems quite odd to me... Maybe now the .login is nearly equivalent. - Liz PS I did have that alias for "rm". I've changed it to "del" but that'll be hard for me to remember -- I've been using "rm" since 1979! A subtle fix for hard-to-diagnose installer hangs Authored by: liz4cps on Jul 25, '05 07:21:13PM I had a typo in the last one; sorry. That first line should have an ! in it: #!/bin/csh -f - Liz overriding aliases Authored by: sjk on Jul 29, '05 04:06:36PM But remember you can override your "rm" alias by prepending '\' (backslash) to it. :-) And, depending on the flavor of Unix and/or command, adding "-f" after an alias with "-i" can override its interactivity. Personally, I prefer using cp/mv/rm with "-i" by default (e.g. with shell aliases) and overriding it when desired. With "rm", I'd rather be prompted to delete the first of many files, interrupt the command, recall it (e.g. ctrl-P), slap a backslash in front of it, and redo it than be the unwilling victim of an overzealous wildcard. An occasional, brief "do you really want to do that?" pause has been a worthwhile rethink-and-redo safety net for me although some people will be annoyed by it. And I've never wanted to remember to use interactive versions for those commands. YMMV. :-) A subtle fix for hard-to-diagnose installer hangs Authored by: garumph on Jul 25, '05 11:56:03AM I hate it when people alias common commands like rm. I would fire an admin that did that, it is dangerous. What happens when you go to a machine without the alias? You risk deleting more than you want. If you don't like rm alias another command to it like del or erase. Use that command instead of rm. That way if you get on a machine or account with the alias you are safe. fire who? Authored by: sjk on Jul 29, '05 03:33:59PM Since I've been using Unix shells for nearly 30 years I'll usually take exception to someone who thinks they know better than I do how to customize (or not) my shell environment. If I want to add "-i" to aliases for cp, mv, and rm commands in my shells that's my business. I'm not telling anyone else to do that, nor would I even consider creating such aliases in "shared shells" unless there was mutual understanding and consensus between everyone who'd be using them. If users (admins or not) aren't savvy enough to check for aliases and other customizations in shell environments other than their own before running commands with potentially unexpected, undesirable results then they'd benefit from more education and experience. IMHO, to fire someone who's willing (even eager) and able to learn these things would be a rather arrogant, myopic reaction. That's the kind of person I'd like to hire and enjoy working with. A subtle fix for hard-to-diagnose installer hangs Authored by: JMFelty on Jul 25, '05 04:40:10PM Back in the day it was good practice to assume that users customized their environments and sysadmins tried to protect them from themselves -- because they have the right -- and just deal with it. Why get all bent out of shape about something you KNOW is going to happen? How to avoid these problems Authored by: nxg on Jul 25, '05 08:02:41PM There's a lack of defensiveness all round, here! First, there's no reason for Canon to avoid any particular scripting language (though csh is probably a bad choice on other grounds) -- that's not the problem. Second, having the customisations in .cshrc isn't the problem either. Customisations that should be in place for each instance of a shell _should_ be in .cshrc (or .bashrc), not in .login, which is (supposed to be) for one-time settings, immediately after the login. As others have pointed out, however, the distinction is blurred in OSX. Whether or not aliasing rm to 'rm -i' is a good or bad thing, folk writing installer or other scripts should be prepared for the user to do this and much worse. So how is this sort of problem avoided? From a user point of view, it's good defensive practice to put something like # csh # skip remaining setup if not an interactive shell if ($?USER == 0 || $?prompt == 0 ||$?TERM == 0) exit

or

# *sh
if [ -z "$PS1" ]; then return fi ...near the top of your .cshrc or .bashrc, and crucially _before_ anything which prints anything to the stdout -- that's another category of hard-to-find bugs avoided. The same goes for system-wide csh and *sh startup scripts. This alone would probably have stopped the original poster being bitten by this bug. Because being vulnerable to user customisations _is_ Canon's bug, and it should probably be reported to them as such. Mistake number 1 was (as has been pointed out already) not including the -f option in the !# hack in the first line. Mistake number 2 is not carefully unaliasing, or escaping, or using a full path for, any and all commands they use in the script. Avoiding either would probably have been enough, but it's pretty amateur for them to make _both_ mistakes, when writing a script for such a context. Myself, I would claim that writing any script at all in csh is an immediate bug all by itself (the rant <http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/> is well-known, and spot-on), but that's tip for another time. All the best, Norman How to avoid these problems Authored by: LC on Jul 25, '05 09:40:12PM Right -- I was going to point out that any decent .cshrc script which defines interactive features (aliases, etc.) needs to have an exit mechanism which bails out early for non-interactive shells. The installer application which launches a user shell is a non-interactive situation. Prior to the exit logic (where you check the prompt variable, and exit or skip if the prompt is not pre-set), the usual action would be to define the command path (set path ...). After the prompt check, you can put the terminal setting commands, command aliases, and other stuff. I thought (from years ago) that the csh (or cshrc) man page does mention this; Larry. A subtle fix for hard-to-diagnose installer hangs Authored by: BobHarris on Jul 25, '05 11:18:15PM In my .bashrc file I wrap the contents in:  if [[${-#*i} != ${-} ]]; then ... ... ... fi  In my .tcshrc (or .cshrc) file I place this a the top of the file  if ( !$?prompt ) exit  # quick exit for non-interactive sessions

This works very well for me. I've used this stuff on my Mac, Tru64 UNIX, HP-UX, and Linux.

Bob Harris

A subtle fix for hard-to-diagnose installer hangs
Authored by: rpaul on Jul 26, '05 03:15:21AM

Actually I'd say Canon is erring on the side of amateurish if in fact they've centered their printer install process this way.

I've no idea if there's a set methodology from Apple regarding installations and environments. If there ain't there should be.

No need for the "M"ediocrity of "M"icrosoft to rear it's ugly head on this platform.

A subtle fix for hard-to-diagnose installer hangs
Authored by: name99 on Jul 26, '05 06:26:41PM

Canon are notorious for shipping really crummy software on MacOS X. Look at their scanners --- they come with a background app whose job is to sit listening over USB for when the user presses buttons on the scannner. This sounds like a fine thing to do, but their app is so poorly written it sucks up about 10% of CPU doing this one stupid task.
Another example is their windows centric viewpoint that thinks its just fine to write their crap at the root of the file system rather than figuring out the appropriate place under MacOS X to write it.

Damn, I wish Apple would provide some sort of "validated as not written by morons" program for MacOS X so that when I bought a printer or a scanner or suchlike I had some guarantee that it not only (barely) worked on the day I bought it, but that it was written well enough that it would play well with the rest of MacOS X, not gratuitously waste disk, RAM and CPU, and had a fair chance of surviving an OS upgrade still working.

A subtle fix for hard-to-diagnose installer hangs
Authored by: jdhorner on Jul 27, '05 12:27:28PM
isn't the simplest thing people are missing here this: they should have just used the entire system pathname to the -rm- executable. e.g.
/bin/rm
instead of just calling rm in general? that way, the alias is avoided and the user need not worry. ALSO, it would let the vendor know that the true system commands were being used.

---

-------
sig? who said anything about a sig?

A subtle fix for hard-to-diagnose installer hangs
Authored by: Code Masseur on Aug 01, '05 10:59:25AM

I totally agree with this comment: I consider using full pathnames for system executables a "best practices" item for writing secure (and predictable) scripts.

A subtle fix for hard-to-diagnose installer hangs
Authored by: calum on Jul 12, '07 05:57:12AM

The more correct way would be "\rm", no?