Micah Cowan wrote: > Bash does set SHELL, but (1) only if it's not already set, and (2) > always to the user's login shell, as specified in /etc/passwd > (therefore, it's not always bash: if the user's login shell is > /bin/tcsh, bash will actually set SHELL to /bin/tcsh). > > The solution feels like a hack, but I'm not sure there's a better way to > do this. We could make lesspipe check the environment for variables such > as BASH or BASH_VERSION, but then if we get the reverse situation > (invoking tcsh from a bash login), we might get the same problem (though > we don't have a .tcshrc in /etc/skel to deal with, I suppose). >
The best solution would certainly be to modify lesspipe and lessfile. They should have special options to override the env settings, e.g. calling it as lesspipe -s or lesspipe -c , depending on whether you are in a .profile or in a .tcshrc (actually you wouldn't call it in an .cshrc, but a .login). This would be a clean solution, but it would not be backwards compatible to old versions of less. It would fail for users who did not upgrade the less package. regards Hadmut -- /etc/skel/.bashrc - lesspipe problem https://launchpad.net/bugs/58103 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
