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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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"
]
}
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"
]
}
I repeated this on my local machine as well.
Did I not understand the meaning of setting DEFAULTSHELL correctly?
Thanks,
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.
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.
So, DEFAULTSHELL has been set to "/bin/bash -c %C", as shown in the PROCESS LIST SETTINGS output:
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):
When you query the process handle, the "Shell" value shows you the shell that STAF used when starting a process (/bin/bash -c %C)
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:
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:
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.
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.
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
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?