Sorry for the long summary, but this is a weird bug. A combination of circumstances yields the result that when less is used on source code files, control sequences are inserted in the displayed text which makes it hard to read. This will happen for people (like me) who have their own setting of the LESS environment variable (or who simply unset it) which does not contain the "-R" option to less. Here is the story that leads to this result: * If the LESSOPEN environment variable is set to a value beginning with "|", less will run the command specified in LESSOPEN as a pipe to filter files before displaying them. On most systems, if the SHELL environment variable is set, less will actually run the command formed by concatenating the value of SHELL, the string " -c ", and the value of LESSOPEN after the "|". * On Gentoo, LESSOPEN is set to "|lesspipe.sh %s" by /etc/env.d/00basic. * I use tcsh, so my SHELL environment variable is set to /bin/tcsh. * Thus, when I run the command "less foo.c", less actually runs the following command to get the data to display: "/bin/tcsh -c lesspipe.sh\ foo.c". (Actually, it passes this to popen, which will then run the equivalent of '/bin/sh -c "/bin/tcsh -c lesspipe.sh\ foo.c"'. But this additional detail doesn't matter.) * tcsh sources /etc/csh.cshrc on startup, including for non-interactive shells. * /etc/csh.cshrc loads /etc/csh.env, which collects together in csh-style syntax the environment settings in the files in /etc/env.d. * The file /etc/env.d/70less specifies that LESS should be set to "-R -M". * So lesspipe.sh gets run with an environment that specifies LESS="-R -M". As a result, it decides that it is safe to colorize its output, because "-R" is in the value for LESS. And it does colorize the output for filenames with certain extensions. This colorization is done by inserting terminal escape sequences in the output. * My LESS environment variable (which I set myself (and have done so for years and years before Gentoo even existed), thereby overriding the setting in /etc/csh.env) does not contain "-R". * Thus, less is running with a different value of the LESS environment variable than is visible to lesspipe.sh, but lesspipe.sh is assuming the value of LESS that it sees is the same as the value of LESS that less sees. (Note that lesspipe.sh is also assuming that no command-line options were used to override the settings in LESS.) * The result is that less is running in a mode where it does not allow sending escape sequences through to the terminal, but the output less gets from lesspipe.sh contains escape sequences. These escape sequences are displayed in an extremely ugly fashion that makes the output unreadable. Whew, sorry for the long description! It is not completely clear to me exactly who/what is to blame for this. I think the main problem is that it is not legitimate for /etc/csh.cshrc to set lots of environment variables for non-interactive shells. The corresponding /etc/profile.env for Bourne-shell style shells is not loaded at all for non-interactive invocations of bash, so I think csh-style shells should be treated the same. This means that the loading of /etc/csh.env should be moved to the end of /etc/csh.cshrc, after the test for whether the shell is interactive. Reproducible: Always Steps to Reproduce: 1.Set your LESS environment variable to a value not containing "R" or "r" (or unset it.) 2.Run "less foo.c" for some source file named "foo.c". 3.Observe zillions of ugly escape sequences making the screen hard to read or unreadable. Actual Results: You can now see zillions of ugly escape sequences making the screen hard to read or unreadable. Expected Results: The screen should be readable, not obscured by lots of escape sequences. Gentoo Base System version 1.12.0_pre7 Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.8.1-co-0.6.2-pre1 i686) ================================================================= System uname: 2.6.8.1-co-0.6.2-pre1 i686 Intel(R) Pentium(R) M processor 1100MHz dev-lang/python: 2.2.3-r1, 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy distlocks moo sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://gentoo.mirror.solnet.ch http://mir.zyrianes.net/gentoo/ http://gd.tuwien.ac.at/opsys/linux/gentoo/ http://ds.thn.htu.se/linux/gentoo" MAKEOPTS="" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/extra/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X Xaw3d acl apache2 bdf bitmap-fonts bonobo bzip2 cairo crypt djvu dvi dynagraph eds emacs emacs-w3 emboss escreen esd etwin fam firefox font-server fortran fpx gcj gd gd-external gif glep glitz graphviz gstreamer gtk gtk2 guile imagemagick imlib ipv6 java jbig jpeg latex lcms leim libg++ libwww lua lzw-tiff mad mailwrapper md5sum mmx motif mozdevelop mozilla mozsvg mozxmlterm mp3 mpeg ncurses nodrm nptl nsplugin objc ogg oggvorbis opengl pam pam_chroot pam_console pam_timestamp perl php png python readline samba sdk slang snmp socks5 spell sse ssl syslog t1lib tcltk tcpd tetex tiff toolbar truetype truetype-fonts type1-fonts unicode vorbis wmf xinerama xml2 xmms xprint xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
reassigning to tcsh maintainer.
I'm trying to find evidence that bash indeed doesn't source the /etc/profile.env file for non-interactive shells. If it doesn't then it is clear to me that csh.env should (and hence will) only be sourced for interactive shells.
Ok, Joe, I dived a bit more into this problem. First off, what I forgot, is to thank you for your efforts to spell it out in such detail. Can I ask you what version of tcsh you are using. It doesn't matter for this problem, but not so long ago I have created tcsh-6.14-r1, which is a completely different installation, which resolves many bugs previously reported by users. I'd like to fix this issue too before requesting the arch teams to mark 6.14 stable. Point of doubt I have now, is that if I look at csh.cshrc provided by 6.14-r1 then there are in general three blocks: 1) sourcing csh.env, 2) setting path + prompt and 3) sourcing extensions. Of these three blocks, everything is unconditional except setting the prompt. Question I consider now is whether sourcing of extensions should also be depending on interactive shell or not, considering I make the csh.env block conditional on being interactive or not. Since you seem to have a well ordered opinion on these issues, can you advise on what the best choice would be?
Thanks for thanking me for my bug report! Not often that that happens. :-) I'm running app-shells/tcsh-6.14-r1. I noticed when I upgraded to that ebuild that you had changed a bunch of things in the configuration files. Unfortunately, I don't remember most of my thoughts about it. I think I didn't care too much one way or the other because I override most of it anyway. :-) I mainly made sure to override anything new that I didn't like. There were some nice touches in the older setup that I copied into my private settings when they were removed from the ebuild, but I didn't think any of them were terribly important, so I don't even remember which ones they were. After my bizarre experience with the lessopen.sh interaction, I do think that the non-interactive tcsh should follow the non-interactive sh. So I guess that non-interactive tcsh should not (at least by default) load any non-essential extensions. I hope this helps.
Created attachment 72590 [details, diff] csh.cshrc.patch k. The attached patch contains the changes made to solve this problem I think. Could you take a look at the patch and possibly test it to see if it works? If so, I'll be happy to create tcsh-6.14-r2 and commit it.
Checked in 6.14-r2. I consider this bug fixed.
