Re: etcupdate -B, /.cshrc and /.profile

[Jamie Landeg-Jones]

Sulev-Madis Silber  wrote:

> on why removing those, i for example only use /etc/csh.cshrc so i don't need 
> others

Exactly the same here!

Re: etcupdate -B, /.cshrc and /.profile

[Sulev-Madis Silber]

on why removing those, i for example only use /etc/csh.cshrc so i don't need 
others

Re: etcupdate -B, /.cshrc and /.profile

[Jamie Landeg-Jones]

Mike Karels  wrote:

> Both sets have been present since 4.3-Reno in 1990, although they were
> apparently not links.

Well before my time!
>
> > Removing them both is one of the first things I do when I install a new
> > system from install-media.
>
> Why?

Because I don't use them

> > If etcupdate is now removing them, maybe there has been an update to the src
> > distribution / mntree so that this historical weirdness has finally been 
> > removed?
>
> It is not weird.  /.profile and /.cshrc are used in single-user mode, the ones
> in /root are used for root logins.

Ah yeah, that would make sense, I guess. I remember my first unix systems,
the default home for the root login was / so there was no /root duplication of
those files.

> > If you have a /root/.cshrc and /root/.profile, try doing an ls -c on them to
> > see if their changed-date is when you did the etcupdate.
>
> They were modified by the removal of $FreeBSD$ a few days ago at the next
> etcupdate.

A. That idea won't work then!

Cheers

Re: etcupdate -B, /.cshrc and /.profile

[Jamie Landeg-Jones]

Graham Perrin  wrote:

> If I recall correctly, a few hours ago etcupdate -B resulted in removal 
> of two files:
>
> /.cshrc
> /.profile
>
> Is this degree of checking/removal a novelty?
>
> (I can't recall the files' contents, or when I created them. I guess 
> that I carelessly created them as dot files months ago without realising 
> that I wasn't at ~, I don't mourn their loss.)

For as long as I can remember, (as far back as FreeBSD 2.2.7 in 1998) all
FreeBSD installs have /.cshrc and /profile as hardlinks to /root/.cshrc and
/root/.profile .

Removing them both is one of the first things I do when I install a new
system from install-media.

If etcupdate is now removing them, maybe there has been an update to the src
distribution / mntree so that this historical weirdness has finally been 
removed?

If you have a /root/.cshrc and /root/.profile, try doing an ls -c on them to
see if their changed-date is when you did the etcupdate.

Jamie

Re: etcupdate -B, /.cshrc and /.profile

[Steve Rikli]

On Thu, Aug 17, 2023 at 07:17:20PM +0100, Graham Perrin wrote:
> If I recall correctly, a few hours ago etcupdate -B resulted in removal of
> two files:
> 
> /.cshrc
> /.profile
> 
> Is this degree of checking/removal a novelty?
> 
> (I can't recall the files' contents, or when I created them. I guess that I
> carelessly created them as dot files months ago without realising that I
> wasn't at ~, I don't mourn their loss.)

I suspect you didn't create them, at least not directly or manually; my
system still has them at the moment, and they appear to be the same
from /root/ :

$ uname -mrv
13.2-STABLE FreeBSD 13.2-STABLE stable/13-n255938-fec383bb5385 GENERIC amd64

$ ls -lai /.profile /root/.profile /.cshrc /root/.cshrc 
5 -rw-r--r--  2 root  wheel  1023 May 12  2022 /.cshrc
7 -rw-r--r--  2 root  wheel   507 May 12  2022 /.profile
5 -rw-r--r--  2 root  wheel  1023 May 12  2022 /root/.cshrc
7 -rw-r--r--  2 root  wheel   507 May 12  2022 /root/.profile

I think they were installed by FreeBSD rather than created. My other systems
which have been periodically upgraded over time have the same situation.

Cheers,
sr.

etcupdate -B, /.cshrc and /.profile

[Graham Perrin]

If I recall correctly, a few hours ago etcupdate -B resulted in removal 
of two files:


/.cshrc
/.profile

Is this degree of checking/removal a novelty?

(I can't recall the files' contents, or when I created them. I guess 
that I carelessly created them as dot files months ago without realising 
that I wasn't at ~, I don't mourn their loss.)


Re: the manual pages below, I'm reminded of where files _should_ be.