Hi Dale,
I have a bash script that needs to do "input $GEMSTONE/updgrade/xxx.sh". And so, I need to get $GEMSTONE resolved. I am trying to source stone.env in many ways but I am failing. I am sure I am doing something dumb. The error I get is that custom.env is not found... this is because it is sourced this way: source custom_stone.env This is the script: #!/bin/bash # Requires a SystemUser password as a parameter if [ "a$2" = "a" ]; then echo 'Missing argument <SystemUser password>' exit 1 fi source ${GS_HOME}/bin/defGsDevKit.env stonePath=$GS_SERVER_STONES/$1 if [ ! -d "$stonePath" ] ; then exit_1_banner "The stone $stoneName does not exist" fi # set up stone environment pushd $stonePath $stonePath >& /dev/null source $stonePath/stone.env popd >& /dev/null $GS_HOME/bin/startTopaz $1 -l <<EOF set user SystemUser pass $2 login input $GEMSTONE/upgrade/installtimezone.txt commit logout exit EOF Thanks _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
BTW, I think I came to this issue a few times. I wonder why we cannot change stone.env to be: source $GEMSTONE_STONE_DIR/custom_stone.env that fixes it. Thanks On Tue, May 9, 2017 at 2:25 PM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
The $GS_HOME/startTopaz script sources stone.env like this: # set up stone environment I see this pattern in your script below, so that makes me think that perhaps there is something wrong other than the way your are sourcing the stone.env ... is there a custom.env file present in the stone directory? Dale On 05/09/2017 10:25 AM, Mariano
Martinez Peck via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Tue, May 9, 2017 at 2:48 PM, Dale Henrichs via Glass <[hidden email]> wrote:
Yes, but I couldn't figure... The only workaround is what I said in the next email, that is, change stone.env to be: source $GEMSTONE_STONE_DIR/custom_
Yes, there is. I even tried doing a "cd $stonePath" before sourcing.... but nothing changed.
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Well the $GEMSTONE_STONE_DIR and $GEMSTONE_NAME are set by `pwd`, so I'm not sure that changing how custom_stone.env is sourced would solve those problems .... somehow we need to know the stone directory and the name of the stone and we need to ensure that the base name of the directory matches the name of the stone... I guess we could have the stone.env script figure out what directory it is living in, instead of using `pwd`. What is confusing to me is how the proposed change to stone.env "fixes your problem", $GEMSTONE_STONE_DIR is a function of `pwd` and if `pwd` is correct, why can't the file custom_stone.env be found> Dale
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
This is very bizarre, can you do a `set -x` in the script and
provide the output? Something doesn't add up, because
$GEMSTONE_STONE_DIR is set by `pwd` and if `pwd` is correct then
`source custom_stone.env` should be correct as well Dale On 05/09/2017 11:03 AM, Mariano
Martinez Peck wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |