LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 07-20-2013, 12:27 PM   #16
GazL
Senior Member
 
Registered: May 2008
Posts: 3,312

Rep: Reputation: Disabled

The idea behind the profile.d/ directory was to provide a simple mechanism for packages to add their own stuff to the profile in a safer way than trying to sed or patch it directly into an existing /etc/profile file - which is always problematic. I think the concept works best when the files that are placed in there by packages are considered non modifiable. This doesn't mean you can't add your own files to it, merely that it's best if you leave any of them that are under package management alone. This is why I think setting such as $LANG belong elsewhere (whether that be in /etc/profile itself, /etc/environment or a rc.conf file, of which only the first is used in a stock Slackware install).

Anyway, there are many ways of looking at it, and this is just my take on it.
 
Old 07-21-2013, 05:30 AM   #17
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Original Poster
Rep: Reputation: 145Reputation: 145
Quote:
Originally Posted by GazL View Post
...
I've always viewed /etc/profile as something that belongs to the system administrator and the contents of profile.d as belonging to the distro maintainer for stuff that shouldn't need changing.
...
I agree "/etc/profile.d" belongs to the distro maintainer. But why the stuff there shouldn't be changed?

The sole purpose of "/etc/profile.d" is to avoid (at best effort) changes to "/etc/profile", which will block the automatic upgrade of this file due to the modified "/etc/profile" having a different md5sum than that from the official package. It achieves this goal by distributing the changes to the (sub)scripts under "/etc/profile.d". The use "lang.{c,}sh" is a good example.

This method is called structured programming.

My proposal was exactly intended for this -- to avoid changes to "/etc/profile". Neither does my proposal do the thing you hate -- changing the contents of the scripts under "/etc/profile.d". In my proposal no regular file gets changed. They only get chmod-ed. By contrast, the present "/etc/profile" file should be changed to remove "." from PATH.

Last edited by guanx; 07-21-2013 at 01:59 PM. Reason: Thanks GazL for pointing out the md5sum is checked and not the time stamp
 
1 members found this post helpful.
Old 07-21-2013, 06:33 AM   #18
GazL
Senior Member
 
Registered: May 2008
Posts: 3,312

Rep: Reputation: Disabled
Quote:
Originally Posted by guanx View Post
The sole purpose of "/etc/profile.d" is to avoid (at best effort) changes to "/etc/profile", which will block the automatic upgrade of this file due to the modified "/etc/profile" having a newer time stamp than the package content file under "/var/log/packages".
I don't think that is true. As I said above, my understanding (someone please correct me if I am incorrect) is that the rationale behind introducing /etc/profile.d was not to avoid dealing with user changes to /etc/profile for the reasons you state, but to introduce modularity in order to avoid the complications of multiple packages all trying to make their own changes to a single file and tripping over each other. It's a change that was pretty much introduced specifically to ease packaging.


If you change a file in /etc/profile.d then you end up in exactly the same situation as you have just described for /etc/profile itself: moving the adding of "." to the PATH into a profile.d file doesn't gain anything. You'll still have to deal with the '.new' file when it comes along if you've modified it to remove '.' from the PATH, and even worse, if you actually made the mistke of deleting the "~.sh" file from profile.d thinking it a quick and easy approach to making your change then the upgraded package will just silently add it back in and you'd be completely unaware that it has done so. I take your point about chmodding the file to disable the feature, but I'd still worry about the permissions being set back to executable (does a package update reapply permissions? I'm not sure off hand.)

Personally, I've always liked the /etc/rc.conf{,.local} concept as used in OpenBSD (and other places) which avoids much of this ugliness.

Last edited by GazL; 07-21-2013 at 06:50 AM.
 
Old 07-21-2013, 07:00 AM   #19
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Original Poster
Rep: Reputation: 145Reputation: 145
Quote:
Originally Posted by GazL View Post
... moving the adding of "." to the PATH into a profile.d file doesn't gain anything. You'll still have to deal with the '.new' file when it comes along if you've modified it to remove '.' from the PATH, ...
Sorry, I don't think "chmod -x" changes the file's time stamp. Why can't it be automatically upgraded?



Quote:
Originally Posted by GazL View Post
and even worse, if you actually made the mistke of deleting the "~.sh" file from profile.d thinking it a quick and easy approach ...
Everyone including me knows he/she should not delete but "chmod -x" the script.

Who thinks deleting the file is a quick and easy approach? This kind of person, if exists, must be as solitary as that who relies on "." to be in PATH.
.

Last edited by guanx; 07-21-2013 at 07:03 AM.
 
Old 07-21-2013, 08:01 AM   #20
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 2,995

Rep: Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737
I use, among others, The Generic Mapping Tools (GMT) for manipulating geographic data sets and, you know, drawing maps. I consider GMT "optional software" and it gets installed in /opt along with NetCDF, a set of libraries used by GMT. In the good old days -- before /etc/profile.d -- you had to either add PATH variables in /etc/profiel or in every user's ~/.profile to use GMT. PITA. Your other choice was to install GMT and NetCDF in the system directories (in /usr) or, if you kept /usr/local on a separate disk or partition, you could install it there but you still had to add PATH entries so /usr/local would be searched. Nuts to that. I don't like installing add-on software in the /usr tree; I prefer to keep distribution software (the stuff on the DVD) in the "system" directories and any additional software in /usr/local and any "applications" (like LibreOffice/OpenOffice, GMT and a few others) in /opt; just don't want that stuff spread all over the system directories. And, yes, I know that Slackware defaults to /usr/local, so I don't have add it to any profile.

So,
Code:
cat /etc/profile.d/gmt.sh
#!/bin/sh
#ident	"$Id$"
#	Purpose:	set local environment variables for GTM and netCDF
export GMTHOME="/opt/GMT"
export NETCDFHOME="/opt/netCDF"
export MANPATH="${MANPATH}:${GMTHOME}/man"
export MANPATH="${MANPATH}:${NETCDFHOME}/man"
# Set the local system $PATH:
PATH="${PATH}:${GMTHOME}/bin"
PATH="${PATH}:${NETCDFHOME}/bin"
works just fine.

Also, my systems all default to KornShell, so
Code:
cat /etc/profile.d/ksh.sh
#!/bin/sh
#	Purpose:	set local environment variables for KornShell
# Set the HOST environment variable
export HOST="`uname -n`"
# Set ksh93 visual editing mode:
if [ "$SHELL" = "/bin/ksh" ]; then
#  VISUAL=emacs		# ugh
#  VISUAL=gmacs		# double ugh
   VISUAL=vi		# ah, this one
fi
# Set a default shell prompt:
#PS1='`hostname`:`pwd`# '
# Do these anyway in case sombody uses a different shell
if [ "$SHELL" = "/bin/pdksh" ]; then
 PS1='! $ '
elif [ "$SHELL" = "/bin/ksh" ]; then
 PS1='${HOST}-${USER}-${PWD}: '
elif [ "$SHELL" = "/bin/zsh" ]; then
 PS1='%n@%m:%~%# '
elif [ "$SHELL" = "/bin/ash" ]; then
 PS1='$ '
else
 PS1='\u@\h:\w\$ '
fi
PS2='> '
export PS1 PS2
Simply taken from /etc/profile and edited a wee bit.

Really pretty nice that anything executable in /etc/profile.d gets executed at log in (down at the bottom of /etc/profile).

Individual user accounts have a .profile, a .kshrc and a .exrc:
Code:
cat .profile
#	set up default columns and lines
COLUMNS=80
LINES=40
export COLUMNS LINES
#	set up default group
GRPNAME=`groups | cut -d' ' -f1`
export GRPNAME
#	set up a good-size history
HISTSIZE=1000
export HISTSIZE
#	set up the ksh environment
ENV=${HOME}/.kshrc
export ENV
#	set up CVSROOT
CVSROOT=:pserver:trona@fubar.com:/usr/local/cvsroot
export CVSROOT
#	change the PATH a little
export PATH=.:${HOME}/bin:${PATH}
export INSTALL_BASE=${HOME}
export LLDATABASES=${HOME}/LifeLines:.
export LLPROGRAMS=.:/usr/local/share/lifelines
#	make COLUMNS and LINES the screen size
eval `resize`
Some of that stuff is meaningful to me and the folks I do some work for.
Code:
cat .kshrc
alias lc='/usr/bin/clear; /bin/ls ${LS_OPTIONS} -aCF'
alias ll='/bin/ls ${LS_OPTIONS} -al'
alias cls='clear'
alias hi='history -${LINES}'
alias rs='eval `resize`'
Code:
cat .exrc
set autoindent showmode showmatch
The one everybody will yell about is
Code:
#	change the PATH a little
export PATH=.:${HOME}/bin:${PATH}
Yup, current directory first, my home bin directory, then the system paths. Been doing it that way since the 1970's and I am always aware that the current directory is first and I am always aware of the potential hazards of so doing. I have always done and continue to do a lot of programming (write, test, dammit, edit, test, repeat) and I have a physical thing that makes it a little difficult to type the dot-slash combination so I live with the potential hazard. Plus I'm a little lazy too.

I don't recommend that to anybody else (I do recommend that the dot go at the end of the PATH environment though and would put both the dot followed ${HOME}/bin at the end in most cases).

A large part of working with these critters is being aware of what you're doing and why you're doing it and think before you whack the carriage return key (showing my age, eh?).

I only did it once, logged in as root (back when root logged in to the root)
Code:
rm -r * .bak
on 15 July 1981 at about 1315. Took until 2330 to reinstall the system and recover everything from the back up tapes. Oops.

Last edited by tronayne; 07-21-2013 at 08:07 AM.
 
Old 07-21-2013, 08:42 AM   #21
GazL
Senior Member
 
Registered: May 2008
Posts: 3,312

Rep: Reputation: Disabled
Quote:
Originally Posted by guanx View Post
Sorry, I don't think "chmod -x" changes the file's time stamp. Why can't it be automatically upgraded?
The config processing in doinst.sh relies on comparing md5sums and not timestamps, but yes, my doubts about chmodding were unfounded on reflection and the permissions would not be changed when a package is updated. I know we tend to use chmod -x to disable services, but using it to control something as simple as adding ":." to the end of the Path seems a little over-engineered to me. It will work, but I'd still go with something like a rc.conf.local instead.

Anyway, I can see we both have a very different view on the way this should be done and are never likely to completely agree on this so I'll shut up.
 
Old 07-21-2013, 10:25 AM   #22
NonNonBa
Member
 
Registered: Aug 2010
Distribution: Slackware
Posts: 61

Rep: Reputation: 21
@guanx

Personally, I've created a /local/etc/profile, where I put all the local environment stuff I want to set (PERLLIB, the PATH for the TexLive, etc.). This one is sourced into the top of my ~/.profile and of the /root/.profile. This way I do not need to worry about what is defined in the /etc/profile, since my local profile has always the last word.

I will consider what you suggest, as it appears that like many people here, I always use ./... to execute something from the cwd. The fact is it is IMHO more harmful (if we agree it is at all) in the user's perspective than in the root's one: I can retrieve on the internet most of the things root owns, while I can't do it with most of the things belonging to my regular user (mail, code, etc ).

I think I will simply add this in my local profile:

Code:
export PATH=$(echo $PATH | sed 's/:\.$//')
This should do the job.

Last edited by NonNonBa; 07-21-2013 at 10:26 AM. Reason: typo
 
Old 07-21-2013, 01:51 PM   #23
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Original Poster
Rep: Reputation: 145Reputation: 145
Quote:
Originally Posted by GazL View Post
The config processing in doinst.sh relies on comparing md5sums and not timestamps,
You are right. For the "etc" package it is done this way, but chmod doesn't change the md5sum either.

Quote:
Originally Posted by GazL View Post
but yes, my doubts about chmodding were unfounded on reflection and the permissions would not be changed when a package is updated. I know we tend to use chmod -x to disable services, but using it to control something as simple as adding ":." to the end of the Path seems a little over-engineered to me. It will work, but I'd still go with something like a rc.conf.local instead.
For "/etc/profile.d" the facility is already there. So that is not over-engineering. For "rc.conf.local" the facility is absent so this needs over-engineering.

Quote:
Originally Posted by GazL View Post
Anyway, I can see we both have a very different view on the way this should be done and are never likely to completely agree on this so I'll shut up.
My fault. I took it for granted that disabling something in "/etc/profile.d" should be a simple chmod. Never tought of the idea of removing the related script. It's my lack of imagination.
.

Last edited by guanx; 07-21-2013 at 01:53 PM.
 
Old 08-04-2013, 10:27 AM   #24
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Original Poster
Rep: Reputation: 145Reputation: 145
Solved.
Code:
Sat Aug  3 20:36:53 UTC 2013
a/etc-14.1-i486-1.txz:  Upgraded.
  Disabled '.' at the end of non-root path, but added new scripts
  in /etc/profile.d/ to allow enabling it systemwide if desired.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] I added a PATH to /etc/profile but "echo $PATH" says it's not there? cravengemetzel Linux - Newbie 6 12-30-2012 06:52 PM
unpredictable "delete" "move to trash" or "cut" file menu option dorianrenato Linux - General 3 11-28-2011 06:41 PM
can't locate object method "path" via package "Autom4te::Request" at/usr/bin/autom4te wjh513 Linux - Software 1 08-13-2010 02:31 PM
Where can I read about the difference between "..profile" and ".profile"? zorrokan Linux - Newbie 4 09-05-2007 01:26 AM
"Broken" envirnment variable (MANPATH) and "/etc/profile.d" question. ErV Slackware 3 03-20-2007 09:42 AM


All times are GMT -5. The time now is 08:48 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration