Hi
In your ~/.profile or respective file in /etc/profile.d.
You can also set in a systemd service file as well (re your other
thread)… In the [Service] section add;
Environment="PATH=...."
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.19-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
Yes I try run through the systemd service but didn’t work, when I type printenv PATH or echo $PATH, the directories added don’t are in the variable.
See:
Using keyboard-interactive authentication.
Password:
Last login: Tue Oct 16 08:39:48 2018 from 192.168.0.113
OE-DB:~ # systemctl status ini-server.service
â ini-server.service - Roda comandos na inicializaçao -Pierre - 16/10/2018
Loaded: loaded (/etc/systemd/system/ini-server.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Tue 2018-10-16 10:54:18 -03; 52s ago
Process: 1022 ExecStart=/bin/sh -c /usr/local/bin/ini-server.sh (code=exited, status=0/SUCCESS)
Main PID: 1022 (code=exited, status=0/SUCCESS)
Oct 16 10:54:14 OE-DB systemd[1]: Starting Roda comandos na inicializaçao -Pierre - 16/10/2018…
Oct 16 10:54:14 OE-DB sh[1022]: OpenEdge Release 11.6.4 as of Tue Oct 3 01:15:46 EDT 2017
Oct 16 10:54:18 OE-DB systemd[1]: Started Roda comandos na inicializaçao -Pierre - 16/10/2018.
OE-DB:~ # printenv PATH
/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin
I do assume a conceptual misunderstanding: Environment variables are only set inside the current shell (or program) and then, if export’ed, available to any “sub-program” started from this shell/program.
will get executed in a shell of its own (because of the “shebang” #!/bin/bash) - there, the value is acutally set and exported, but then the shell is terminated. So after you have run that program and checked the value of PATH, you’ll see the value as it was set in the current, invoking shell - and there it never got changed.
So concerning your previous post, where you describe how you started the “proadsv” program and right before that exported the variables DLC and PATH, the proadsv program should actually have seen these variables with their new values. If the program remains active as a process, you can verify this by looking up the PID of the process and then check the content of /proc//environ for these variables.
Checking the variables from shells outside the setting program/shell and its subs will not work.
On 10/16/2018 10:54 AM, jmozdzen wrote:[color=blue]
Checking the variables from shells outside the setting program/shell and
its subs will not work.[/color]
Right, and if for some reason you want to have a script that you can call
set environment variables in your CURRENT shell, then you can do so using
the ‘source’ command, which essentially runs the commands int he called
script in the current shell, rather than doing what you may be missing by
default in that a call to a script calls a new sub-shell which, at the end
of the script, exits, taking all of its updated environment variables with it.
source /pat/to/your/environment-setting-script.sh
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
Thanks for everyone’s help, really I was making a mess!
I solved the problem by creating the /etc/profile.local file that was just what I needed, but since the file did not exist I did not know it was just to create.