10.5 Sourceable Scripts

A powerful concept in csh is that of aliases. Another great capability is shell scripts. Each has its strengths. An alias is just right for common sequences of commands, calling a command by a different name, and so on. Scripts are great for more flexible processing and batch processing. There are limitations to both, and I will show a way around them.

The limitation to aliases is that you are working pretty much with one command line. Consider this example:

alias pp 'set o2=$cwd; popd; set old=$o2; dir_number; record_dir pp; \\
  prompt_set; set cd_attempt=(\!*); if ($#cd_attempt > 0) cd $cd_attempt'

Now this works fine for me, and it served me well for a few years and thousands of invocations, but it's at the point where I start thinking that a script is more suited to the job. This brings me to the limitation of scripts...

Shell scripts are great for accomplishing some task that might change a file, start a program, etc. They are limited by the fact that any changes they make to shell or environment variables are not visible (38.3) to the parent shell that started them. In other words, you can write some really cool script that will change directories for you if you don't touch the keyboard for five seconds, but once the script exits, you are still in the same place you started.

The answer is to combine the best of both worlds. Consider this:

( )	alias pp 'set cd_attempt=(\!*); source ~/bin/pp_csh'

We set up a variable and source a script. The concept is this: put your command-line arguments into a variable and then source (44.23) a script in order to accomplish something. The difference here is that because you are not starting a subshell (38.4) for the script, it can do everything an alias can and more. This is much like Bourne shell functions (10.9).

Some hints on using this technique:

• Naming: I like to name the script that is doing all of the work after the alias, with _csh or .csh at the end of its name. I put all of the scripts in my ~/bin (4.2). [Instead of names ending in .csh, I put mine in a directory named ~/.lib/csh. -JP ]

• Feedback: You don't want to execute the script directly. You want to source it. Here's a good first line that detects this:

  #!	#! /bin/echo sorry,try:source

• Usage statement: Check the variable that you expect to see from the alias. If it isn't there, you can show a usage statement, and do a goto to the end of the script:

  $# <<	if ($#lg_args == 0) then 1 usage: lg [-a][-p] pattern [command] -a lists all (.dot files) -p pipe resulting list into command +++ goto lg_end endif ... lg_end:

• Alias options: You aren't limited to what an alias can do, since you are sourcing a script. You gain some flexibility here. Here's one way of handling options:

  switch [1] set shift	unset ls_arg while (! $?ls_arg) switch ("$lg_args[1]") case "-a": set ls_arg="-a" shift lg_args case "-p": set use_pipe shift lg_args default: set ls_arg breaksw endsw end

Have fun with this! You may find yourself tossing some old aliases and rewriting them as sourceable scripts. They're also easier to maintain.