DEFAULTSHELL and shell on command line don't seem to take effect

[Sander Pool]

Hi,

I'd like to run bash instead of /bin/sh for my processes. I added the following to my STAF.cfg:

SET DEFAULTSHELL "/bin/bash -c %C"

This does not seem to be effective:

[pools1@pools1-dur-vm ~]$ staf 10.110.224.203 process start shell command :6:export wait returnstdout returnstderr
Response

---

{
Return Code: 0
Key : <None>
Files : [
{
Return Code: 0
Data : declare -x CLASSPATH="/usr/local/staf/lib/JSTAF.jar:/usr/local/staf/samples/demo/STAFDemo.jar:"
declare -x HOME="/root"
declare -x LANG="en_US.UTF-8"
declare -x LD_LIBRARY_PATH="/usr/local/staf/lib:"
declare -x LOGNAME="root"
declare -x OLDPWD
declare -x PATH="/root/.rvm/bin:/root/.rvm/rubies/ruby-1.8.7-head/bin:/usr/local/staf/bin:/usr/bin:/bin:"
declare -x PWD="/root"
declare -x SHELL="/bin/sh"
declare -x SHLVL="4"
declare -x STAFCONVDIR="/usr/local/staf/codepage"
declare -x STAF_INSTANCE_NAME="STAF"
declare -x USER="root"
declare -x _="/bin/bash"

}
{
  Return Code: 0
  Data       :
}

]
}

Similarly when I put the shell on the command line the effect is the same:

[pools1@pools1-dur-vm ~]$ staf 10.110.224.203 process start shell "/bin/bash -c %C" command :6:export wait returnstdout returnstderr
Response

---

{
Return Code: 0
Key : <None>
Files : [
{
Return Code: 0
Data : declare -x CLASSPATH="/usr/local/staf/lib/JSTAF.jar:/usr/local/staf/samples/demo/STAFDemo.jar:"
declare -x HOME="/root"
declare -x LANG="en_US.UTF-8"
declare -x LD_LIBRARY_PATH="/usr/local/staf/lib:"
declare -x LOGNAME="root"
declare -x OLDPWD
declare -x PATH="/root/.rvm/bin:/root/.rvm/rubies/ruby-1.8.7-head/bin:/usr/local/staf/bin:/usr/bin:/bin:"
declare -x PWD="/root"
declare -x SHELL="/bin/sh"
declare -x SHLVL="4"
declare -x STAFCONVDIR="/usr/local/staf/codepage"
declare -x STAF_INSTANCE_NAME="STAF"
declare -x USER="root"
declare -x _="/bin/bash"

}
{
  Return Code: 0
  Data       :
}

]
}

I repeated this on my local machine as well.

Did I not understand the meaning of setting DEFAULTSHELL correctly?

Thanks,

Sander

[Sander Pool]

I wonder if this has an effect:

[root@10 ~]# ls -al /bin/bash
-rwxr-xr-x 1 root root 941720 Sep 22 2015 /bin/bash
[root@10 ~]# ls -al /bin/sh
lrwxrwxrwx. 1 root root 4 Apr 5 2016 /bin/sh -> bash
[root@10 ~]#

I would think that if you run /bin/bash the $SHELL variable would tell you so. In fact it does when I log in as myself. The STAF examples above are clearly not loading .bashrc either so the runtime environment for my shell is not correct. Strangely environment variables set in STAFEnv.sh don't seem to percolate to the STAF process either. Or maybe this is by design. Trouble is that I need control over my STAF PROCESS shell otherwise my test scripts don't run.

[Sharon Lucas]

Setting the DEFAULTSHELL doesn't change the $SHELL variable. Setting the DEFAULTSHELL specifies the default shell that STAF uses when starting a process via a separate shell. It does work as described.

[Sharon Lucas]

So, DEFAULTSHELL has been set to "/bin/bash -c %C", as shown in the PROCESS LIST SETTINGS output:

[root@staf1g ~]# staf local process list settings
Response
--------
Default Stop Using Method   : SigKillAll
Default Console Mode        : Same
Default Focus               : Background
Process Auth Mode           : Disabled
Default Auth Username       : <None>
Default Auth Password       : <None>
Default Auth Disabled Action: Ignore
Default Shell               : /bin/bash -c %C
Default New Console Shell   : <None>
Default Same Console Shell  : <None>

When you submit a START request to the PROCESS service (I specified a command that takes 30 seconds to run so that I can query it while it is running):

[root@staf1g ~]# staf local process start shell command "STAF local DELAY DELAY 30s"
Response
--------
124

When you query the process handle, the "Shell" value shows you the shell that STAF used when starting a process (/bin/bash -c %C)

[root@staf1g ~]# STAF local PROCESS QUERY HANDLE 124
Response
--------
Handle         : 124
Handle Name    : STAF/Client
Title          : <None>
Workload       : <None>
Shell          : /bin/bash -c %C
Command        : STAF local DELAY DELAY 30s
Parms          : <None>
Workdir        : <None>
Focus          : Background
User Name      : <None>
Key            : <None>
PID            : 8605
Start Mode     : Async
Start Date-Time: 20170419-17:30:56
End Date-Time  : <None>
Return Code    : <None>

[Sander Pool]

It was my understanding that $SHELL is set by the currently running shell. If that is wrong, sorry. I do not see evidence that bash is indeed being run by STAF because its environment is wrong.

When I run this command:

staf 10.110.224.203 process start  shell command  "ps -ef"  wait returnstdout returnstderr

I get:

<snip>
root      1919     1  0 Apr18 ?        00:00:00 /usr/sbin/atd
root      1934  1915  0 Apr18 ?        00:00:00 [startSTAFProc.s] <defunct>
root      1935     1  0 Apr18 ?        00:00:07 /usr/local/staf/bin/STAFProc

<snip>

postfix  11873  1817  0 09:03 ?        00:00:00 pickup -l -t fifo -u
root     11966  1935  0 09:20 ?        00:00:00 ps -ef

This shows the command is forked by STAFProc and not run by bash. Same when I specify the shell path on the command line. When I export the environment I see only part of the environment I'm supposed to see. Maybe this is as expected by you but not by me. When I specify I want to use a shell I expect to see a shell as the parent of my command.

Interestingly it seems that STAFProc optimizes shell execution and does not do as instructed when there is 'no need'. See the following:

[pools1@pools1-dur-vm ~]$ staf 10.110.224.203 process start  shell command  "ps -ef;echo $SHELL"  wait returnstdout returnstderr

<snip>
root     12080  1935  0 09:35 ?        00:00:00 /bin/bash -c ps -ef;echo /bin/bash
root     12081 12080  0 09:35 ?        00:00:00 ps -ef
/bin/bash

    }
    {
      Return Code: 0
      Data       :
    }
  ]
}

Now STAFProc is forking a bash process as instructed. When there is only a single command it doesn't do that. Even the $SHELL variable works not that it is of interest to me besides for testing why things aren't working.

[Sander Pool]

I still don't understand why STAFProc is the parent of a single command but probably there is an optimization inside STAFProc I don't understand. In any event, when I add the "-l" flag to my default shell I get the behavior I want which is that I want bash to pick up its full environment. The issue is resolved.

Thanks for your continued help over the years.

[Sharon Lucas]

Glad the issue is resolved.

The following link contains some good information about "How to determine the current shell I'm working on?" at http://stackoverflow.com/questions/3327013/how-to-determine-the-current-shell-im-working-on. It talks about a caveat when using "echo $SHELL" is that if you launch a shell explicitly as a subprocess (e.g. it's not your login shell), you will get your login shell's value instead.

Note that the PROCESS services is a "internal" STAF service, in which case, the executable code for the service resides within STAFProc. More about this in section "2.2 Services" at http://staf.sourceforge.net/current/STAFUG.htm#HDRSRVCON

[Sander Pool]

Yes, I know the difference between internal and dynamically loaded services but I don't think that explains why a composite commands get a proper shell and simple ones do not. This does not seem correct to me. Adding the SHELL keyword to the PROCESS command should force an external shell to be fired up and that is not always happening. At least I see no evidence of this, as shown above. A single command (ps -ef) does not get run in a shell. If it did then its parent would be the shell but instead it is STAFProc. If I run a more complicated command (ps -ef | grep bash) then the whole thing gets run in a shell process.

From the manual: "SHELL specifies that COMMAND should be started via a separate shell. Using a separate shell allows complex commands involving pipelines to be readily executed. "

It appears that the command is flagged as 'complex' and only then is started in a shell, otherwise it is forked. Is this really intentional or a bug?