I have tried the following
at the end of my .screenrc
conda activate ${CONDA_DEFAULT_ENV}
in my bash terminal, I typed:
conda activate atwork3
echo ${CONDA_DEFAULT_ENV}
> atwork3
screen -S test
> # starts screen OK but comes with env base
echo ${CONDA_DEFAULT_ENV}
> base
I read that you cannot put bad commands in the .screenrc or the full file gets ignored which is probably what happens to me here
I also tried things from how-to-open-tabs-windows-in-gnu-screen-execute-commands-within-each-one but did not yet get the real stuff behind these comments and how to specify a command in .screenrc or at screen call (examples are weird to me)
Anyone could please give an example on how to change env while entering screen to keep the conda env of the mother bash terminal! (also in subscreens!)
Related
I'm learning Haskell Stack in college. I've hit a problem with my $PATH. From what I can tell is because I also have conda installed. What I'm doing, I've installed Haskell Stack fine and follow the directions to set up project:
stack new MyFirstProject
cd MyFirstProject
stack build
stack install
All fine until stack install I get the error:
Copying from /Users/jamesmurphy/modules/Functional_Programming/Week5/MyFirstProject/.stack-work/install/x86_64-osx/cc05e4baf51e8b4a394e9151b943fe70c815c04c30f6eb1688f4a9e027d758ca/8.10.7/bin/MyFirstProject-exe to /Users/jamesmurphy/.local/bin/MyFirstProject-exe
Copied executables to /Users/jamesmurphy/.local/bin:
- MyFirstProject-exe
Warning: Installation path /Users/jamesmurphy/.local/bin
not found on the PATH environment variable.
I checked the $PATH to see what it was set to using nano .bash_profile and its set as
# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/Users/jamesmurphy/opt/anaconda3/bin/conda' 'shell.bash' 'hoo$
if [ $? -eq 0 ]; then
eval "$__conda_setup"
else
if [ -f "/Users/jamesmurphy/opt/anaconda3/etc/profile.d/conda.sh" ]; then
. "/Users/jamesmurphy/opt/anaconda3/etc/profile.d/conda.sh"
else
export PATH="/Users/jamesmurphy/opt/anaconda3/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda initialize <<<
I'm a bit lost with this as I've never seen $PATH like this before.
So I have tried adding to this $PATH by using nano .bash_profile and added this to the top.
export PATH="$PATH:/Users/jamesmurphy/.local/bin:$PATH"
Still wont work, So I Just replaced all the conda stuff with
export PATH="$PATH:/Users/jamesmurphy/.local/bin:$PATH"
I need to add this PATH but don't know the right way to do it with the conda stuff also. I've messed around with a few times trying a couple of different things and cant figure it out. I opened a new terminal every time I made a change. If anyone can help me or point me in the right direction, it would be most appreciated. Thank you
Updated
Sorry I might have left info out. The 'stack install' is suppose to make an executable file of the program. Haskel Stack is in installed correctly already. If I run
/Users/jamesmurphy/modules/Functional_Programming/Week5/MyFirstProject/.stack-work/install/x86_64-osx/cc05e4baf51e8b4a394e9151b943fe70c815c04c30f6eb1688f4a9e027d758ca/8.10.7/bin/MyFirstProject-exe
it will run the program. I'm being told to add /Users/jamesmurphy/.local/bin to my $PATH but when I do this it still doesn't work.
In my ~/.bashrc I set the below variables...they work fine in my python script when I launch it but when I use supervisor it can't fine
FAILURE
[supervisor]
environment=ORACLE_HOME="%(ORACLE_HOME)s",LD_LIBRARY_PATH="%(LD_LIBRARY_PATH)s"
SUCCESS
[supervisor]
environment=ORACLE_HOME="/path/to/it",LD_LIBRARY_PATH="/path/to/it"
Basically I don't want to go back into the config file every time I want to update the oracle instant client.
Thanks
Try this executing these commands and then start supervisor
>> sudo export ORACLE_HOME="/path/to/it"
>> sudo export LD_LIBRARY_PATH="/path/to/it"
>> . ~/.bashrc
I am not able to set env variables through an executable csh/tcsh script
An env variable set inside a csh/tcsh executable script "myscript"
contents of the script ...
setenv MYVAR /abc/xyz
which is not able to set on the shell and reports "Undefined variable"
I have made the csh/tcsh script as executable by the following shell command
chmod +x /home/xx/bin/myscript
also the path is updated to
set path = (/home/xx/bin $path)
which myscript
/home/xx/bin/myscript
When I run the script on command line and echo the env variable ..
myscript
echo $MYVAR
MYVAR "Undefined variable"
but if i source on command line
source /home/xx/bin/myscript
echo $MYVAR
/abc/xyz
you need to source your code rather than execute it so that it is evaluated by the current shell where you want to modify the environment.
You can of course embed
source /home/xx/bin/myscript
within your .cshrc
the script does not need to be executable or have any #! shebang (though they don't hurt)
This is not how environment variables work.
An environment variable is set for a process (in this case, tcsh) which is passed on to all child processes. So when you do:
$ setenv LS_COLORS=foo
$ ls
You first set LS_COLORS for the tcsh process, tcsh then starts the child process ls which inheres tcsh's environment (including LS_COLORS), which it can then use.
However, what you're doing is setting the environment is a child process, and then want to propagate this back to the parent process (somehow). This is not possible. This has nothing to do with tcsh, it works like this for any process on the system.
It works with source because source reads a file, and executes it line-by-line in the current process. So it doesn't start a new tcsh process.
I will leave it as an exercise to you what the implications would mean if it would be possible :-) Do you really want to deal with unwise shell scripts that set some random environment variables? And what about environment variables set by a php process, do we want those to go back in the parent httpd process? :-)
You didn't really describe what goal you're trying to achieve, but in general, you want to do something like:
#!/bin/csh -f
# ... Do stuff ...
echo "Please copy this line to your environment:"
echo "setenv MYVAR $myvar"
I just started reading Michael Hartl's book on Rails and I've run across a problem in the setup phase. Hartl keeps referring to making a file in my home directory, but I'm not quite sure how to do this. For example, when I try to setup the command line for sublime text the instructions tell me to do this: Assuming you've placed Sublime Text 2 in the Applications folder, and that you have a ~/bin directory in your path, you can run:
ln -s "/Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl" ~/bin/subl
My problem is that I don't know how to put a ~/bin directory in my path. I know this is real basic but any help would be greatly appreciation.
create or edit ~/.profile (works with both bash and zsh)
add the following
export PATH=$PATH:$HOME/bin
The line above is saying, overwrite the PATH environment variable and set it to the previous path plus ~/bin
Now when you try to run a command, bash will look in all the colon separated paths in your PATH environment variable for an executable.
To see your entire PATH, type echo $PATH in a terminal. Or better yet, type env to see all environment variables.
On your terminal
$ mkdir ~/bin
$ sudo ln -s "/Applications/Sublime Text2.app/Contents/SharedSupport/bin/subl" /usr/bin/subl
Edit ~/.base_profile
export PATH=$PATH:~/bin
usage:
open current directory:
subl .
In your ~/.bashrc file add to the end:
PATH="$HOME/bin:$PATH"
I'm having a weird issue with a start-up script which runs a Sinatra script using the shell's "daemon" function. The problem is that when I run the command at the command line, I get output to STDOUT. If I run the command at the command line exactly as it is in the script -- less the daemon part -- the output is correctly redirected to the output file. However, when the startup script runs it (see below), I get stuff to the STDERR log but not to the STDOUT log.
The relevant lines of the script:
#!/bin/sh
# (which is and has been a symlink to /bin/bash
# Source function library.
. /etc/init.d/functions
# Set Some Variables
RUNAS="joeuser"
PID=/var/run/myapp.pid
LOG="/var/log/myapp/app-out.log"
ERR_LOG="/var/log/myapp/app-err.log"
APPLICATION_COMMAND="RAILS_ENV=production ruby /opt/myapp/lib/daemons/my-sinatra-app.rb -p 8002 2>>${ERR_LOG} >>${LOG} &"
# Snip a bunch. This is the applicable line from the "start" case:
daemon --user $RUNAS --pidfile $PID $APPLICATION_COMMAND &> /dev/null
Now, the funky parts:
The error log is written to correctly via the redirect of STDERR.
If I reverse the order of the >> and the 2>> (I'm grasping at straws, here!), the behavior does not change: I still get STDERR logged correctly and STDOUT is empty.
If the output log doesn't exist, the STDOUT redirect creates the file. But, the file remains 0-length.
This used to work. The log directory is maintained by log-rotate. All of the more-recent 'out' logs are 0-length. The older ones are not. It seems like it stopped working some time in April. The ruby code didn't change at any time near then; neither did the startup script.
We're running three different services in this way. Two of them are ruby daemons (one uses sinatra, one does not) and the other is a background java process. This is occurring for BOTH of the ruby processes but is not happening on the java process. Maybe something changed in Ruby?
FTR, we've got ruby 1.8.5 and RHEL 5.4.
I've done some more probing. The daemon function does a bunch of stuff, but the meat of the matter is that it runs the program using runuser. The command essentially looks like this:
runuser -s /bin/bash - joeuser -c "ulimit -S -c 0 >/dev/null 2>&1 ; RAILS_ENV=production ruby /opt/myapp/lib/daemons/my-sinatra-app.rb -p 8002 '</dev/null' '>>/var/log/myapp/app-out.log' '2>>/var/log/myapp/app-err.log' '&'"
When I run exactly that at the command line (both with and without the single-ticks that got added somewhere along the line), I get the exact same screwy behavior w.r.t. the output log. So, it seems to me that this is an issue of how ruby (?) interacts with runuser?
Too long to put in a comment :-)
change the shebang to add #!/bin/sh -x and verify that everything is expanded according to your expectations. Also, when executing from terminal, your .bashrc file is sourced, when executing from script, it is not; might be something in you're environment that differ. One way to find out is to do env from terminal and from script and diff the output
env > env_terminal
env > env_script
diff env_terminal env_script
Happy hunting...