Re: How come i wrote a NO-BREAK SPACE in xterm+bash ?
Quoting Vincent Lefevre (vincent@vinc17.net):
> On 2015-08-21 22:08:33 -0500, David Wright wrote:
> > Quoting Vincent Lefevre (vincent@vinc17.net):
> > > No, here's what I said:
> > >
> > > | In general, one wants NO-BREAK SPACE to be displayed just like
> > > | a space. The differentiation is useful mainly in source code
> > > | and when editing, thus it must be done by the application via
> > > | configuration (actually applications running in the terminal
> > > | rather than the terminal itself).
> >
> > So we may be talking at cross-purposes here as I'm distinguishing the
> > shell (command interpreter/application launcher) from applications,
> > much as Erwan appears to in that sentence. Sorry; but that's why I wrote
> > (AIUI) just there.
That's quoted from my posting.
>
> >From the terminal point of view, the shell is just like another
> process.
Just to make it clear: I didn't write that, even though you've made it
appear that I did by putting ">" in front of it.
>
> Moreover, one can often start commands from other applications
> (conventional "!" shell escape), and even an interactive shell.
> So, it becomes more difficult to do the difference...
I was trying to avoid discussing the terminology of shells,
applications and terminals and concentrate on my point which is that
if a character (eg NBSP) is not treated as whitespace by the shell,
then it is better if it is not reflected on my screen as whitespace.
How the NBSP was input in the first place was the subject raised by
the OP. My point only had to do with the output from the shell.
When a possibly clumsy typist types Alt-Space and generates a NBSP
as input, the terminal doesn't have to display anything. The shell
eats the character and *it* decides how to reflect it. At that point,
it's output. (I seem now to be repeating what's written by me below.)
>
> > > Your "counter-example" is something different because it is about
> > > input (though this doesn't really matter since the notion of context
> > > is the same for both input and output) and because the TAB handling
> > > is not done by the terminal, but by two different applications
> > > running in the terminal (the shell and "cat"). As I've said later,
> > > both applications receive TAB in input. They behave differently only
> > > because they interpret TAB differently, i.e. the differentiation is
> > > done by the application (the shell and "cat").
> >
> > This may come down to terminology again. I don't know. To me, input to
> > the shell is what the keys produce (scan codes) and then the keymap
> > turns them into. That's what I was struggling with yesterday in
> > another thread, playing about with /etc/console-setup/remap.inc.
> >
> > When a character goes into the shell, it is interpreted. What then
> > reflects on the screen, to me, is output from the shell.
>
> It is a bit more complex. A character goes to the terminal first.
> Run "sleep 10" in a shell, and type characters: they will appear,
> but they do not come from the shell (which is just waiting for
> "sleep 10" to terminate). They are echoed directly by the terminal.
> The characters will go to the shell (or another application running
> in the terminal) later.
Yes. When you type ahead, the characters from the keyboard are
reflected raw. I have no argument with what is displayed at this
time. AIUI whatever is reflecting them is not parsing them so any
discussion of "whitespace" is irrelevant. At this stage, what is
actually displayed doesn't make much meaningful sense. For example,
if I type a<down arrow>, I see a^[[B. Interestingly, If I now press
<rubout>A, when the shell eventually reflects it, it looks in my
command history for a command starting with "a". The latter is at the
stage that I'm talking about, when the characters are reflected by
the shell. I want to see NBSP displayed differently from normal
whitespace because the shell doesn't treat it as whitespace.
Here are my original words:
"Why would I want a character that doesn't behave as a space to be
displayed as a normal space? (For example, in the shell, as in the
OP's original question.) It seems a recipe for confusion at best,
and for exploits at worst."
Cheers,
David.
Reply to: