I do not know what happened, but I have a vague recollection of having seen this before. Those lines should have terminated with a trailing “\” to denote continuation.
This is what that section (lines 148-179) looks like on one of my Leap-42.3 systems:
#
# Make path more comfortable
#
if test -z "$PROFILEREAD" ; then
PATH=/usr/local/bin:/usr/bin:/bin
if test "$HOME" != "/" ; then
for dir in $HOME/bin/$CPU $HOME/bin ; do
test -d $dir && PATH=$dir:$PATH
done
fi
if test "$UID" = 0 ; then
test -d /opt/kde3/sbin && PATH=/opt/kde3/sbin:$PATH
PATH=/sbin:/usr/sbin:/usr/local/sbin:$PATH
fi
for dir in /usr/X11/bin \
/usr/bin/X11 \
/usr/X11R6/bin \
/var/lib/dosemu \
/usr/games \
/opt/bin \
/opt/kde3/bin \
/opt/kde2/bin \
/opt/kde/bin \
/usr/openwin/bin \
/opt/cross/bin
do
test -d $dir && PATH=$PATH:$dir
done
unset dir
export PATH
fi
It seems that, the RPM rules in the ‘aaa_base’ package ensure that, any administrator changes to “/etc/profile” are preserved – without a “/etc/profile.rpmnew” being written.
A “diff -cw profile profile.good” would have been helpful.
The workaround for such cases is, to download the .rpm package file and extract the miscreant file with something such as KDE “Ark”.
Then, the decision can be made to either edit the differences into the existing system file or, to simply replace it.
[HR][/HR]As a thought, a system upgrade possibly drops a ‘.rpmnew’ copy into ‘/etc/’ …
Given eng-int’s investigation it seems that, the RPM rules in the ‘aaa_base’ package do not provide a ‘.rpmnew’ copy, which, IMHO, defeats the possibility to simply recover from any changes inadvertently made to “/etc/profile”.
It also seems to be a contradiction to the SUSE comment in “/etc/profile”:
# PLEASE DO NOT CHANGE /etc/profile. There are chances that your changes
# will be lost during system upgrades. Instead use /etc/profile.local for
# your local settings, favourite global aliases, VISUAL and EDITOR
# variables, etc ...
if test "$is" != "ash" ; then
#
# And now let's see if there is a local profile
# (for options defined by your sysadmin, not SuSE Linux)
#
test -s /etc/profile.local && . /etc/profile.local
fi
I can verify.
So, after the testing I’ll describe my solution (skip to end of this post)
On one of my machines, it somehow had escaped my attention and was still 42.1.
So, taking advantage of the situation, I inspected /etc/profile and found that the trailing back-slashes were there (not missing),
Then to test the perserverance of edits to this file I added a comment to the end of this file and then
Upgraded the machine (from 42.1 to 42.3).
The test comment inserted into /etc/profile survived the upgrade.
I then tested for replacing /etc/profile with a forced re-install.
First, to determine and verify the package which contains the file I ran
zypper se -x --provides /etc/profile
Verifying the package is aaa_base, I then ran
zypper in -f aaa_base
Inspecting the file /etc/profile again, I still found the inserted test comment.
So, apparently someone has gone out of its way to make sure that the /etc/profile is not over-written.
This may be useful in some cases (I remember a Forum thread which discussed where the official documentation for some app instructed direct edits to /etc/profile) but as we can see in this thread that the behavior is unexpected.
I’m an old fashioned traditionalist with respect to “/etc/profile”.
In my opinion, the distro should not provide “/etc/profile”. That file properly belongs to the local system administrator, not to the vendor.
The distro should provide “/etc/profile.example”, but not “/etc/profile”.
At the end of a clean install, if there is no “/etc/profile”, then it should copy “/etc/profile.example” to “/etc/profile”. But that would be done as a final install step, not as part of a package install.
If done that way, a forced update of “aaa_base” would replace “/etc/profile.example” with the correct version. It would be up to the local system administrator to then copy that to “/etc/profile” if desired.
Most linux distros seem to get this wrong (in my opinion).
As an old-fashioned DEC Ultrix, DEC RSX-11M, DEC RSTS/E and DEC VAX/VMS traditionalist and, an openSUSE fan, my personal view is, the system should in 99.999% of the cases simply install and run – without any additional effort being needed to set-up the system – apart from the user definitions – which may be available (these days) via LDAP …
I find that, the SUSE solution to have administrator changes to ‘/etc/profile’ being included via ‘/etc/profile.local’, is an acceptable solution to the dilemma of some sites NEEDING to personalise the default system profile …
I’m of the opinion that everything should be modularized to support maximum flexibility and versatility.
To do this,
There should always be a commonly accepted default base, inviolate.
This means that no one should make modifications to this.
Then there should be a way to <separately> modify what is basic.
For most distros and including openSUSE today,
You have 2 ways to do this…
Create an /etc/profile.local file which contains your customizations
Create a script file that is then placed in /etc/profile.d/
By separating what is default and what is custom, there is no need to document changes or worry about lost configurations, all customizations are easy to identify. Editing /etc/profile can result in changes and machine settings impossible for anyone to find later.
I haven’t actually tried to use any of the two methods to disable, remove or modify a default setting in /etc/profile,
I’ve only added settings…
If someone were to edit /etc/profile directly though, I’d suggest leaving some almost unmistakable indication some change was made, like saving a copy of the default as /etc/profile.original
That way, hopefully someone sharp-eyed would notice the unusual file and start to ask questions… But of course, this still wouldn’t be certain.
Patch openSUSE-2018-331 dated Thursday the 5th of April 2018:
This update for aaa_base provides the following fixes:
- Support changing PS1 even for mksh and user root. (bsc#1036895)
- Unset unused variables on profile files. (bsc#1049577)
- Unset id in csh.cshrc instead of profile.csh. (bsc#1049577)
- Allow that personal ~/.bashrc is read again. (bsc#1052182)
- Avoid that IFS becomes global in _ls ksh shell function. (bsc#1079674, bsc#1025743)
- Replace "cat > file" by "mv -f ... file" in pre/post to fix issues with clients
having these files mmapped. (bsc#1038549)
