Bug 802757

Summary: /etc/profile.d/less.sh overrides user-defined LESSOPEN value.
Product: [Fedora] Fedora Reporter: Dams <anvil>
Component: lessAssignee: Vojtech Vitek <vvitek>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dmaphy, hripps, james.antill, vvitek
Target Milestone: ---Keywords: EasyFix, Patch, Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-14 16:29:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dams 2012-03-13 12:55:40 UTC
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 12:58:37 UTC
For the record, this bug affects Fedora 16, 17 and rawhide.

Comment 2 Vojtech Vitek 2012-03-15 00:27:47 UTC
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 09:35:24 UTC
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 13:46:43 UTC
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 13:47:58 UTC
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 14:36:04 UTC
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 16:29:44 UTC
Your arguments convinced me to merge the patch. Thanks.

Comment 8 Dams 2012-05-14 19:29:22 UTC
Appreciated. Thank you very much.