2

A am using bash as a default shell.

If I execute xterm (which is opened in XQuartz), I get the following errors:

bash: unsetenv: command not found
bash: unsetenv: command not found
bash: setenv: command not found
bash: setenv: command not found
bash: setenv: command not found
bash: setenv: command not found
bash: setenv: command not found
bash: unsetenv: command not found

It seems that a configuration file for csh is sourced.

If I execute xterm again in the xterm window, I get a new window without any errors.

In my home directory I have nothing with setenv or unsetenv

In both cases (from the terminal or from xterm):

$ type xterm
xterm is /opt/local/bin/xterm

Which file is read? Why only on the first execution?

Improve this question
11
  • 2
    How do you execute the first xterm?
    – nohillside ♦
    Commented Dec 29, 2022 at 15:22
  • @nohillside either from the terminal or from the menu of XQuartz. In both ways something is executed. If I execute it from xterm itself then it's OK. In both cases I execute the same binary (/opt/local/bin/xterm)
    – Matteo
    Commented Dec 29, 2022 at 16:07
  • What does type xterm in Bash say?
    – nohillside ♦
    Commented Dec 29, 2022 at 16:16
  • xterm is /opt/local/bin/xterm (I updated the question)
    – Matteo
    Commented Dec 29, 2022 at 16:22
  • 1
    You are running bash as your login shell. There seems to be a problem with your bash environment at login and not at next calls. This difference might come simply from the fact that these 2 are different ( ex. /bin/bash ≠ /opt/bin/bash ) or that you have a bug within ~/.bash_profile. Which one is your bash at login ( in /etc/passwd ) and the next ones ( type bash )? Could you check that your ~/.bash_profile doesn't source a C-shell script?
    – athena
    Commented Dec 29, 2022 at 18:17

1 Answer 1

Reset to default
3

The problem occurs when the used shell (in $SHELL) is not listed in /etc/shells.

From the man page:

Xterm validates shell programs by finding their pathname in the text file /etc/shells. It treats the environment variable “SHELL” specially because (like “TERM”), xterm both reads and updates the variable, and because the program started by xterm is not necessarily a shell.

I am using bash 5 installed via MacPorts (/opt/local/bin/bash).

Adding it to /etc/shells solves the problem.

Improve this answer
4
  • By default xterm runs /bin/sh which is /bin/bash when the SHELL is not defined or the passwd defined shell is not a valid one. But /bin/bash shouldn't give you errors like these coming from a C-shell script. This remains a serious pb to analyze.
    – athena
    Commented Dec 29, 2022 at 18:20
  • @dan I agree. And even if a [tc]sh shell was executed I don't get why it should read my .bashrc file ....
    – Matteo
    Commented Dec 30, 2022 at 21:51
  • Is /opt/local/bin/bash your login shell?
    – athena
    Commented Jan 1, 2023 at 13:57
  • @dan yes it's my login shell
    – Matteo
    Commented Jan 1, 2023 at 15:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .