Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#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 BugsMacPorts 1.7.1
Owner: changed from macports-tickets@… to blb@…
Status: newassigned

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.

comment:2 Changed 16 years ago by blb@…

Resolution: fixed
Status: assignedclosed

Fixed in r43946 (trunk) and r43948 (1.7 branch).

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.