Bug #23467


[PATCH] freenas csh.cshrc clobbers noninteractive shell sentinal by setting prompt

Added by Ash Gokhale over 4 years ago. Updated about 4 years ago.

Nice to have
Kris Moore
Target version:
Seen in:
Reason for Closing:
Reason for Blocked:
Needs QA:
Needs Doc:
Needs Merging:
Needs Automation:
Support Suite Ticket:
Hardware Configuration:
ChangeLog Required:


Freenas systems are unable to generate a noninteractive shell because /etc/csh.cshrc unconditionally sets $prompt. This is incorrect behavior and can cause side effects for remote processes as they use ?prompt checks to determine if the terminal is interactive. This broke my remote instrumentation. It also disregards the '-i' switch and also invalidates the csh man page about setting the default prompt for an interactive terminal at login time.

Test to see if a system is affected:
ssh root@zoltan 'set | grep prompt'
(should return nothing, noninterctive shells do not prompt)

Ideally we should remove everything from /etc/csh.cshrc and let it track ( by being empty ) from freebsd. There is noting in this file that contributes to the stability or functionality of FreeNAS.

alternately we can do this sadness to correct the behavior:

< switch ($TERM)
<     case "xterm*":
<       set prompt = '%{\033]0;%n@%m:%~\007%}[%B%n@%m%b] %B%~%b%# '
<               breaksw
<     default:
<       set prompt = '[%B%n@%m%b] %B%~%b%# '
<               breaksw
< endsw
> if ($?prompt) then
>       switch ($TERM)
>           case "xterm*":
>               set prompt = '%{\033]0;%n@%m:%~\007%}[%B%n@%m%b] %B%~%b%# '
>               breaksw
>           default:
>               set prompt = '[%B%n@%m%b] %B%~%b%# '
>               breaksw
>       endsw
> endif #don't clobber the prompt sentinal in non interactive shells

Associated revisions

Revision 4f293a6f (diff)
Added by Kris Moore over 4 years ago

Remove the custom .cshrc and /etc/csh.cshrc files, lets use the upstream versions again Ticket: #23467


#1 Updated by Ash Gokhale over 4 years ago

  • Priority changed from No priority to Nice to have

#2 Updated by Alexander Motin over 4 years ago

  • Assignee changed from Alexander Motin to Kris Moore

I agree that there is a problem now, but I don't very care which way it is fixed. I rarely bother to tune the shell for me, unless it is ugly or broken, using whatever I have. If support tells they don't need that tuning, I won't object, though IMHO having a host name in a window title can indeed be convenient.

Kris, you have large experience with end users, what would you guess they prefer?

#3 Avatar?id=14398&size=24x24 Updated by Kris Moore over 4 years ago

  • Status changed from Unscreened to Resolved
  • Target version set to 11.0

The upstream versions seem fine in this case, I've removed our custom cshrc files.

#4 Updated by Zoom Zoom about 4 years ago

Could the custom csh.cshrc still be included in /etc, but say under the name /etc/csh.cshrc.custom?
  • Other possibilities:
    • It could still be included as /etc/csh.cshrc, but have all lines commented out
    • It could be noted in the manual, or in a sticky in the forum, on where to find the custom csh.cshrc on GitHub or as a text file on

This would enable users to not have to hunt for the default options, such as ls colors, colorized prompt, history saving, etc. which many find helpful.

#5 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

You can always override the defaults with custom .cshrc files in /root or your $HOME dirs. You'll just probably want to have the template somewhere online with an instruction to "fetch -o /root/.cshrc http://&lt;mytemplate&gt;"

#6 Updated by Vaibhav Chauhan about 4 years ago

  • Target version changed from 11.0 to 11.0-RC

Also available in: Atom PDF