csh command history

Hi! I am using csh and I notice that I cannot see the command history. That is, I open a terminal, write a command, close it, and when I reopen it, it is clean. No history. How can I have the history there to speed up the writing?
 
Pushing the up arrow brings back the last commands I used as root. That's true for what I type in the terminal emulator if I exit the WM to the login terminal and work from there.
 
.history Does not exist. When I close my terminal and reopen it, it is empty without history of everything I typed before
Please try touch $HOME/.history -- I tried this on my own system and it worked.

My non-root user account was originally created with /bin/sh as the shell. The sh shell does not use a .history file, and when I ran chsh -s /bin/csh it did not create such a file, but when I created the file using the touch command, it started working immediately.

You might need to log out and log in again; you'll want to do that anyway, to see if it starts remembering your history from the previous login session when you press the up-arrow key.
 
I do sometimes get a sense of some things (not everything) missing from history, but I can never put my finger on it.



… log out and log in again; you'll want to do that anyway, to see if it starts remembering your history from the previous login session …

Ah! So, is ~/.history written only at exit time or log out time?

I just realised, the last update to the file was more than six hours ago:

Code:
% ls -hl .history
-rw-------  1 grahamperrin  grahamperrin    29K 10 Jul 20:48 .history
% date
Sun 11 Jul 2021 02:40:54 BST
%
 




Ah! So, is ~/.history written only at exit time or log out time?

I just realised, the last update to the file was more than six hours ago:

Code:
% ls -hl .history
-rw-------  1 grahamperrin  grahamperrin    29K 10 Jul 20:48 .history
% date
Sun 11 Jul 2021 02:40:54 BST
%
I think so but didn't actually check. I did notice that it remembered the commands I had entered during that login session before I created the file.

As the non-root user, first I entered the chsh command, and, as expected, nothing had changed: I still had the $ prompt, echo $SHELL still output /bin/sh, and I was still using the /bin/sh commands (for example, x=x did not produce a syntax error). So I then logged out and back in. Lo and behold, I had the /bin/csh shell and the % prompt, but no .history file, so I created it, logged out and back in again -- call this login session number 3. The history file had all the commands from login session number 2, but contained no commands from login session number 1.

This was all more or less as expected. Using the sh shell, it always remembers all the commands from the present login session, but none from previous login sessions. What I infer from that is that the sh shell keeps all the present session's commands in memory, but then loses that memory when you log out, whereas the csh shell writes them in the ~/.history file.

The /bin/bash shells I use in Linuxland also keep history, but in ~/.bash_history files. I don't use any other shells. I used to use ksh on AIX systems, but that was many years ago, and I could be mistaken, but I don't remember any of those old unixes keeping any history at all, even for the current login sessions. SCO used /bin/sh IIRR. I don't remember what shell the DEC systems used.

Looking at my /bin/bash and /bin/csh history files right now, the last commands in those files is consistently exit in four of those files. Just guessing-- maybe you are shutting down your system without logging out some times?
 
It's probably true that in most (if not all) cases where I have been puzzled by sparseness of history, I had run (typically in ttyv1):

shutdown -r now

For the future, I'll try to remember to exit then log in before shuttting down …
 
Last edited:
It's probably true that in most (if not all) cases where I have been puzzled by sparseness of history, I had run (typically in ttyv1):

shutdown -r now

For the future, I'll try to remember to exit then log in before shuttting down …
In FreeBSD, [CTRL][ALT][DEL] from a login prompt gives what appears to be a proper shutdown and reboot. I'm not sure if that works in Linux or not, because I never run Linux headless, so I just use the DE's [Restart] button instead.
 
I found some commits. In chronological order:
  1. <{link removed}> move all functions related to shutting down to one file called kern_shutdown.c …
  2. <{link removed}> Make it possible to pass boot()'s flags to shutdown_nice() …
  3. <{link removed}> init: Only run /etc/rc.shutdown if /etc/rc was run. …
  4. <{link removed}> Clean up shutdown_nice(). Just send the right signal to init(8). Right now, init(8) cannot distinguish between an ACPI power button press or a Ctrl+Alt+Del sequence on the keyboard. …
kern_shutdown.c « kern « sys - src - FreeBSD source tree <{link removed}>
 
Last edited:
Interesting discussion. It's often considered a bit of a security hole to have persistent shell history, so I've always had an "unset savehist" in my init file.

Also, if you are in a desktop environment, you probably need to close all term sessions or logout to force the save to file.
 
Thanks,

With csh(1) you can also force a history save with history -S.

Below, what are the mysterious first word and second word?

Code:
savehist
    If set, the shell does `history -S' before exiting.  If the
    first word is set to a number, at most that many lines are
    saved.  (The number should be less than or equal to the number
    history entries; if it is set to greater than the number of
    history settings, only history entries will be saved) If the
    second word is set to `merge', the history list is merged with
    the existing history file instead of replacing it (if there is
    one) and sorted by time stamp and the most recent events are
    retained.  If the second word of savehist is `merge' and the
    third word is set to `lock', the history file update will be
    serialized with other shell sessions that would possibly like
    to merge history at exactly the same time. (+)
 
Last edited:
Interesting discussion. It's often considered a bit of a security hole to have persistent shell history, so I've always had an "unset savehist" in my init file.

Also, if you are in a desktop environment, you probably need to close all term sessions or logout to force the save to file.
Kind of makes a case for using /bin/sh for security's sake. Which reminds me, after touch ~/.history one should probably execute chmod 600 ~/.history to tighten security on one's history file.

In my test case I just deleted the ~/.history file and ran chsh -s /bin/sh via my test system's non-root user, to revert back to using the relatively more secure sh shell.
 
  • Like
Reactions: mer
I love tcsh but the history is a nightmare. I've tried a whole bunch of stuff to get it to save right but it never does.

open term, type 1 [enter] 2 [enter]
open a second term, type 3 [enter] 4 [enter]
back to first term, type 5 [enter] 6 [enter]
close term2, close term 1.

Open new term, history:
1
2
5
6

The second terms history disappears rather than merging in. It seems like the histfile is locked by the first instance to start - no idea if this is how it works because I'm too lazy to read manpages and googling offers very little help for tcsh these days.

No amount of binds with history -s, prealias, etc make it work how I like.
 
… tcsh …

… I have ctrl+d set to exit

I have not knowingly set it, but it seems to be effective.

With tcsh already my preferred shell for the root user, things seem OK for me, since learning from SirDice

With multiple tabs in Konsole, at a root command prompt I keyed Up and observed:

root@mowa219-gjp4-8570p:~ # pkg provides xkeyboard-config

After keying Control-D I brought forward a non-root tab, su -, entered the passphrase then keyed Up and observed the same ☑
 
I have not knowingly set it, but it seems to be effective.
It's the default keybinding.
Code:
"^D"           ->  delete-char-or-list-or-eof
It has multiple meanings, it also acts as a delete and it shows a list (when using completion, bash uses double TAB for that) too.
 
I love tcsh but the history is a nightmare. I've tried a whole bunch of stuff to get it to save right but it never does.

open term, type 1 [enter] 2 [enter]
open a second term, type 3 [enter] 4 [enter]
back to first term, type 5 [enter] 6 [enter]
close term2, close term 1.

Open new term, history:
1
2
5
6

The second terms history disappears rather than merging in. It seems like the histfile is locked by the first instance to start - no idea if this is how it works because I'm too lazy to read manpages and googling offers very little help for tcsh these days.

No amount of binds with history -s, prealias, etc make it work how I like.

Code:
set savehist = (2000 merge)

It has been reported that tcsh(1) (as of version 6.21) does not handle the merge option for the savehist shell variable correctly: Astron-tcsh-mailing-list . The error has been corrected in tcsh version 6.22. Starting at 2021-03-14 tcsh 6.22 has been imported into -CURRENT: source-log.

Any reasonable expectations or educated guess if tcsh 6.22 will find its way into 13.X-RELEASE?
I'd guess unlikely but I do not have any knowledge or experience how such things tend to develop.
 
Any reasonable expectations or educated guess if tcsh 6.22 will find its way into 13.X-RELEASE?
It's been merged into 13-STABLE some time ago, so it will be included in 13.1-RELEASE.
Code:
root@molly:~ # tcsh --version
tcsh 6.22.04 (Astron) 2021-04-26 (x86_64-amd-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec
root@molly:~ # uname -a
FreeBSD molly.dicelan.home 13.0-STABLE FreeBSD 13.0-STABLE #33 stable/13-n246220-a7761d19dac: Sat Jul 10 14:23:54 CEST 2021     root@molly.dicelan.home:/usr/obj/usr/src/amd64.amd64/sys/MOLLY  amd64

It's also merged in 12-STABLE, so 12.3-RELEASE will have it too.
 
Reading <{link removed}> alongside <{link removed}>

Is this an example of stable/11 simply receiving less attention?

(Not complaining. I'm just curious.)
 
Last edited:
Back
Top