Summary: | /etc/csh.cshrc loads /etc/csh.env even when non-interactive, causes less's lesspipe.sh (via LESSOPEN) to colorize when it shouldn't | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joe Wells <sllewbj> |
Component: | [OLD] Unspecified | Assignee: | Fabian Groffen <grobian> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | csh.cshrc.patch |
Description
Joe Wells
2005-09-03 19:23:49 UTC
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. |