Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Prevent .cshrc customizations from impacting scripts UNIX
This recent hint included a mention of how aliasing rm to rm -i messed up an installer. The way I've always avoided this problem is to place the following line at the top of my .cshrc file:
if (! $?prompt) exit
This causes the .cshrc commands to be skipped if the prompt shell variable is undefined. The prompt shell variable is only defined when the shell is interactive with a terminal.

[robg adds: There are some other methods discussed in the comments to the previous hint, but I felt the topic was worth a hint of its own, in case people are searching on different terms. Please feel free to add your favorite workaround for your favorite shell to the comments...]
    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
 
[5,403 views]  

Prevent .cshrc customizations from impacting scripts | 7 comments | Create New Account
Click here to return to the 'Prevent .cshrc customizations from impacting scripts' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Prevent .cshrc customizations from impacting scripts
Authored by: wgscott on Aug 01, '05 10:41:30AM

#!/bin/csh -f

or better yet, don't program with the c-shell.



[ Reply to This | # ]
Prevent .cshrc customizations from impacting scripts
Authored by: kickingvegas on Aug 01, '05 05:04:02PM
Using the backslash in front of a command will override the alias for that command. Works pretty much with all the major Unix shells. So for example, if you have rm aliased to
rm -i
you can override it at the command line by typing
\rm


[ Reply to This | # ]
Prevent .cshrc customizations from impacting scripts
Authored by: LC on Aug 01, '05 10:48:20PM
Or else (for binary executables) ... /bin/rm; but for shell built-ins, the backslash is good. Also, can first unalias any commands that we know we'll use in the script (for good measure) ... and, the command path can be another BIG gotcha; (especially when your script will be run by another user!)

It (csh, tcsh) is just not such a great shell for serious script programming. Certainly software vendors should never ship csh scripts as production material. Boot-time (startup/shutdown etc.) scripts are sh, ksh, bash for good reason! Larry.

[ Reply to This | # ]

Similar Korn and Bourne tricks of the trade
Authored by: greed on Aug 02, '05 02:17:58PM
Ugh, hard-coding pathnames in commands is a different kind of evil; consider an 'rm' upgraded to handle meta-info on some weird filesystem that isn't supported by the standard /bin or /usr/bin commands. There's no reliable way to presume the 'rm' you want is in /bin or /usr/bin or /usr/xpg4/bin or whatever, if cross-UNIX portability matters.

I don't use C Shell, but the Korn (POSIX) shell has a "command" keyword, so you can definately get the actual command by regular path search, no alias, no function. (I think Bourne shells have it too.)

command rm ...

The other change I'd recommend in Korn (POSIX) and Bourne scripts is to use

#!/bin/ksh -p
(or
#!/bin/sh -p
; that turns on "privileged" mode, intended for set-user-ID scripts, but it also prvents the shell from loading the user's ~/.*rc files, so no surprising functions or aliases.

And don't forget

#!/bin/ksh -e
, to exit automatically on a failed command that doesn't have error checking associated with it. Scripts that ignore errors are evil.

[ Reply to This | # ]
for bash
Authored by: huzzam on Aug 01, '05 06:19:43PM

In bash, I wrap most of my .bashrc in

if [ -n "${PS1}" ]; then

[stuff for interactive shells here...]

fi
Anything I DO want to apply across the board can go outside of the if/fi construct, like umask & some environment variables.

[ Reply to This | # ]
Prevent .cshrc customizations from impacting scripts
Authored by: bdm on Aug 02, '05 06:55:29AM

Just put
   unalias *
at the start and all aliases will be disabled.

Works in tcsh interactive or not.

Brendan.



[ Reply to This | # ]
Prevent .cshrc customizations from impacting scripts
Authored by: luomat on Aug 02, '05 09:31:15AM

Yet another example of why you should not rename existing commands.

Rather than renaming "rm" use "del" or some other name which is not in use. That way when you are in another account or on another computer and go to use 'rm' thinking it is 'safe' you won't get burned. If you are used to typing 'del' for "safe rm" and you are in an account or on a computer where it isn't installed, you just get an error message.



[ Reply to This | # ]