I wanted to change the env var PWD in Jenkins because the current file path has spaces in it which causes errors. I wanted to place double quotes around this in hopes of resolving this.
PWD: home/user/File Storage
After changing
PWD:home/user/"File Storage"
Did anyone know how to go about changing the PWD?
Related
when I run dep ensure
/home/jenkins/workspace/myproject-voter is not within a known GOPATH/src
we have go installed on this docker image , I know that the project is not cloned to go/src but my question is if via set env or something I can do some trick to overcome this issue ?
my question is if via set env or something I can do some trick to overcome this issue ?
Not "set env", but ENV:
ENV GOPATH=/path/to/your/Go/project
That would ensure any Go command is using the right workspace.
I'm using a Centos 7 server. I'm entering the command echo $PATH and trying to figure out where it's getting the path that it's putting out. The path doesn't match what's in my .bash_profile, and there is no .bashrc file. How do I find out where my current $PATH is being sourced from?
The Default values for .bashrc and $PATH are stored in files /etc/bashrc and /etc/profile. These files are used by shell and kernel for setting default values for proper functioning of the server.
I would advise not to change any values here, as it might cause abnormal behavior in the server.
I'm trying to set up a build in jenkins that reads a config file generated during a previous build (if it exists) as part of a shell build step. However, the variables I define in the config file don't seem to get put into the environment of the current shell, and I can't figure out why.
The first build step will pull in the config file from the upstream project.
The config file has just simple variable defs:
VAR_ONE=foo
VAR_TWO=bar
#etc...
The second build step is the shell, which looks like this:
if [ -f $WORKSPACE/build_config ];
then
source $WORKSPACE/build_config
echo $VAR_ONE
echo $VAR_TWO
fi
In the jenkins console output for the job I see:
+ '[' -f /var/lib/hudson-slave/workspace/build_config ']'
+ source /var/lib/hudson-slave/workspace/build_config
++ VAR_ONE=foo
++ VAR_TWO=bar
+ echo
+ echo
I don't know what the double plus means, maybe it's being exported into a different scope? If it is, why?
I haven't really looked into the EnvInject or EnvFile plugins yet. I plan to after this exercise in frustration, but I figured this would be a good question to ask anyway since I thought this would be possible to just bash out.
Anyone know what the heck is going on?
Just a shot in the dark, but have you tried to surround the variables with {} like in ${VAR_ONE} when using them?
About the double plus i just can guess either. I would say it is because of the variables declaration coming from the config file which is loaded into the current shell... But this is really just me guessing.
Hope this helps though.
when I try to use fabric to deploy Apache server remotely using Fabric, I encountered a problem. I tried to add a new path to the PATH variable first using sudo(), then I tried to echo $PATH using sudo() too. However, I found that it looks like the new path wasn't added to PATH at all. As a result, I cannot execute the bins in that path via sudo().
[name#IP:port] Executing task 'reboot'
[name#IP:port] sudo: export PATH=$PATH:/new/path/to/add/install/bin
[name#IP:port] out: sudo password:
[name#IP:port] sudo: echo $PATH
[name#IP:port] out: sudo password:
[name#IP:port] out: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Could anyone tell me how to add a path variable to sudo command in Fabric? Thanks in advance.
It should be habit to always give a full path to the executable when running as root, to avoid having trojan horses being pushed into your PATH.
Setting an environment variable via export works only for the current shell session - which is the one invoked by sudo. Once your command (export, in this case) is executed, the shell exits, and takes your environment variable with it. The next time you execute sudo, a new shell (with default environment) is set up, which does know nothing about your previous export.
The configuration file /etc/sudoers usually contains an entry like Defaults env_reset, the effect of which is that environment variables set in the calling environment are not copied to the environment invoked by sudo, so calling export in your current environment and then executing sudo does not work either. This is done for security reasons (ref. 1) above).
It is possible to set up /etc/sudoers to make exceptions to 3), via env_keep. Refer to man sudoers for details. However, see 1) - it is not a good idea.
There is the -E option to sudo, which allows to keep the caller's environment (including e.g. an extended PATH), but this requires SETENV being set in /etc/sudoers. Again, refer to man sudoers for details, and be mindful of 1).
use
sudo('PATH=$PATH:/new/path/to/add/install/bin commad')
I want add some directory to the $PATH when running sudo, this is a (semi) permanent requirement, not something that needs to be added to the scripts themselves. I notice that Django has managed to do it, (my $PATH when running sudo is "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/django/django-trunk/django/bin") - so how did it do that?
This is the line in the sudoers file that resets:
Defaults env_reset
You can work around this by adding PATH to env_keeps or by adding this line:
Defaults env_keep = "PATH"
EDIT: meder, you do not disable env_reset, you simply bypass the path reset
Or you can remove the offending env_reset line.
Even better though, you can declare a secure_path that will replace PATH when sudo is run:
Defaults secure_path="/bin:/usr/bin"
That way you can control what specific directories to include in the path.
I think this should work out if you save it in /root/.bashrc:
export PATH=/www/foo:$PATH
I forget if it's PATH or PYTHONPATH and if it actually matters, this is based on my user's .bashrc:
export PYTHONPATH=/www/django:$PYTHONPATH
You can set the variable in /etc/environment, and then use "sudo -i" to run the script (works in ubuntu 10.10).