[OPEN-ILS-DEV] PATCH: srfsh.c (! commands)

[Scott McKellar]

This patch sprinkles a few const qualifiers about, and inserts "void"
as the formal parameter list of a couple of functions.

Mostly, though, this patch is an experiment and a proof of principle.
You may not want to apply it in its present form.

The experiment concerns the way we invoke a child process, using an 
exclamation point as an escape.  So far, I have compiled with 
EXEC_DEFAULT undefined, so I'm not using the pipe that we open to 
bash.  Under these conditions, when we invoke a child process, the 
results aren't very satisfying.

The reason is that we don't pass the command to a shell.  We parse it 
with strtok() and then pass an array of arguments to the program 
identified by the first token.  As a result:

- We don't expand environmental variables.
- We don't expand wild cards.
- We can't use input or output redirection.
- We can't invoke another layer of subshell, as with backticks.
- We can't access shell built-ins.

In short, we can't harness the rich language processing that a shell
normally applies before passing arguments to programs.  Even trivial
commands like:

    srfsh# !ls *.o

...don't work as expected.  As a result, the escaping is very 
limited in its usefulness, probably leaving a typical user both
frustrated and baffled.

Using the pipe-to-bash approach would presumably eliminate most of 
these problems, but not all.  For example, if we enter:

    srfsh# echo "Hello,       World!"

...the result will be to display "Hello, World!" instead of
"Hello,       World!".  By dismembering the command with strtok()
and then reassembling it, we lose the extra embedded spaces.

In any event, the pipe-to-bash approach applies only when EXEC_DEFAULT
is defined, and only when the command we enter is otherwise invalid 
to srfsh.

-------------

The experimental solution is to pass the original command (minus the
opening exclamation point) to the system() function, which in turn
passes it to an instance of /bin/sh.  Then sh does all the things it
normally does.

On my system sh is linked to bash.  I don't think this sh behaves 
like a true Bourne shell, but is just an alias for bash.  For example
it implements the "let" built-in, which I don't think a true Bourne 
shell recognizes.

In any case we may or may not want to use sh.  We might want to 
always use bash.  Or we might want to look at $SHELL to see what the
user is accustomed to.

I don't think that this patch is a final solution, because it needs
to be cleaned up in some respects.  However I believe that it is a
step in a useful direction.

Scott McKellar
http://home.swbell.net/mck9/ct/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: srfsh_c_2.patch
Type: text/x-patch
Size: 3309 bytes
Desc: 3702060326-srfsh_c_2.patch
Url : http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070709/2809e335/srfsh_c_2.bin