DevHeads.net

/etc/profile.d/lang.sh -- still needed?

Hello people,

does anybody know if the files /etc/profile.d/lang.{csh,sh} are still used
these days, and what for?
Do we still need them in Fedora?
Should they be installed by default these days?

Any info is appreciated! :)

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>.

Comments

/etc/profile.d/lang.sh -- still needed?

By R P Herrold at 05/14/2018 - 11:27

by their terms, they are a collection of I18N and environment
settings.

Are you asking if /bin/sh, and /bin/tcsh are still installed
or used? I certainly install ande use each

One assumes the files could be moved out to 'bash' and 'tcsh'
packagings, if the (unstated) goal is to eliminate
'initscripts' as a standalone package

-- Russ herrold

Re: /etc/profile.d/lang.sh -- still needed?

By David Kaspar at 05/14/2018 - 11:41

​My question was more meant in a sense "are those files still necessary"?
:) I expect they were created to deal with some problems with locale
setting, but from just looking into them it's hard for me to guess what the
initial purpose of them were... :)

​Let me rephrase - if those files are gone completely, will it break
anything? Isn't the functionality of those scripts obsolete nowadays?​

​I'd like to remove them completely if possible, but I don't want to break
anything for our users.​ That's why I would like to know the initial
purpose of those files, and if they are still really needed nowadays... :)

Re: /etc/profile.d/lang.sh -- still needed?

By Stephen John Smoogen at 05/14/2018 - 11:51

On 14 May 2018 at 11:41, David Kaspar [Dee'Kej] < ... at redhat dot com> wrote:
A quick review of the files says that all kinds of user related things
will probably "break" from other scripts expecting specific collation
to reports on 'XYZ application is so slooooow' because it is not
getting language setup correctly. [I believe that some of the fixes in
there were from when UTF-8 was coming into play and startup of the
system got slow because every startup script was parsing things in 8+
bit wide when they didn't need to.. this filtered down to fixing speed
issues for users.]

I guess the question is more like: Is this an initscripts problem or
some other part of the OS. If initscripts plans to remove it, I would
definitely expect a systems change because it is going to silently
affect a lot of things which have been getting a 'free' ride from that
environment setup over the years. Some of the problems are probably
fixed, but I expect others are just expecting those .sh to do their
job.