| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
screen issue
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 screen issue - Jun. 15, '05, 3:08:26 AM
|
|
|
cortez_
Posts: 330
Joined: Mar. 27, '04,
From: Poland
Status: offline
|
When starting screen I get error "LoginName too long - sorry."
The computer is not part of a domain but the full username is: "PCBPRZYBYLSKI+gprzybylski" I suppose it might be too long for screen to accept it.
Maybe that is the issue (from the source code):
if (strlen(LoginName) > 20)
Panic(0, "LoginName too long - sorry.");
But why does it limit the field lenght to 20 chars?
|
|
|
|
|
RE: screen issue - Jun. 15, '05, 3:26:02 AM
|
|
|
Rodney
Posts: 2916
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
I'll fix that and then post another release.
A length of 20 is more than enough for most Unix systems.
I think it should have been based on a constant from a system header file.
We set MAXHOSTNAMELEN to 256 at one point for Interix.
But I set UT_NAMESIZE and UT_HOSTSIZE to 128 each which equals 256.
And I think I did that for the relationship with MAXHOSTNAMELEN, but it was
so long ago now. Anyway, I'll use the UT_*SIZE's for the fix.
I expect that there are some other similar lines like the one you found.
|
|
|
|
|
RE: screen issue - Jun. 15, '05, 4:36:42 PM
|
|
|
Rodney
Posts: 2916
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
I've place a patched version of screen under beta for you to try.
The changes were not complex per se, but there is with screen
an established communications protocol using the maximum size of 20.
So I can't break/fix that. So I've set it so the last 20 characters
are used in the screen to screen communications.
So try:
pkg_add ftp://ftp.interopsystems.com/pkgs/beta/screen-4.0.2.1-bin.tgz
If it seems good for you then I'll place it in the main section.
|
|
|
|
|
RE: screen issue - Jun. 16, '05, 2:38:40 AM
|
|
|
cortez_
Posts: 330
Joined: Mar. 27, '04,
From: Poland
Status: offline
|
It is fine, I mean it starts up, but does not work with the colours in the prompt of bash,
The prompt is defined like this:
\[\e[1;33m\]\u \[\e[1;36m\]\w\[\e[1;31m\]#>\[\e[0m\]
And this is actually whas I see when I enter screen (it should be a normal prompt).
I have tested the gnu version of screen in Linux and with bash it worked ok with the color prompt defined in the same way.
|
|
|
|
|
RE: screen issue - Jun. 16, '05, 10:41:51 AM
|
|
|
Rodney
Posts: 2916
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Okay. I haven't changed anything with regards to character flow.
I'll try the escape codes and see what's up.
|
|
|
|
|
RE: screen issue - Jun. 16, '05, 11:29:41 AM
|
|
|
Rodney
Posts: 2916
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
It's got to be some other issue than screen itself.
When I start screen and run one of the libcurses test programs
(which are in colour) such as "worm" I get everything in colour.
When I run ls -v (colour output) in screen the colour does not appear.
So it has to do with the escape codes. When you screen is run it sets it's
own terminal type ("screen") instead of using the same as the real underlying tty.
So when the escape codes match then there is colour. The same thing is happening
with your bash. On your Linux machine there must be something conditional
for the colour bash prompt.
In your shell's startup script (i.e. ~/.profile) you can conditionally test the
terminal type name and set things as needed. For example, with ls you
can set the environment variable LS_COLOURS differently for interix, xterm,
screen, vt100, ...
|
|
|
|
|
RE: screen issue - Jun. 16, '05, 11:53:16 AM
|
|
|
cortez_
Posts: 330
Joined: Mar. 27, '04,
From: Poland
Status: offline
|
The scripts in .bash_profile have been copied to the linux machine from the windows/interix machine and there are no conditionals in there.
The prompt is defined like this:
export PS1='\[\e[1;33m\]\u\[\e[0;33m\]@\h \[\e[1;36m\]\w\[\e[1;31m\]#>\[\e[0m\]'
I'm also using the gnu version of ls (instead of the one provided by the /tools) because it uses a little bit different switches. And when I type ls --color within screen I get perfec color support.
However I see that also the aliases from .bash_profile are not recognized within screen.
|
|
|
|
|
RE: screen issue - Jun. 16, '05, 12:15:03 PM
|
|
|
Rodney
Posts: 2916
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
> And when I type ls --color within screen I get perfec color support.
It must have some hardwired defaults for some certain tty types because
the documentation for GNU's ls and dircolors says it's using
an environment variable for the colour settings. (I'm not looking at the
GNU ls code to keep myself clean.)
With the /Tools ls this hardwiring is done as a default for interix
and for xterm when LS_COLOURS is not set (though xterm being black & white it
won't show much difference).
When you start screen on your Linux box, what does it show for the terminal
type ? (echo $TERM)
And what is the underlying tty type? (interix, xterm, rxvt, ...)
< Message edited by Rodney -- Jun. 16, '05, 12:40:31 PM >
|
|
|
|
|
RE: screen issue - Jun. 16, '05, 12:41:10 PM
|
|
|
Rodney
Posts: 2916
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Another though is that on your Linux box the environment variable LS_COLOR
is always set to something.
|
|
|
|
|
RE: screen issue - Jun. 16, '05, 5:40:29 PM
|
|
|
cortez_
Posts: 330
Joined: Mar. 27, '04,
From: Poland
Status: offline
|
The linux termtype is "linux" on linux the echo $TERM command from within the screen gives me "screen.linux" termtype.
The LS_COLORS is set to the same value as outside of the screen.
On Interix the described problem occures when starting sceen from interix type terminal
|
|
|
|
|
RE: screen issue - Jun. 16, '05, 7:15:39 PM
|
|
|
Rodney
Posts: 2916
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
> The LS_COLORS is set to the same value as outside of the screen.
Right, so there is a value for ls to pick up on your Linux box.
So that's why it's working.
On the Interix box L_COLOURS is not set, and is not one of the "internally
known terminals" so nothing gets set. Hence, no colours.
So if you explicitly set LS_COLOURS then something will always happen.
|
|
|
|
|
RE: screen issue - Jun. 17, '05, 2:16:59 AM
|
|
|
cortez_
Posts: 330
Joined: Mar. 27, '04,
From: Poland
Status: offline
|
but if I type "ls --color" (GNU ls) inside the screen IT WORKS! Only seems that the alias from the .bash_profile (alias ls="ls --color") gets dropped.
I KNOW!!!! It's not the bash shell that gest started when I run screen, that is why the prompt gets busted.
It starts the sh shell which is apparently linked to ksh so therefore it doesn't work.
When I run bash within the screen it works perfectly with the colour prompt. So now we should redefine the question.
Why does screen run /bin/sh instead of the shell that is defined ad default for the user?
|
|
|
|
|
RE: screen issue - Jun. 17, '05, 2:18:34 AM
|
|
|
savoiu
Posts: 25
Joined: Jun. 11, '05,
Status: offline
|
I've tried setting LS_COLORS to what I usually set on my Linux box
setenv LS_COLORS 'no=00:fi=00:di=01;33:ln=01;35:pi=01;37:so=01;34:bd=01;36:cd=01;36:or=05;01;31:mi=05;01;31:ex=01;31:*.cmd=01;31:*.exe=01;31:*.com=01;31:*.btm=01;31:*.bat=01;31:*.sh=01;31:*.csh=01;31:*.tar=01;37:*.tgz=01;37:*.arj=01;37:*.taz=01;37:*.lzh=01;37:*.zip=01;37:*.z=01;37:*.Z=01;37:*.gz=01;37:*.bz2=01;37:*.bz=01;37:*.tz=01;37:*.rpm=01;37:*.cpio=01;37:'
but it seems to kill the colors in 'ls'. If I don't set it then I get the default 'ls' colors.
Any ideas?
Thanks,
Nick
|
|
|
|
|
RE: screen issue - Jun. 17, '05, 2:54:39 AM
|
|
|
cortez_
Posts: 330
Joined: Mar. 27, '04,
From: Poland
Status: offline
|
The Idea to get colours with ls in screen is to use the GNU version of ls - it obviously works.
The second issue is that if you have a default shell as bash, you will surely get confused as I did. On linux /bin/sh is a symlink to /usr/bin/bash and you won't notice anything. In interix /bin/sh is a symlink to /bin/ksh/ which is obviously not the bash shell. And apparently screen uses /bin/sh as a default shell.
Therefore there are four solutions possible:
1. Change the symlink from /bin/sh to point to /usr/local/bin/bash
2. Run screen with a command "screen -s /usr/loacl/bin/bash"
3. before running screen setup an environment variable $SHELL to the shell you want to use within screen
4. Specify the shell in /etc/screenrc
|
|
|
|
|
RE: screen issue - Jun. 17, '05, 3:08:42 AM
|
|
|
savoiu
Posts: 25
Joined: Jun. 11, '05,
Status: offline
|
Hmm, seems complicated. I'm using tcsh. Using 'ls -v' I already getting colors in the listing. Shouldn't LS_COLORS allow customization?
Nick
|
|
|
|
|
RE: screen issue - Jun. 17, '05, 3:27:35 AM
|
|
|
Rodney
Posts: 2916
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
For cortez's issues:
I've made a fix to screen for getting the correct default shell (that's a screen bug).
So this will solve the "which shell" problem.
The correct default shell is taken from the user database now.
So the next release will have this in it.
For savoiu:
If the environment variable LS_COLOURS (or LS_COLOR for those who spell alternatively)
then these settings will be used for display. If the env var is not set then ls
has default values it will use for the terminal types "interix" and "xterm".
The settings for which file types get which colour is done in the env var as outlined
on the man page for ls. It's not the same as GNU's ls. To quote:
LS_COLOURS
The contents of this variable will set the display colours for
different file types for the terminal. For compatability
LS_COLORS will be accepted as an alternative spelling. The
content is a series of variable settings that are colon (:)
separated.
all for all file types
dir for directories
exe for executable files
fifo for FIFO's
lnk for linked files
norm for regular files
sock for socket files
wht for whiteout files (not yet on Interix)
Variable are set equal to a value. You do not specify an
'escape' as this will be prefixed for you when colouring is
done. You may leave variables unset. You need to specify the
unsetting of the color with the same variable name suffixed
with a "_r". An example setting is:
dir=[31m:dir_r=[0m:norm=[0m:lnk=[34m:exe=[32m:all_r=[0m
|
|
|
|
|
RE: screen issue - Jun. 17, '05, 3:34:56 AM
|
|
|
Rodney
Posts: 2916
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Screen 4.0.2.2 is available now.
It has the default shell fix.
To install/update do:
pkg_update -L screen or
pkg_add ftp://ftp.interopsystems.com/pkgs/3.5/screen-current-bin.tgz
|
|
|
|
|
RE: screen issue - Jun. 17, '05, 8:30:38 AM
|
|
|
cortez_
Posts: 330
Joined: Mar. 27, '04,
From: Poland
Status: offline
|
Doesn't work. I mean it works in the same way as the 4.0.2.1 - are there any language dependant issues in getting info from the user database?
|
|
|
|
|
RE: screen issue - Jun. 17, '05, 12:40:34 PM
|
|
|
Rodney
Posts: 2916
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
The algorithm is to look for the environment variable "SHELL" first
and use whatever is specified in it. If "SHELL" does not exist then
the value stored in the user database is used (a getpwuid() call).
I've verified that it's working with a fresh install of screen from the
ftp site. There's no language issue (the fresh install is in Japanese).
So, if you currently have SHELL set then unset it.
Otherwise check that you have bash as your default shell in
the user database ("finger -l <username>").
|
|
|
|
|
RE: screen issue - Jun. 17, '05, 2:06:01 PM
|
|
|
cortez_
Posts: 330
Joined: Mar. 27, '04,
From: Poland
Status: offline
|
Yes, it's ok. I've tested it on another machine where the shell is correctly installed in the user database. Therefore it was my mistake. On the previous machine the user database was not updated. It's fine now.
Sorry for misleading info, and thanks for support.
The only thing that doubts me now is that the aliases defined in .bash_profile are not recognized inside the screen
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
