executing $TERM as shell is not good. This patch adds a
new global config value to specify the X-Shell command
to use.
In global.cfg add something like this:
XShellCommand = "xterm";
Hard coding of those NUL's shoudl be removed. It can easily brake
everything... and try not to overflow char array (only copy
buffer_max_len -1 characters as last MUST be NUL).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2003-06-04
Logged In: YES
user_id=9205
Ok, I updated the patch using buflen-1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I committed some changes to CVS. See my idea from there for safely
copying strings. (added safe_strncpy).
Next thing in your patch
:)...
Now if someone wants to use $TERM variable as it is normally
used, he probably wants it to work after upgrading to newer fte.
I
propose that you change your patch a bit, so if that new configuration
variable is empty (eg. not set) then it uses normal $TERM or "xterm", if it
wasn't empty it forces usage of what was defined in configuration file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2003-06-05
Logged In: YES
user_id=9205
The error with $TERM was that it was not normally used, it
was pure luck[1] that $TERM pointed to an executable.
I really do not like leaving this mistake for backward
compatibility. The new default "xterm" is sensible and we
should make users aware of the new configuration variable in
the Changelog or release announcement <wink 0.50 ;>
Ciao, Bastian
[1] well, statistically on my box it would have worked with
rxvt, xterm, konsole and kterm.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hmm... I just played bit with ssh & x-forwarding... and found out that your
way is actually only way to go.
There is also some hardcoded
commandline parameters and I am not totally sure if those parameters
are somehow standardized: "-ls" and "-e "
Should these also be
configurable ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2003-06-05
Logged In: YES
user_id=9205
The -e option should be support by all X terminal emulators
out there. The -ls is not supported by all of them. See http://lists.debian.org/debian-x/2000/debian-x-200010/msg00358.html
for a wrapup of most of them.
So, -e can remain, I would remove -ls (it does not seem to
be strictly necessary for a spawned subshell to be a login
shell, no?).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I modified your patch a bit and commited it. I still leaved -ls until I know (or
just test) why it was there orginally. I will give it a look in near future...
probably when I start playing with UTF8 problem....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=20264
Hard coding of those NUL's shoudl be removed. It can easily brake
everything... and try not to overflow char array (only copy
buffer_max_len -1 characters as last MUST be NUL).
Logged In: YES
user_id=9205
Ok, I updated the patch using buflen-1
updated patch
Logged In: YES
user_id=20264
I committed some changes to CVS. See my idea from there for safely
copying strings. (added safe_strncpy).
Next thing in your patch
:)...
Now if someone wants to use $TERM variable as it is normally
used, he probably wants it to work after upgrading to newer fte.
I
propose that you change your patch a bit, so if that new configuration
variable is empty (eg. not set) then it uses normal $TERM or "xterm", if it
wasn't empty it forces usage of what was defined in configuration file.
Logged In: YES
user_id=9205
The error with $TERM was that it was not normally used, it
was pure luck[1] that $TERM pointed to an executable.
I really do not like leaving this mistake for backward
compatibility. The new default "xterm" is sensible and we
should make users aware of the new configuration variable in
the Changelog or release announcement <wink 0.50 ;>
Ciao, Bastian
[1] well, statistically on my box it would have worked with
rxvt, xterm, konsole and kterm.
Logged In: YES
user_id=20264
Hmm... I confused $TERM and $SHELL :|... anyway... $TERM usually has
terminal type eg. linux, vt100, vt320, xterm.
$SHELL usually has
active shell.
Logged In: YES
user_id=20264
hmm... I just played bit with ssh & x-forwarding... and found out that your
way is actually only way to go.
There is also some hardcoded
commandline parameters and I am not totally sure if those parameters
are somehow standardized: "-ls" and "-e "
Should these also be
configurable ?
Logged In: YES
user_id=9205
The -e option should be support by all X terminal emulators
out there. The -ls is not supported by all of them. See
http://lists.debian.org/debian-x/2000/debian-x-200010/msg00358.html
for a wrapup of most of them.
So, -e can remain, I would remove -ls (it does not seem to
be strictly necessary for a spawned subshell to be a login
shell, no?).
Logged In: YES
user_id=20264
I modified your patch a bit and commited it. I still leaved -ls until I know (or
just test) why it was there orginally. I will give it a look in near future...
probably when I start playing with UTF8 problem....
Looks like this code is already part of fte cvs tree