bash scripters--a question

[OfficeLinebacker]

So at my job we use tcsh, and "the way it's always been done" is that if you need to string a few commands together, you just write a c shell script (#!/bin/csh, which is just an alias to tcsh).

Lately I've realized (for myself, not just cos someone told me) the superiority of bash for scripting, and, frankly, interactive shell as well. Anyway what I've been doing is every time I have to modify a c shell script, I change it to #!/bin/sh, which is just an alias to bash.

I'm used to having all the stuff I set in my .cshrc file, including aliases, available in my scripts, so I was quite consternated when I tried to use the distill command, which I have aliased to a Perl script I wrote that uses ps2pdf. Apparently our version of ps2pdf isn't smart enough to do glob expansions.

Anyway when I converted this script it obviously broke. So I have to

a) make sure to use #!/bin/bash--not #!/bin/sh
b) shopt -s expand_aliases in ~/.bashrc
c) setenv BASH_ENV ~/.bashrc in my .cshrc file*

What a pain! Why WOULDN'T I want my aliases available when I code a script?

The only explanation I saw was here.

"In a script, aliases have very limited usefulness."

Why???

*It seems that one could also do something equivalent with a ~/.bash_profile but why create a new file when I cna just add a line to ~/.cshrc?

TIA

 

[cleverhandle]

I think it's mostly just a portability thing - if your script depends on aliases set elsewhere in your shell configuration, then it will break if the script is used by someone else. It shouldn't be as hard to get around as you describe though. Just use #!/bin/bash instead of #!/bin/sh (as you're already doing) and make sure that ~/.bashrc is still used in non-interactive shells. Most .bashrc's by default have a control near the top that bails if the shell is non-interactive (like mine has [ -z "$PS1" ] && return). Disable that control and your scripts should have aliases available. Or better yet, if there are particular aliases you need, then just define them at the top of the script.

 

[OfficeLinebacker]

Well, seeing as I control a file that gets sourced by all my users' .cshrc files, and I don't have to worry about anyone other than my users using my scripts, I'd say the portability issue is moot.

I am doing this conversion with an eye to changing myself and all my users' shells to bash sometime in the future (I also have the right to make that decision), but this is one aspect of bash I don't like.

However, being able to treat STDERR and STDOUT separately goes a looooooooong way.

 

[Nothinman]

Another aspect is debugability, I think most people consider shell scripts to be self-contained so references to functions, variables, etc outside of that file can be a PITA to track down. The only real exceptions to that rule that I can think of right now are init scripts, since a lot of distributions put the lsb functions in a seperate file and reference them.