Linux

Scripting in Linux with execline

Vincent Danen describes an alternative to traditional shell scripts, like bash. If you are resource-conscious, you may want to consider execline scripting as a leaner, more secure, and faster scripting method.

Most individuals write shell scripts in bash, or "sh" (which is often, but not always, bash). Other shells are more than capable of executing shell scripts as well, but the problem with shell scripts executed by shells is they can take more memory than they should, usually because if you execute a shell script from inside a shell, you now have two shells running instead of one. For example, if you ran a shell script and looked at the output of ps as it was executing, you might see something like:

25024 pts/0  Rs   0:00 -zsh
25036 pts/0  T   0:00 /bin/sh ./test.sh
25037 pts/0  T   0:00 sleep 100

There are alternatives to bash and similar shells for shell scripting, particularly if resources are an issue. One such alternative is execline. execline is a non-interactive, secure scripting language with a very different syntax from traditional shells. It's very simple and straightforward, secure, and portable. It's also very fast.

For instance, if the above output was from running the script test.sh, which contained:

#!/bin/sh
sleep 100

The execline equivalent would be:

#!/bin/sh
/bin/foreground { /bin/sleep 100 }

But notice that, unlike /bin/sh, the execline program doesn't hang around:

16183 pts/0  Rs   0:00 -zsh
16247 pts/0  T   0:00 /bin/sleep 100

This is because execline creates a chain of events, so to speak, and then exits. Each line in an execline script takes the output of the previous command as input to the next command. Once execline has parsed the script, it starts the chain of events and then exits. Although execline works very well for many types of scripts, it does have a few limitations. It won't work in every situation for which you would need to write a script (see the Current Limitations section at http://www.skarnet.org/software/execline/execline.html).

When combining execline with a tool such as runit, system startup becomes quite quick with low overhead. And the execline scripts aren't overly complex, once you get used to them. As an example, examine the stage 1 runit script as provided in Annvix in Listing A.

As you can see, each command in the script is an actual executable. Here, the /bin/foreground program is a simple program that reads the program within the block (such as /sbin/rc), forks, executes the program, and waits for it to complete; then, it execs into the next program noted outside the block.

In addition, using execline doesn't preclude the use of shell testing, but instead of writing:

if [ -f /sbin/runit.old ]; then
  rm -f /sbin/runit.old
fi

You're using:

/bin/foreground {
  /bin/if {
    /usr/bin/test -f /sbin/runit.old
  }
  /bin/rm -f /sbin/runit.old
}

Execline is a great scripter's tool, particularly for those working with numerous scripts or scripts that can execute many times (at the same time), or even those working in embedded environments.

Delivered each Tuesday, TechRepublic's free Linux NetNote provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

7 comments
carl0ski
carl0ski

is it just me or is execline just bash# ./test.sh& bash# note the ampersand runs you script in the background

apotheon
apotheon

From the pkg-desc file in the FreeBSD ports tree describing execline: execline is a very light non-interactive scripting language, which is similar to /bin/sh. Simple shell scripts can be easily rewritten in the execline language, improving performance and memory usage. execline was designed for use in embedded systems, but works on most Unix flavors. execline features conditional loops, getopt-style option handling, filename globbing, and more. Meanwhile, its syntax is far more logical and predictable than the shell's syntax, and has no security issues.

DanLM
DanLM

Wouldn't you think that the biggest resource of a shell script is in performing/launching various utilities? Ie, grep, sed, sort, uniq, awk???? The way I understood the article was that shell scripts are actually opening up another shell which requires more resources Yea, ok. But, I would think that every time you launch a utility(my previous examples) that the initialization of the utility would take up more resources. Not the script itself? Seriously, almost ever script I have ever written was launched from the crontab. Thus, why I wrote the script. Repetitive task that must be performed at a specific time. soooo, it opened up a shell that was never there before. It's still only 1 shell secession right? ????? Dan

rob_cranfill
rob_cranfill

I like the statement // execline ... has no security issues. Well, hey, there you have it! They say it has no security issues, so, ipso fatso, it's true! Would that it were that easy.... - rob

Johnny:P
Johnny:P

Ok, dont mean to sound skeptical... but why bother? For the sake of half a meg? What if you wanted to run your script on several machines, you'd need execline on each and every machine. Shells like ksh have so many built in functions within the shell (such as for test conditions, etc) they don't need to call external programs, and hence less context switches. Shells like csh and bash (and esp bourne) need to call an external program for just about everything. Moral of the story? Learn ksh :)

briant11
briant11

Wouldn't it be nice if the 1 shell secession could be performed in one process i.e. not proceeding to the next, then the next etc. But I agree, if it were possible then computer architects should design a better shell script that not only launches utilities but other programs/instructions, for example, a virus scan, disk cleanup or user identification command (UID) ... but that is somewhere in the future and I darer say that software consumers are all eager to get their hands of Vista and seeing for themselves what it has to offer that would blow the socks of many PC users. Cheeeers!

apotheon
apotheon

The noninteractive shell started by the script is not a huge resource sink. Using a less powerful shell language to try to avoid resource usage is usually a pretty good sign of premature optimization (the "root of all evil"). Only on embedded systems do you really have to worry about the trivial amount of system resources spent on a noninteractive shell to run a script.

Editor's Picks