[OPEN-ILS-DEV] PATCH: srfsh.c (more on shelling out)

[Scott McKellar]

This patch contains one minor change and one less minor change.

--------

The less minor change is the elimination of some old code that once
opened a pipe to send commands to bash.  According to Bill Erickson
in a private email, that code is a leftover remnant from an 
experiment and may be removed.

Before a patch was applied several days ago, things worked like this:
IF you compiled srfsh with a certain macro #defined, AND you entered
a command that was invalid to srfsh, THEN srfsh would pipe the 
command to bash for execution.

It is doubtful that anyone but Bill ever used this variation, but if
anyone wants to keep it around, then this is his or her chance to 
protest.  Before protesting, however, please note that the shell
escape mechanism now provides shell-like command processing.  I.e. 
if you start the srfsh command line with an exclamation point, srfsh 
passes the rest of the command to the default shell (normally 
/bin/sh) for execution.  The command so passed can use environmental
variables, pipes, IO redirection, wild card expansion, and most of
the sorts of things you're used to from the shell command line. 

Note that not all shells behave the same.  If you're used to using
tcsh as your shell, for example, you may find that sh won't work 
quite the same way.  For now, at least, that's just too bad, but
that's the way shell escapes typically work.

It is probably possible to invoke the user's default shell as
identified by the environmental variable $SHELL.  However that
nicety would not be trivial to code.

----------

The minor change is that, after building an array of pointers 
pointing to tokens from the input command, I set the next 
pointer to NULL so that it mark the end of the token list.

For most systems most of the time, this change will make no 
difference, because a preceding memset() writes a bunch of binary
zeros to the pointer array.  However not all systems represent
NULL as all-bits-zero.

There is a further subtlety: the memset() doesn't fill the entire
array.  It fills a number of bytes equal to the number of pointers
in the array.  However a pointer occupies more than one byte (with
rare exceptions).  The result is that, on a system with four-byte
pointers, only one fourth of the pointers get nullified.

This incomplete nullification probably explains the following
mysterious fragment that occurs after building the array of token
pointers:

	// not sure why (strtok?), but this is necessary
	memset( words + i, 0, COMMAND_BUFSIZE - i );

For a sufficiently large number of tokens, where we exhaust the
pointers nullified by the first memset(), this second memset()
provides at least one NULL to terminate the list.

At least that's my theory.  I have left the memsets alone for now.
I don't really know what sort of misbehavior the second memset() is 
intended to prevent, so I can't test the effects of its removal.

Scott McKellar
http://home.swbell.net/mck9/ct/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: srfsh_c_5.patch
Type: text/x-patch
Size: 3427 bytes
Desc: 2196935148-srfsh_c_5.patch
Url : http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070712/4c6e9c9e/srfsh_c_5.bin