Bug 802757 - /etc/profile.d/less.sh overrides user-defined LESSOPEN value.
/etc/profile.d/less.sh overrides user-defined LESSOPEN value.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: less (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Vojtech Vitek
Fedora Extras Quality Assurance
: EasyFix, Patch, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-13 08:55 EDT by Dams
Modified: 2015-03-04 18:57 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-14 12:29:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dams 2012-03-13 08:55:40 EDT
Description of problem:
I'm using zsh, and I have defined a LESSOPEN environment variable in my ~/.zshenv, but the value is overridden by the system /etc/profile.d/less.sh


Version-Release number of selected component (if applicable):
less-444-2.fc16.x86_64

How reproducible: Always


Steps to Reproduce:
1. Install less & zsh
2. echo "export LESSOPEN=MYVALUE" >> ~/.zshenv
3. start zsh
4. echo $LESSOPEN
  
Actual results:
LESSOPEN is ||/usr/bin/lesspipe.sh %s


Expected results:
LESSOPEN should be set to MYVALUE.

Additional info:
A portable (POSIX) trivial fix for this issue would be to do :
[ -x /usr/bin/lesspipe.sh ] && export LESSOPEN="${LESSOPEN-||/usr/bin/lesspipe.sh %s}"

This would allow user-defined value of LESSOPEN including empty value (so that user can disable LESSOPEN).
Comment 1 Dams 2012-03-13 08:58:37 EDT
For the record, this bug affects Fedora 16, 17 and rawhide.
Comment 2 Vojtech Vitek 2012-03-14 20:27:47 EDT
Isn't this rather a zsh issue? Imho, the /etc/profile.d/* scripts should be read *before* the user's setting files (eg. ~/.zshenv), so the variables can be overridden?
Comment 3 Dams 2012-03-15 05:35:24 EDT
Maybe you're right, maybe not. Let me explain.

The root problem is actually the way the profile.d logic was implemented in zsh, yes. As you can see in the trace below (and as described in the zsh man pages), zsh configuration files are read in this order:

1. /etc/zshenv
2. ~/.zshenv
3. /etc/zshrc and 
4. ~/.zshrc

[dnade@dnade ~]# strace -e open zsh 2>&1|grep -E '(/etc|/home/)'
open("/etc/zshenv", O_RDONLY|O_NOCTTY)  = 3
open("/home/dnade/.zshenv", O_RDONLY|O_NOCTTY) = 3
open("/etc/zshrc", O_RDONLY|O_NOCTTY)   = 3
open("/etc/profile.d/PackageKit.sh", O_RDONLY|O_NOCTTY) = 3
open("/etc/profile.d/bash_completion.sh", O_RDONLY|O_NOCTTY) = 3
open("/etc/profile.d/ccache.sh", O_RDONLY|O_NOCTTY) = 3
open("/etc/profile.d/colorgrep.sh", O_RDONLY|O_NOCTTY) = 3
open("/etc/profile.d/colorls.sh", O_RDONLY|O_NOCTTY) = 3
open("/etc/profile.d/cvs.sh", O_RDONLY|O_NOCTTY) = 3
open("/etc/profile.d/gnome-ssh-askpass.sh", O_RDONLY|O_NOCTTY) = 3
open("/etc/profile.d/lang.sh", O_RDONLY|O_NOCTTY) = 3
open("/etc/profile.d/less.sh", O_RDONLY|O_NOCTTY) = 3
open("/etc/profile.d/udisks-bash-completion.sh", O_RDONLY|O_NOCTTY) = 3
open("/etc/profile.d/vim.sh", O_RDONLY|O_NOCTTY) = 3
open("/etc/profile.d/which2.sh", O_RDONLY|O_NOCTTY) = 3
open("/home/dnade/.zshrc", O_RDONLY|O_NOCTTY) = 3

So, the "/etc/profile.d" stuff is loaded at the "zshrc" stage", and redefines the user environment when it shouldn't. Moving the profile.d loading in /etc/zshenv may have some other nasty side effects: basically /etc/profile.d/*.sh also define some aliases which can alter ~/.zshenv behaviour and will make ~/.zshrc content non-portable - aliases should only be defined in "zshrc" files.

I think it's better to fix that in less.
Comment 4 Vojtech Vitek 2012-03-15 09:46:43 EDT
Sorry, I can't change anything what has been working for years (and rather decades). The /etc/profile.d/* scripts are standard place where (and when) to set the environment variables for tools such as LESS.

Also, I can't break the default behaviour for other shells (bash, ksh, csh, tcsh etc.) just to workaround different behaviour of zsh. Sorry.

Closing as WONTFIX. Please, feel free to reopen (and reassign to any other component) if you have some patches, or strong arguments why and what to fix. Thanks!
Comment 5 Vojtech Vitek 2012-03-15 09:47:58 EDT
By the way, why not to change the LESSOPEN variable in the ~/.zshrc file? It should work for you, right?
Comment 6 Dams 2012-03-15 10:36:04 EDT
I dont get it. I've *sent* a patch in my problem description. Why would you at least *not* change to this kind of variable setting LESSOPEN="${LESSOPEN-||/usr/bin/lesspipe.sh %s}" ? 

This would 1. be POSIX and work with bash/ksh/dash/etc. (csh/tcsh are off topic here) 2. be backward-compatible and 3. fix the issue ?

Instead of that you want to that every zsh user to adapt to a *flawed* behaviour ?

And for the record, cvs.sh is already doing it.
[anvil@gruyere ~]# cat /etc/profile.d/cvs.sh 
# change default from rsh to ssh for cvs command
export CVS_RSH=${CVS_RSH-ssh}

Please. Fix it.
Comment 7 Vojtech Vitek 2012-05-14 12:29:44 EDT
Your arguments convinced me to merge the patch. Thanks.
Comment 8 Dams 2012-05-14 15:29:22 EDT
Appreciated. Thank you very much.

Note You need to log in before you can comment on or make changes to this bug.