Earthdata Forum

Looks like the forum ate my reply (beware the time-out!) Briefly, I ran installs from the command line initially, then switched to the GUI when it failed (see original post). I will try to work in some debugging checks in the scripts as you suggest.

>* running "update_luts" from the command-line
This works! (...with the -v aqua switch)

>* running "ocssw_runner update_luts -v aqua" from the command-line
Fails on the usual requests module import

>* running "ocssw_runner --ocsswroot $OCSSWROOT update_luts -v aqua" from the command-line
Fails on the requests module import

Dirk,

"bash -l" does not load ~/.bashrc

To get the previous 3 commands to execute correctly, we need to load the .bashrc file from a login file.

if you have a ~/.bash_profile file add this code to the file

# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi



if you have a ~/.profile file add this code to the file

# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi


after this the GUI should work. I will go back and read this thread a few times to figure out why install_ocssw does not work from the command line.

don

Morning,

> "bash -l" does not load ~/.bashrc
Okay... (?) I ran that as a test at George's suggestion. It opened a login shell as expected without incident.

> if you have a ~/.bash_profile file add this code to the file
My ~/.bash_profile has the following, which should accomplish the same thing:
if [ -r ~/.bashrc ]; then
source ~/.bashrc
fi

> if you have a ~/.profile file add this code to the file
No ~/.profile on this machine.

The command line install_ocssw and the GUI updater still both fail as described in the original post. The only thing that works so far is running "update_luts -v -aqua" by itself.

I backed up ocssw_runner and then added the line "echo OCSSWROOT=$OCSSWROOT >> ~/ocssw_runner.log" before the "source" call (I also tried placing it after the "source" call). I then tried updating OC Processors in the GUI and it failed as before, but it did NOT write the occssw_runner.log to ~ begging the question of whether ocssw_runner ran at all. When I run it on command line it works as expected (result in log file: OCSSWROOT=/Users/daurin/Applications/seadas8/ocssw).

An old log from a successful May 2019 install_ocssw run (named OCSSW_LOG_install_ocssw.py.txt) does exist in ~. That ocssw still resides on this machine in ~/Applications/ocssw, but none of the new paths point to it (the new location is ~/Applications/seadas8/ocssw).

yes, install_ocssw is special in the SeaDAS GUI. ocssw_runner does not exist yet when install_ocssw runs the first time.

Give me the results of these commands:

which ocssw_runner
ocssw_runner --ocsswroot $OCSSWROOT env


don

(base) daurin@GSSLA18091785:~/Applications/seadas8/ocssw/opt/bin$ which ocssw_runner
/Users/daurin/Applications/seadas8/ocssw/bin/ocssw_runner
(base) daurin@GSSLA18091785:~/Applications/seadas8/ocssw/opt/bin$ ocssw_runner --ocsswroot $OCSSWROOT env
LIB3_DIR=/Users/daurin/Applications/seadas8/ocssw/opt
PROJ_LIB=/Users/daurin/Applications/seadas8/ocssw/opt/share/proj
LIB3_CHECK=0
TERM_PROGRAM=Apple_Terminal
TERM=xterm-256color
SHELL=/usr/local/bin/bash
LIB3_LIB=/Users/daurin/Applications/seadas8/ocssw/opt/lib
TMPDIR=/var/folders/th/7q7vkd_x68g_88b8j5qg5kxh0000gp/T/
CONDA_SHLVL=1
CONDA_PROMPT_MODIFIER=(base)
TERM_PROGRAM_VERSION=433
TERM_SESSION_ID=366FF300-28DC-4365-9468-A0A2ACC326AE
LIB3_BIN=/Users/daurin/Applications/seadas8/ocssw/opt/bin
LIB3_INC=/Users/daurin/Applications/seadas8/ocssw/opt/include
USER=daurin
SWTBL=/Users/daurin/Applications/seadas8/ocssw/share/seawifs
CONDA_EXE=/Users/daurin/anaconda3/bin/conda
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.h63i0khAMj/Listeners
OCVARROOT=/Users/daurin/Applications/seadas8/ocssw/var
OCSSW_ARCH=macosx_intel
_CE_CONDA=
ASAP_PARMS=/Users/daurin/Applications/seadas8/ocssw/share/common/nav
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Applications/MATLAB_R2020a.app/bin:/Users/daurin/anaconda3/bin:/Users/daurin/anaconda3/condabin:/Users/daurin/Applications/seadas8/ocssw/opt/bin:/Users/daurin/Applications/seadas8/ocssw/bin:/Applications/Visual Studio Code.app/Contents/Resources/app/bin:/Applications/Visual Studio Code.app/Contents/Resources/app/bin
L2GEN_ANC=/Users/daurin/Applications/seadas8/ocssw/var/anc
NAVCTL=/Users/daurin/Applications/seadas8/ocssw/share/seawifs/nav
OCSSWROOT=/Users/daurin/Applications/seadas8/ocssw
CONDA_PREFIX=/Users/daurin/anaconda3
HDFEOS_LIB=/Users/daurin/Applications/seadas8/ocssw/opt/EOS/lib/macintel64
OCSSW_BIN=/Users/daurin/Applications/seadas8/ocssw/bin
HRPT_STATION_IDENTIFICATION_FILE=/Users/daurin/Applications/seadas8/ocssw/share/seawifs/station/station_id.dat
PWD=/Users/daurin/Applications/seadas8/ocssw/opt/bin
LANG=en_US.UTF-8
OCSSW_SVN=localhost
XPC_FLAGS=0x0
OCDATAROOT=/Users/daurin/Applications/seadas8/ocssw/share
SWFTBL=/Users/daurin/Applications/seadas8/ocssw/share/seawifs/qc
XPC_SERVICE_NAME=0
OCSSW_DEBUG=0
PGSLIB=/Users/daurin/Applications/seadas8/ocssw/opt/EOS/lib/macintel64
CXX=g++
_CE_M=
SHLVL=3
HOME=/Users/daurin
FC=gfortran
CONDA_PYTHON_EXE=/Users/daurin/anaconda3/bin/python
LOGNAME=daurin
ORBCTL=/Users/daurin/Applications/seadas8/ocssw/share/seawifs/nav
GCC_TUNE=
CONDA_DEFAULT_ENV=base
OCTS_REGISTRATION_TABLES=/Users/daurin/Applications/seadas8/ocssw/share/octs/nav
CC=gcc
DISPLAY=/private/tmp/com.apple.launchd.LsyV81Pece/org.xquartz:0
EOS_LIB_PREFIX=macintel64
ELEMENTS=/Users/daurin/Applications/seadas8/ocssw/var/seawifs
PGSINC=/Users/daurin/Applications/seadas8/ocssw/opt/EOS/include
NAVQC=/Users/daurin/Applications/seadas8/ocssw/share/seawifs/nav
_=/usr/bin/env

OB SeaDAS - dshea wrote:
> Dirk,
>
> "bash -l" does not load ~/.bashrc
>
> To get the previous 3 commands to execute correctly, we need to load the
> .bashrc file from a login file.
> [...]
> don

This is progress.

Getting the command-line environment set correctly at login has been a headache on macOS for years. Some users have copied a "~/.bashrc" from linux (or SGI IRIX64!), or have created a "~/.profile". Some of these startup scripts have different sections for interactive and batch sessions so you have to be careful about where you put the OCSSWROOT lines. It is very hard to diagnose this remotely -- there are just too many moving parts.

I strongly recommend that macOS users who will be using SNAP or SeaDAS for batch processing become comfortable with the command line.

Just to solidify things try this:

ocssw_runner --ocsswroot $OCSSWROOT which python3


if it shows the wrong python3, then all we need to do is fix your PATH

don

/usr/local/bin/python3

daurin wrote:
> (base) daurin@GSSLA18091785:~/Applications/seadas8/ocssw/opt/bin$ which
> ocssw_runner
> /Users/daurin/Applications/seadas8/ocssw/bin/ocssw_runner
> (base) daurin@GSSLA18091785:~/Applications/seadas8/ocssw/opt/bin$
> ocssw_runner --ocsswroot $OCSSWROOT env
> LIB3_DIR=/Users/daurin/Applications/seadas8/ocssw/opt
> [...]
>
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:\
/Applications/MATLAB_R2020a.app/bin:\
/Users/daurin/anaconda3/bin:\
/Users/daurin/anaconda3/condabin:\
/Users/daurin/Applications/seadas8/ocssw/opt/bin:\
/Users/daurin/Applications/seadas8/ocssw/bin:\
/Applications/Visual Studio Code.app/Contents/Resources/app/bin:\
/Applications/Visual Studio Code.app/Contents/Resources/app/bin
> [...]

So the default path comes before the ocssw entries. This is not good for SeaDAS users but is, however, recommended in some documents to protect against malicious versions of system programs (e.g., "ls") in user directories.

I can see how Matlab and anaconda3 entries might come after OCSSW_bash.env is sourced, but having the system entries at the start is a surprise and pretty much negates the purpose of installing anaconda3.