On 2/26/13 3:39 PM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>> On 2/26/13 12:41 AM, Linda Walsh wrote:
>>
>>> It isn't using the current value of SHELL as my shell nor the value
>>> of my login shell.
None of this is relevant, see below.
> #if 1 <---------------Note problem??
Your vendor, which may be SuSE, has changed bash and shipped the modified
version. They have chosen to interpret Posix ("a command equivalent to
having a shell invoked with the pathname resulting from the search as its
first operand") as requiring that bash actually invoke /bin/sh, with all
of the consequences of starting a fresh process. I imagine they didn't
change the man page while they were at it, nor produce a list somewhere
of the changes they made.
I'm always going to answer from the perspective of bash as I distribute it.
This is a different case.
You should follow Greg's excellent advice and include the #! line. That's
the only way you can be sure of what you get.
> (SuSE ism?)
> larray = strvec_len(args) + 1;
> args = strvec_resize(args, larray + 1);
>
> for (i = larray - 1; i; i--)
> args[i] = args[i - 1];
>
> args[0] = savestring(_PATH_BSHELL);
> args[1] = command;
> args[larray] = (char *)0;
>
> SETOSTYPE (0); /* Some systems use for USG/POSIX semantics */
> execve ("/bin/sh", args, env);
> SETOSTYPE (1);
>
> internal_error (_("%s: cannot execute: %s"), command, strerror (errno));
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
