On Tue, 2015-06-30 at 17:36 +0200, Vincent Lefevre wrote:
> how to use GNU screen without writing it
> explicitly?
>
> For instance:
>
> ssh host my_command
>
> where my_command is automatically run under GNU screen.
When you invoke ssh like this, it executes the command with -c
"mycommand",
On Tue, 2015-06-30 at 17:26 +0200, Vincent Lefevre wrote:
> Sending TERM is absolutely necessary because different terminals
> behave in different ways.
And that's why SSH sends it... others are not important, thus, they
don't sent by default.
> > What keeps you from also just setting your LC_*,
On 2015-06-30 16:09:29 +0100, Stephane Chazelas wrote:
> 2015-06-30 16:45:59 +0200, Vincent Lefevre:
> > On 2015-06-30 15:04:17 +0100, Stephane Chazelas wrote:
> > > From a UTF-8 terminal:
> > >
> > > luit -encoding 'ISO 8859-1' ssh host-known-to-use-latin1
> >
> > This is not very good, because
On 2015-06-30 16:32:53 +0200, Christoph Anton Mitterer wrote:
> On Tue, 2015-06-30 at 13:30 +0200, Vincent Lefevre wrote:
> > This is not completely true: this is the case *by default*, but the
> > user can always change the default. When I get an account on a
> > machine,
> > one of the first thi
2015-06-30 16:45:59 +0200, Vincent Lefevre:
> On 2015-06-30 15:04:17 +0100, Stephane Chazelas wrote:
> > Or use luit that has been designed for that:
>
> However it doesn't work from non-UTF-8 terminals.
Yes, though if you don't use a UTF-8 terminal you won't be able
to see arbitrary characters
On 2015-06-30 15:04:17 +0100, Stephane Chazelas wrote:
> Or use luit that has been designed for that:
However it doesn't work from non-UTF-8 terminals.
> From a UTF-8 terminal:
>
> luit -encoding 'ISO 8859-1' ssh host-known-to-use-latin1
This is not very good, because the default encoding on t
On Tue, 2015-06-30 at 13:30 +0200, Vincent Lefevre wrote:
> You should learn how terminals work. When using a terminal, the
> remote
> charmap MUST be the same as the local one (or be a subset), otherwise
> the terminal cannot interpret the byte sequences correctly.
Sure... I haven't said that I wo
2015-06-30 13:30:50 +0200, Vincent Lefevre:
[...]
> > I don't understand what you mean.
> > My point was, applications/systems use different locales. Nothing will
> > change that.
> > Thus when you process output from a remote application on the local
> > system, you must assume that this is happen
2015-06-30 15:04:17 +0100, Stephane Chazelas:
[...]
> ssh -t host luit
>
> (assuming luit is installed on host).
>
> (unfortunately it doesn't seem to support the /new/ Western
> Europe charset iso8859-15).
[...]
Sorry, it does support it, but it seems it fails to detect it
properly from the loc
On 2015-06-30 05:35:16 +0200, Christoph Anton Mitterer wrote:
> On Tue, 2015-06-30 at 04:30 +0200, Vincent Lefevre wrote:
> > > Well but there one knows / must assume at least that this can
> > > happen:
> > > When one remotely accesses a system and processes output from
> > > there, it
> > > must
On Tue, 2015-06-30 at 04:30 +0200, Vincent Lefevre wrote:
> > Well but there one knows / must assume at least that this can
> > happen:
> > When one remotely accesses a system and processes output from
> > there, it
> > must be assumed that there are different locales/etc. and
> > appropriate
> >
On 2015-06-30 02:53:23 +0200, Christoph Anton Mitterer wrote:
> On Tue, 2015-06-30 at 01:23 +0200, Vincent Lefevre wrote:
> > On the other hand, having the wrong charmap on the other side is a
> > security issue, because remote utilities could send characters that
> > they think to be printable, bu
On Tue, 2015-06-30 at 01:23 +0200, Vincent Lefevre wrote:
> On the other hand, having the wrong charmap on the other side is a
> security issue, because remote utilities could send characters that
> they think to be printable, but are actually control characters /
> escape sequences due to the wron
On 2015-06-29 22:50:59 +0200, Christoph Anton Mitterer wrote:
> On Mon, 2015-06-29 at 20:55 +0100, Stephane Chazelas wrote:
> > Note that LANG/LC_* which Debian ssh already accepts is probably one
> > of the worst one as it affects so many commands. That also
> > affects bash shell grammar parsing
On Mon, 2015-06-29 at 20:55 +0100, Stephane Chazelas wrote:
> $TERM is already passed but only when a pty is requested.
Which is by far not the only use case of ssh.
Actually there are many major use cases where no pty is involved at all
(and where ssh serves just as a crypto transport layer), but
Hey
Am 29. Juni 2015 14:25:15 MESZ, schrieb Vincent Lefevre <
vinc...@vinc17.net>:
> I completely disagree that passing XTERM_VERSION is not secure
> (this RFE is about this particular variable, and not anything else).
To be honest, I think it's at best naive to assume, that one can
predict wheth
On 2015-06-29 05:43:07 +0200, Christoph Anton Mitterer wrote:
> We've had the same discussion last time when it was about LC_*.
>
> It's generally a bad idea to change the secure default of not
> forwarding/accepting anything.
I completely disagree that passing XTERM_VERSION is not secure
(this R
We've had the same discussion last time when it was about LC_*.
It's generally a bad idea to change the secure default of not
forwarding/accepting anything.
Due to past errors, we're already in the unfortunate situation that
this is done for an arbitrary number of vars, and regrettably the
mainta
Source: openssh
Version: 1:6.7p1-6
Severity: wishlist
Passing the terminal version to the server side is useful for programs
that depend on some terminal features (for instance, to make sure that
some query escape sequence will receive an answer).
In the case of xterm, it is provided by XTERM_VER
19 matches
Mail list logo
