Terminal unter Gnome schließt nicht mehr

[poe]

Hallo,
mein Terminal unter Gnome schließt nicht mehr mit "exit". Weiß jemand woran das liegt? Dabke.

[SubOptimal]

Hi,

was passiert denn, wenn Du exit eintippst? Bekommst Du eine Fehlermeldung?
Was lieferen denn folgende Kommandos?

Code: Alles auswählen

which exit
echo $SHELL

SubOptimal

[poe]

Hi,
which exit ergibt garnichts, läuft einfach leer, und der Prompt kommt wieder.
echo $SHELL ergibt /bin/bash
Das sieht wohl alles normal aus, oder?

wenn ich exit eingebe wird exit als text wieder ausgegeben, und das terminal friert ein. Ich schließe dann halt das Fenster. Das terminal läuft dann normal weiter, wenn ich es wieder starte. Das ganze ist also kein Drama, aber halt komisch, weil das simple exit nicht funktioniert. Danke mal für Dein reply.

[SubOptimal]

Hi,

which exit ergibt garnichts, läuft einfach leer, und der Prompt kommt wieder.
echo $SHELL ergibt /bin/bash
Das sieht wohl alles normal aus, oder?

Schaut normal aus.

wenn ich exit eingebe wird exit als text wieder ausgegeben, und das terminal friert ein.

Das schaut so aus, dass noch irgendein Prozess läuft. Dieser aber die Eingabe aber nicht entgegen nimmt.
Ich würde vermuten, dass die Ursache dafür in der ~/.bashrc zu finden ist. Zum Test mal folgendes ausprobieren.

Code: Alles auswählen

# die .bashrc sichern
cd
mv ./.bashrc ./bashrc_backup

# nun ein gnome-terminal starten, in dem Fall am besten über die Gnome-Menüleiste
...

# schauen ob sich dieses gestartete gnome-terminal mit exit verlassen lässt
exit

# .bashrc wieder zurück sichern
cd
mv ./.bashrc_backup ./.bashrc

Hat es so funktioniert, die ~/.bashrc mal durchschauen welche Programme gestartet werden. Eventuell ist es ja auch nur ein fehlendes Hochkomma, für eine Environmentvariable oder ähnlichem. Bei Problemen oder wenn Du nichts findest, die ~/.bashrc mal auf http://nopaste.debianforum.de/ zur Durchsicht hochladen.

SubOptimal

[poe]

Gute Idee! Hab ich gemacht. Leider kein Effekt. Ist das nicht leidig, bei so einem guten System wie Debian?!
Mal sehen, ich forste das trotzdem mal durch, der Ansatz schein mir sehr gut. Merci.

Hier die .bashrc bzw .bashrc_backup:


export EDITOR=/usr/bin/vim
# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# don't put duplicate lines in the history. See bash(1) for more options
# don't overwrite GNU Midnight Commander's setting of `ignorespace'.
export HISTCONTROL=$HISTCONTROL${HISTCONTROL+,}ignoredups
# ... or force ignoredups and ignorespace
export HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# make less more friendly for non-text input files, see lesspipe(1)
#[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi

if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

#if [ -f ~/.bash_aliases ]; then
# . ~/.bash_aliases
#fi

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
eval "`dircolors -b`"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'

#alias grep='grep --color=auto'
#alias fgrep='fgrep --color=auto'
#alias egrep='egrep --color=auto'
fi

# some more ls aliases
#alias ll='ls -l'
#alias la='ls -A'
#alias l='ls -CF'

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi

[SubOptimal]

Hi,

die .bashrc ist also nicht die Ursache. Starte mal eine gnome-terminal Sitzung und schau ob durch die Bash noch ein weiterer Prozess gestartet wird.

Code: Alles auswählen

pstree `pidof gnome-terminal`

Es könnten auch die Profileinstellungen der gnome-terminal Sitzung sein. Überprüfe mal ob in den Profileinstellungen (Klick mit rechter Maustaste in das gnome-terminal Fenster --> Profile --> Profileinstellungen) ob im Reiter »Titel und Befehl« bei der Option »Wenn Befehl beendet« »Exit the terminal« ausgewählt ist.

Ist das nicht leidig, bei so einem guten System wie Debian?!

Wenn es ein genereller Fehler wäre, dann:
- würde sich Deine Fehlerbeschreibung mittels Suchmaschine mehrfach finden lassen
- wäre die Lösung dafür schnell gefunden und behoben worden
Also wahrlich kein Grund an der Zuverlässigkeit von Debian zu zweifeln.

SubOptimal

[poe]

Gelöst. Es war die Profileinstellung. Naiverweise bin ich die nicht konsequent durchgegangen. Danke für Deine kompetente Hilfe. An Debian zweifle ich nach meinem Distri-hopping nicht, ich habe es ganz bewußt gewählt, wegen seiner Zuverlässigkeit, Offenheit und hervorragenden Dokumentation.