#17588 closed defect (fixed)
macports 1.7rc1 writes path variable to .tcshrc even when a .cshrc is present
| Reported by: | north@… | Owned by: | blb@… |
|---|---|---|---|
| Priority: | Low | Milestone: | MacPorts 1.7.1 |
| Component: | base | Version: | 1.7.0 |
| Keywords: | Cc: | ||
| Port: |
Description
One of those infuriating habits of oldtimers is still using a million year old .cshrc file even though running tcsh -- which still honors the .cshrc file. Previous versions of macports wrote to my .cshrc, but this new rc1 creates a .tcshrc where one was not present, overriding the existing .cshrc (rendering it temporarily moot and creating much surprise!)
Obviously easily cured, but testing for the presence of .cshrc would be a nice touch.
Change History (3)
comment:1 Changed 16 years ago by blb@…
| Milestone: | Port Bugs → MacPorts 1.7.1 |
|---|---|
| Owner: | changed from macports-tickets@… to blb@… |
| Status: | new → assigned |
comment:2 Changed 16 years ago by blb@…
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:3 Changed 16 years ago by rdm@…
I know about dotfiles, but it still took me a while to track down why my sessions were suddenly getting initiated wrong. Ended up reading the tcsh man page, making a guess, and finding this delightful little "present" from MacPorts. Grumble.
Note: See
TracTickets for help on using
tickets.
Handling of dotfiles can definitely be improved, as it should really be checking for .bash_profile and .bash_login for bash users as well. For the time being the general idea is to take care of those who don't know much about dotfiles and let those who do handle it manually since they probably know what's going on.