Solved more or less

[noodlefling]

I recently set up a 12.1 box to test. All my existing boxes are 11.3.

One unexpected effect seems to be that things like man and freebsd-update now use less instead of more when dumping output. Or they're doing something similar to that.

So when I did my first freebsd-update and it just sat there saying "(END)", I kept hitting ENTER to make it go away and nothing happened. I thought I'd lost my shell connection. Eventually I just started hitting random keys and figured out what was going on.

I can certainly evolve and learn to hit q instead, but is there a place that controls this in case I want to stay in dinosaur mode at least until all my servers are running the same version?

 

[SirDice]

In your's and root's ~/.cshrc:

setenv  PAGER   less

It's the PAGER environment variable that tells the system what to run.

 

[noodlefling]

Thanks, that fixed it!

Sorry for such a basic question, but searching for simple words like "more" and "less" is pretty tough.

By the way, I thought I would be clever and put the change in /etc/csh.cshrc, but that didn't change anything. Apparently, the system plunks down a default ~/.cshrc at some point, which of course overrides any system default. So I suppose future accounts will have the new default, although it seems I can't fix all accounts at once in a sensible way.

Oh well, not the end of the world. That's what happens when you want to deviate from the default.

Thanks for the quick and helpful response, as always!

 

[SirDice]

I thought I would be clever and put the change in /etc/csh.cshrc, but that didn't change anything.

It's loaded but the variable gets overruled by the user's ~/.cshrc.

   Startup and shutdown
       A login shell begins by executing commands from the system files
       /etc/csh.cshrc and /etc/csh.login.  It then executes commands from
       files in the user's home directory: first ~/.tcshrc (+) or, if
       ~/.tcshrc is not found, ~/.cshrc, then the contents of ~/.history (or
       the value of the histfile shell variable) are loaded into memory, then
       ~/.login, and finally ~/.cshdirs (or the value of the dirsfile shell
       variable) (+).  The shell may read /etc/csh.login before instead of
       after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or
       ~/.cshrc and ~/.history, if so compiled; see the version shell
       variable. (+)

       Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on
       startup.

Apparently, the system plunks down a default ~/.cshrc at some point, which of course overrides any system default.

When you create an account and the home directory a couple of files from /usr/share/skel/ are copied to that home directory. These are known as skeleton files and are basically templates that get automatically copied when you create an account.

 

[noodlefling]

When you create an account and the home directory a couple of files from /usr/share/skel/ are copied to that home directory.

Ah, that's where those are hidden!

So, I guess the solution should be to add a ~/.cshrc.user to override without breaking the default. I changed ~/.cshrc, which would seem to be the wrong thing to do, or at least potentially confusing. I try to keep /usr stuff that isn't /usr/local clean.

It would be nice to be able to flip one switch and change the behavior of every account, but this was a good lesson in any case.

 

[SirDice]

The skeleton files in /usr/share/skel/ are meant to be adjusted to your environment. That's their entire purpose.

It would be nice to be able to flip one switch and change the behavior of every account, but this was a good lesson in any case.

The PAGER environment variable is specifically meant so users can pick their own preference. Same as the EDITOR variable (which defaults to vi(1)).

 

[noodlefling]

The skeleton files in /usr/share/skel/ are meant to be adjusted to your environment. That's their entire purpose.

But anything in /usr/share potentially gets wiped out with a new version of the OS, right?

Also I just realized that ~/.cshrc.user is something specific to our servers that was set up ages ago and I never questioned. I always thought it was a part of base FreeBSD.

So, I guess the real "correct" thing is to change ~/.cshrc. If I change the skel files, those will get washed out with system upgrades, so it's better to be in the habit of manually changing ~/.cshrc when necessary. I think.

 

[SirDice]

But anything in /usr/share potentially gets wiped out with a new version of the OS, right?

Never had that happen, but it's always a good idea to make backups of course.

Also I just realized that ~/.cshrc.user is something specific to our servers that was set up ages ago and I never questioned.

I actually thought you made a typo. But sure, I can understand how and why they added it. It's fairly easy to implement but there's rarely a reason to do so.

so it's better to be in the habit of manually changing ~/.cshrc when necessary

That's what it's there for. To allow you to customize your own environment.

 

[noodlefling]

Never had that [/usr/share getting wiped out on upgrade] happen, but...

Huh. I guess I figured /usr/local is magically protected because I always put it on its own filesystem, and have always considered anything else under /usr to be potential fodder. I back up everything, of course, but if I were moving to a new system, I wouldn't think to move anything from /usr/share over. /usr/local/share is of course another matter, and I regularly change files in there.

And I understand that the purpose of ~/.cshrc is to customize your own environment, but I was looking for a solution where the default could be easily changed for accounts that have not explicitly overridden a given default. But given that this variable set up from a skel file that plunks down an override without any user interaction, I don't see a way to accomplish that without removing the line from the skel file. Which maybe I'll do.