Solved CSH prompt customization

[Myersj281]

As this question is regarding a package in the base system, this seemed like the best place to ask. If not, just recomend a new place to ask and I'll move it there.

I'm attempting to migrate from ZSH to CSH and the configuration is proving to be a bit difficult. In ZSH, I have these lines

PROMPT='%n@%m %d: '
RPROMPT='[%?] %*'

which produce this output in the terminal

joshua@FreeBSD /Users/joshua:                              [0] 19:19:57

I've attempted to just simply copy and paste the '%n@%m %d: ' and '[%?] %*' portions, but it doesn't quite translate. This resulted in a prompt that looks like this:

joshua@FreeBSD 08:                                                  [0] %*

I guess "08" is today (The 8th), but after that it makes no sense to me at all. I've tried searching Google and found Stack Exchange threads for similar issues regarding CSH, but nothing for this particular isssue. It's probably just the search terms that I tried, but how can I translate this to work with CSH? Also, are there any good guides similar to this one for ZSH? I attached the two RC files below for reference.

 

[gotnull]

I don't think you'll be able to reproduce a prompt right and prompt left in csh that's a zsh thing.
A good place to start with customization:

Share your .tcshrc file

I decieded to start this thread after reading the thread 'Which shell do you use?'. I'll start, mine is below. # .cshrc - csh resource script, read at beginning of execution by each shell # # # -- Set up command aliases alias searchports 'find /usr/ports -type f -name pkg-descr | xargs...

forums.freebsd.org

Also on your system:
cat /usr/share/examples/csh/dot.cshrc

A good site for unix stuff:

Csh - the C Shell

 

[Erichans]

[...] I'm attempting to migrate from ZSH to CSH and the configuration is proving to be a bit difficult.

Why?
If you are used to the modern zsh(1), its documentation and its support, then you'll most likely be disappointed; perhaps possibly with the exception on very underpowered systems. In general zsh(1) seems so much better. Note that a lot, if not most, FreeBSD (base system's) shell programming happens in sh(1) (i.e. the "POSIX" shell, see for example Sh - the POSIX Shell for a good tutorial). FreeBSD sh(1) is gaining ground as it is getting more (interactive) niceties, for example better history support (it was quite spartan and it is still not comparable to the TCSH IMO).

CSH is a relic from the past; I dare say it is of no importance on FreeBSD. There is no CSH-only executable in the FreeBSD base-install: it's the TCSH—look ar the inodes of both. (There are (very) small differences in executable behaviour—of which I cannot show any examples—if this executable is called as tcsh or csh.) TCSH is also from a long time ago but at least it is a better (or less worse) shell: you can view it as a superset of the CSH. The TCSH is no longer being further developed, though still maintained. TCSH is fine for interactive use (in a sort of mimimalistic way when compared to zsh(1)). TCSH has niceties, CSH only has a few. CSH is particularly infamous for its shell programming; that extends to TCSH: you're advised not to do that. Everything you want to search for on the web, do search for tcsh.

The tcsh(1) man page is your friend: see the prompt description (search for "printexitvalue" - 2nd hit). Try*:

$ set prompt='%n@%m %/: '
blurp@q210 /home/blurp: alias precmd 'set rprompt="[`echo -n $?`] %P"'

EDIT: I missed the tcsh %?; this works better (don't forget to do unalias precmd first if you've defined it like above):

$ set prompt='%n@%m %/: '
blurp@q210 /home/blurp: set rprompt='[%?] %P'

Example:

blurp@q210 /home/blurp: date                        [0] 13:54:18
Thu May  9 13:54:21 CEST 2024
blurp@q210 /home/blurp: ddate                       [0] 13:54:21
ddate: Command not found.
blurp@q210 /home/blurp:                             [1] 13:54:27

The best single TCSH reference for interactive use is IMO still: Using csh & tcsh by Paul DuBois. If you find anything for the tcsh documentation online, comparable to the extensive zsh documentation online, please let me know
___
* based on zsh's info here:

%? Show the return code from the previous executed command Typically returns “0” when executed successfully

Note: my example code may not have the exact same effect as in zsh; check yourself.

 

[balanga]

With the change in the default shell for root from csh to sh in 14.0, I was wondering if there was any reason to use csh any more...

 

[Myersj281]

Thanks for the replies, everyone! I'm attempting to migrate just to see if I like it (ZSH is still on my system). I didn't realize how old and lacking it was compared to ZSh so I doubt I will start using it in production now, but it may be fun to continue migrating just to see if I even can.

Also, thanks Erichans, I haven't tested it yet, but I do believe your response solves the initial issue

EDIT: I just tested it and it does work. If CSH is that old, there probobly won't be anyone stumbling upon this and finding it usefull lol, but that '%p' is capital '%P'.

 

[mer]

With the change in the default shell for root from csh to sh in 14.0, I was wondering if there was any reason to use csh any more...

Because it's what I've been using for my user for a long time and I don't want to change it. By "it" I mean "tcsh". csh/tcsh works fine for interactive use; it falls short trying to script in it.


Now for the root user I just use the default.

 

[balanga]

Because it's what I've been using for my user for a long time and I don't want to change it. By "it" I mean "tcsh". csh/tcsh works fine for interactive use; it falls short trying to script in it.


Now for the root user I just use the default.

JFYI the default changed from 13 to 14. It caught me out inititialy. Just worth remembering if you work on <14 system at some point.

 

[mer]

Yep I know it changed, but I've always maintained users can choose whatever shell they like but the root shell should be whatever the system default is.

 

[Myersj281]

Yep I know it changed, but I've always maintained users can choose whatever shell they like but the root shell should be whatever the system default is.

Any reason for that? I always set the system shell to whatever I use (ZSH, lately) and it always works fine for me.

 

[fraxamo]

It is recommended that the root user's default shell remain unchanged since shells which are not included in the base distribution are installed to /usr/local/bin. In the event of a problem, the file system where /usr/local/bin is located may not be mounted. In this case, root would not have access to its default shell, preventing root from logging in and fixing the problem. To use a different shell for root, the toor account is available.

 

[mer]

Any reason for that? I always set the system shell to whatever I use (ZSH, lately) and it always works fine for me.

fraxamo tells the primary reason; my personal reason is I don't use the root account except for things that need root.
running pkg upgrade, running freebsd-update to update the system absolutely.
It also reduces a point of conflict when upgrading; I consider the root account to be "not under my control during updates" similar to "never modify /etc/defaults/rc.conf".
Could my position be considered harsh, too rigid? Perhaps. Experience has shown me accepting a little bit of discomfort when being root can save you a lot of pain if you get too comfortable as root.

 

[SirDice]

Any reason for that? I always set the system shell to whatever I use (ZSH, lately) and it always works fine for me.

There is no "system" shell. If anything all shell scripts are written with sh(1), a user's shell (including root's) setting is irrelevant in this respect.

It is recommended that the root user's default shell remain unchanged since shells which are not included in the base distribution are installed to /usr/local/bin. In the event of a problem, the file system where /usr/local/bin is located may not be mounted.

You can also run into problems with major version upgrades. Shells installed from ports/packages can fail as they are linked to the old library versions from the previous version. You will lock yourself out if you're not careful, especially if you do an upgrade remotely.