Steps to reproduce: 1. Create a new user account. 2. Edit /etc/passwd and delete the shell -- ie: test:x:1006:100:test,,,:/home/test:/bin/bash becomes: test:x:1006:100:test,,,:/home/test: 3. Start xfce as that user. Run Terminal. Result: Terminal starts, but the window is blank and will not accept input at all. Okay, I know that this is braindead and should never happen. However, it does - every now and then, a user forgets to specify "-s <shell>" when using useradd(8), and in some versions of kde (up to 3.5.8 at least), the kuser tool would not select a shell automatically, so if the user did not specify one, it would be left blank. According to usermod(8), if the shell is left blank, then /bin/sh should be assumed: ‐s shell The name of the user’s new login shell. Setting this field to blank causes the system to select the default login shell. Basically, what I think should happen is that Terminal should use "/bin/sh" if there is no shell in the user's /etc/passwd.
IIRC, this is done by VTE, but I'm not 100% sure. Did you try with gnome-terminal as well? If so, this bug should be forwarded to VTE.
I can't confirm this personally, but I've had a few trusted people test this, and neither roxterm nor gnome-terminal, both of which use vte, have this bug. The tested versions are gnome-terminal 2.24.2 and roxterm 1.13.0, both with vte 0.17.4 (again, both of them work correctly with no shell specified in /etc/passwd). For what it's worth, I can confirm that this occurs with all vte versions up to the latest current release (0.19.4).
Interestingly enough, this is also a problem with the sample terminal shipped with vte -- executing "vte" gives an identical blank screen. I just built and tested sakura, another vte-based terminal, and it works fine.
Created attachment 2199 Possible fix by reading SHELL environment variable if the shell is not set in /etc/passwd This is a possible solution of the problem based on Robby's patch (http://rlworkman.net/ugly). If no shell is set in /etc/passwd, then the SHELL environment variable is read. In case this also fails, "/bin/sh" is used as a last fallback.
I cannot reproduce this problem here, but the fix looks reasonable nevertheless. I tested Enrico's patch and it seems to be fine.
Enrico's patch works as expected here; thanks for cleaning up my trash! ;-)
I could reproduce it now and the patch indeed fixes this problem. Committed in revision 29638: * terminal/terminal-screen.c: Fall back to the SHELL environment variable or to /bin/sh if there's no login shell defined for the current user. This fixes bug #4970. Patch cooked up by Robby Workman and Enrico Tröger.