Shell System Wide Environment Variable Across Shells

F

fumanchu

Hello,

I am in need of setting several "system wide" environment variables. I tried to put them in /etc/csh.cshrc, but that did not work, because each created user can have a different shell. Is there a "best practice" on how to support this across all shells?

Thanks,
 
Any sane shell should read /etc/profile.

For console logins, you can also set environment variables in login classes defined in /etc/login.conf.
 
Yeah, I originally tried adding a file under /etc/profile.d, but that did not work. Since we mostly use csh, it looks as if csh does not read /etc/profile, so I had to add the variable to /etc/csh.cshrc... but that is not the ideal solution.
 
fumanchu said:
Yeah, I originally tried adding a file under /etc/profile.d, but that did not work. Since we mostly use csh, it looks as if csh does not read /etc/profile, so I had to add the variable to /etc/csh.cshrc... but that is not the ideal solution.
Click to expand...
Ok I can already hear the angry BSD crowd, but csh is not what I called a "sane" shell ? (most of all because it's non-standard, see ...)

Well, if you can't rely on a POSIX shell and also can't rely on /etc/login.conf (e.g. because people use display managers to login or whatever), I guess you'll have no other choice than configuring your variable in multiple files. Yes, that sucks....
 
covacat, I'm sure systemd can set global variables fetched from some central web service, don't you think? ?

In fact, I'm not even sure this would work. Doesn't e.g. "login" clear and repopulate the environment?
 
I think we have an XY problem here. You say you need a global environment variable, which you say needs to be available to all users. Does that include subshells? Programs started from inside another program (fork/exec, the system() call, and so on)? Cron jobs? Do you see the insanity here? A user can download or write the source code for an arbitrary shell (something as crazy as Intercal is to programming languages), and how are you going to enforce that it doesn't clear environment variables, or ignores what you put into /etc/profile?

I have a better idea: Tell us what you are really trying to accomplish, tell us why you need this, and perhaps we can come up with a better solution.
 
fumanchu said:
Hello,

I am in need of setting several "system wide" environment variables. I tried to put them in /etc/csh.cshrc, but that did not work, because each created user can have a different shell. Is there a "best practice" on how to support this across all shells?

Thanks,
Click to expand...
You should use ~/.login_conf.

Code: 
{beastie} @ FreeBaSeD-T430 > /home/beastie
 → cat .login_conf
# $FreeBSD$
#
# see login.conf(5)
#
#me:\
#    :charset=iso-8859-1:\
#    :lang=de_DE.ISO8859-1:
me:\
        :charset=UTF-8:\
        :lang=en_US.UTF-8:\
        :path=/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin /home/beastie/bin /home/beastie/.local/bin /home/beastie/.local/bin:\
        :setenv=PAGER=most,\
        BROWSER=firefox,\
        EDITOR=nano,\
        LC_NUMERIC=en_US.UTF-8,\
        LC_MONETARY=en_US.UTF-8,\
        COLORTERM=truecolor,\
        CHEATCOLORS=true:
 
zirias@ said:
Ok I can already hear the angry BSD crowd, but csh is not what I called a "sane" shell ? (most of all because it's non-standard, see ...)
Click to expand...

I'm not angry, you're just expressing your opinion :) Mine differs; sh for scripts, csh interactively.

i only started with FreeBSD 2.2.6 in 1998, but then and ever since the 'standard' installed interactive shell has been csh, including for root - unless 13.x changed that?

POSIX is useful, but it's not the Holy Grail.
 
smithi said:
Mine differs; sh for scripts, csh interactively.
Click to expand...
If there weren't very powerful, yet conforming, shells (like e.g. zsh), this would make objective sense. But as there are conforming alternatives, is's indeed just a matter of personal taste, which probably grew from habit and/or "BSD tradition" ;)

The price you pay is having to remember two different shell languages and deal with a few other incompatibilities. I don't even criticize that, just pointing it out, because csh ignoring /etc/profile is one of them.

smithi said:
POSIX is useful, but it's not the Holy Grail.
Click to expand...
POSIX and other standards is what helps a lot with interoperability. Of course you'll always want to use stuff that's not specified by POSIX. I just prefer stuff that extends POSIX, instead of doing something completely different ?‍♂️

ralphbsz I'm not even sure this is an example for an XY-problem, after all, having some environment variables preset in any user's session is a rather typical requirement. But of course it makes sense pointing out there is no such thing as "system-wide variables" (impossible given how environment variables work) and I agree knowing the specific scenario could help.

BobSlacker ~/.login_conf certainly isn't system-wide configuration, that's what /etc/login.conf is for. But as already mentioned, the problem with that is that there are ways to start a session without using any tool that would read/apply this database, for example login using some X display manager.
 
zirias@ said:
BobSlacker ~/.login_conf certainly isn't system-wide configuration, that's what /etc/login.conf is for. But as already mentioned, the problem with that is that there are ways to start a session without using any tool that would read/apply this database, for example login using some X display manager.
Click to expand...
Yeah, I know that ~/.login_conf isn't system-wide. But unlike /etc/login.conf, the configuration in ~/.login_conf survives at least one Display Manager (XDM). I use both and works.
 
zirias@ said:
If there weren't very powerful, yet conforming, shells (like e.g. zsh), this would make objective sense. But as there are conforming alternatives, is's indeed just a matter of personal taste, which probably grew from habit and/or "BSD tradition" ;)
Click to expand...

I'm trying not to take that as a put-down. I respect your choices. Sure it's personal taste, the result of evaluation over years of how I can best work efficiently; sh at the command line isn't that.

I make extensive use of some of csh's features like history search/ save/load, directory stack, aliases and more that sh mostly lacks.

zirias@ said:
The price you pay is having to remember two different shell languages and deal with a few other incompatibilities.
Click to expand...

I don't use csh as a language at all; all my scripts are sh.

One of csh's differences is handling output redirection, where I find sh syntax superior, so I'll often use such as:

% sh -c 'grep -r something / 2>/dev/null'

zirias@ said:
I don't even criticize that, just pointing it out, because csh ignoring /etc/profile is one of them.
Click to expand...

Sure, just as sh ignores /etc/csh.cshrc and
~/.cshrc <&^}=

zirias@ said:
POSIX and other standards is what helps a lot with interoperability. Of course you'll always want to use stuff that's not specified by POSIX. I just prefer stuff that extends POSIX, instead of doing something completely different ?‍♂️
Click to expand...

csh(1) /POSIX

cheers
 
smithi said:
Sure, just as sh ignores /etc/csh.cshrc and
~/.cshrc <&^}=
Click to expand...
You're aware this is completely non-standard, right? Given the rest of your post, you might indeed try for example zsh for interactive usage, maybe you actually like it? ?

edit: and no, no "put-down" involved. It's just stating a few facts. csh is by large "BSD tradition", and tcsh (which comes with FreeBSD) is a very comfortable version of it. If you like it, use it. Just be aware of the drawbacks of it NOT conforming to standards (in this case: POSIX).
 
zirias@ said:
Ok I can already hear the angry BSD crowd, but csh is not what I called a "sane" shell ? (most of all because it's non-standard, see ...)

Well, if you can't rely on a POSIX shell and also can't rely on /etc/login.conf (e.g. because people use display managers to login or whatever), I guess you'll have no other choice than configuring your variable in multiple files. Yes, that suck
Click to expand...
i didn't know that csh is not sane/standard(i tried to use it but its doesn't support VAR=value command, syntax and that really set me off), then why is it in base? mksh is just awesome and bare sh for base, i use it for both root and regular user
 
ayleid96 said:
i didn't know that csh is not sane/standard(i tried to use it but its doesn't support VAR=value command, syntax and that really set me off), then why is it in base? mksh is just awesome and bare sh for base, i use it for both root and regular user
Click to expand...
"sane" is to some extent subjective, but csh certainly is "non-standard". The thing is, it's traditionally included with any BSD system. The standard for POSIX systems though is "bourne" shells. And there are shells with lots of features like zsh (or GNU's bash) which conform to POSIX...

After all, everyone has to decide for themselves.
 
To elaborate a bit on the "C-shell issue", here's a VERY old rant:

Csh Programming Considered Harmful

harmful.cat-v.org harmful.cat-v.org

Please, before killing me, consider its age. All the bugs mentioned there probably don't apply to tcsh as delivered with FreeBSD. But: The flaws in the language design persist. And that's the reason why nowadays everyone agrees you really shouldn't ever use a C-shell for scripting.

I just ask: Then why learn different shell languages at all, given there are very comfortable POSIX-compliant shells available? But here, we're back in the realms of "personal taste" ?
 
zirias@ said:
To elaborate a bit on the "C-shell issue", here's a VERY old rant:

Csh Programming Considered Harmful

harmful.cat-v.org harmful.cat-v.org

Please, before killing me, consider its age. All the bugs mentioned there probably don't apply to tcsh as delivered with FreeBSD. But: The flaws in the language design persist. And that's the reason why nowadays everyone agrees you really shouldn't ever use a C-shell for scripting.

I just ask: Then why learn different shell languages at all, given there are very comfortable POSIX-compliant shells available? But here, we're back in the realms of "personal taste" ?
Click to expand...
Thank you for links and reply, i know that all necessary/base scripts start with #!/bin/sh(correct me if i am wrong) then why by default we have csh by default on root account, i am not questioning philosophy about shells, i just want to know the reason for csh existing within freebsd base, is it pure traditional or other technical reasons for it?
 
ayleid96 said:
i know that all necessary/base scripts start with #!/bin/sh(correct me if i am wrong)
Click to expand...
You're not wrong. /bin/sh is the minimal standards-compliant (POSIX/bourne) shell in base, that's what should be used for any scripting. And using a minimal shell for that makes sense as well, it reduces the risk to write non-portable scripts.* That said, FreeBSD's /bin/sh got a few features for interactive use (like a useful command history), but it's still kind of minimal.

ayleid96 said:
then why by default we have csh by default on root account, i am not questioning philosophy about shells, i just want to know the reason for csh existing within freebsd base, is it pure traditional or other technical reasons for it?
Click to expand...
You certainly want a more comfortable shell for interactive use with features added beyond what POSIX specifies.

But, IMHO, the reason that it's a "C-shell" in FreeBSD is really just "BSD tradition". BSD always came with C shells...

*edit: compare this to the situation on most GNU/Linux systems: GNU's standard shell is bash, which is POSIX-compliant, but offers tons of extensions, and many distributions install it as /bin/sh – the result is lots of "bashisms" in shell scripts written by people who only know Linux systems :rolleyes:
 
You must log in or register to reply here.
Back
Top