Jumbled terminal input
yon...@yahoo.com
OpenBSD. Why does copy and paste of multiple lines of commands like
this
sleep 1
sleep 1
from my Windows clipboard into my C shell UNIX window makes the input
and output jumbled together:
% sleep 1
sleep 1
% %
On this host, bash doesn't have this problem; each line of "sleep 1" is
echoed back to the terminal window 1 second after another:
% bash
bash-2.03$ sleep 1
bash-2.03$ sleep 1
I compared `stty -a` ouput of csh and bash. They're exactly the same.
`set` output differs. bash has an option IFS:
bash-2.03$ set
[snipped]
IFS='
'
[snipped]
I think that may be relevant. But I don't know how to set it in csh or
if csh cares that option at all.
ksh has yet another behavior. Pasting two "sleep 1" lines into it echos
"sleep 1" three times:
% ksh
$ sleep 1
sleep 1
$ sleep 1
Can anybody explain all this? What I want is to get the bash behavior
in csh.
One more puzzble related to this. The behavior may be controlled by the
specific application (shell or not). For instance, on one server,
Expect echo commands can't be pasted into Expect too fast (three "echo
'a'" here):
$ expect
expect1.1> echo 'a'
echo 'a'
echo 'a'
'a'
expect1.2> 'a'
expect1.3> 'a'
expect1.4>
But I have no problem pasting multiple print commands into python on
the same server:
$ python
Python 2.4.1 (#1, Nov 15 2005, 10:21:52)
[GCC 3.3.5 (propolice)] on openbsd3
Type "help", "copyright", "credits" or "license" for more information.
>>> print 'a'
a
>>> print 'a'
a
>>> print 'a'
a
>>> print 'a'
a
Thanks for any explanation.
Yong Huang
Michael Paoli
> This may not be specific to any UNIX but my test is on Solaris and
> OpenBSD. Why does copy and paste of multiple lines of commands like
> this
>
> sleep 1
> sleep 1
>
> from my Windows clipboard into my C shell UNIX window makes the input
> and output jumbled together:
>
> % sleep 1
> sleep 1
> % %
UNIX(/LINUX/etc.) will generally continue to accept input, even when
not yet ready to explicitly act upon the additional input (e.g. prior
command hasn't completed and shell hasn't issued next prompt yet).
If echoing is on, as it typically would be, characters input will be
echoed back. The exact ordering of the output will depend on various
timing factors, and may not necessarily always be the same. The only
(general) guarantees are:
o the commands input are echoed back (so long as echoing is on)
o command won't start until that input is completed
o prompt is issued after synchronous command completion (and
completion of its output) and before start of subsequent command
(for asynchronous command, shell doesn't wait for it to complete)
o output of synchronous commands will be in sequence
o output of echoed input will be in order
o if input to a subsequent command is received prior to completion of
current command and issuance of next prompt, there are no guarantees
that output of the current command and echoing of input for
subsequent command(s) won't be intermingled.
o there may be some (slight) exceptions to the above, but those cover
the general cases pretty well
> On this host, bash doesn't have this problem; each line of "sleep 1" is
> echoed back to the terminal window 1 second after another:
>
> % bash
> bash-2.03$ sleep 1
> bash-2.03$ sleep 1
>
> I compared `stty -a` ouput of csh and bash. They're exactly the same.
> `set` output differs. bash has an option IFS:
>
> bash-2.03$ set
> [snipped]
> IFS='
> '
> [snipped]
>
> I think that may be relevant. But I don't know how to set it in csh or
> if csh cares that option at all.
>
> ksh has yet another behavior. Pasting two "sleep 1" lines into it echos
> "sleep 1" three times:
>
> % ksh
> $ sleep 1
> sleep 1
> $ sleep 1
Korn and Korn-like shells - e.g. those that have in-place
command-line editing capabilities (e.g. vi-line and emacs-like
command-line editing) may output(/"echo") input more than exactly
once. This will typically happen when they shift into mode(s) to
enable special handling of the display of the characters input (e.g.
shifting them on the display line to accommodate a command that would
exceed or nearly exceed the display width when followed by the
shell's prompt), and might possibly happen in other circumstances
(e.g. if in vi edit mode, one first enters ESCAPE, then i, and then
enters the command, the echoing may proceed in a manner rather
different than simple literal echoing of the characters input).
> Can anybody explain all this? What I want is to get the bash behavior
> in csh.
>
> One more puzzble related to this. The behavior may be controlled by the
> specific application (shell or not). For instance, on one server,
> Expect echo commands can't be pasted into Expect too fast (three "echo
> 'a'" here):
>
> $ expect
> expect1.1> echo 'a'
> echo 'a'
> echo 'a'
> 'a'
> expect1.2> 'a'
> expect1.3> 'a'
> expect1.4>
I don't see anything incorrect in the above.
I see three commands:
echo 'a'
that were entered, each of which is echoed exactly once, for a total
of three.
I see the output ('a') exactly 3 times, once for each command.
For each command entered, I see one new prompt (1.2 through 1.4).
The prompts are issued in order.
The echoing of the input, and the output of the commands would
both each seem to be in order (though that can't be visually
confirmed with all three of the commands and each of their outputs
being identical in this case).
> But I have no problem pasting multiple print commands into python on
> the same server:
>
> $ python
> Python 2.4.1 (#1, Nov 15 2005, 10:21:52)
> [GCC 3.3.5 (propolice)] on openbsd3
> Type "help", "copyright", "credits" or "license" for more information.
> >>> print 'a'
> a
> >>> print 'a'
> a
> >>> print 'a'
> a
> >>> print 'a'
> a
Some commands/shells, might possibly choose to not echo input until
after they've issued the prompt - or such might merely appear to be
the case, depending on the timing and speed of the commands and such.
yon...@yahoo.com
...
>
> UNIX(/LINUX/etc.) will generally continue to accept input, even when
> not yet ready to explicitly act upon the additional input (e.g. prior
> command hasn't completed and shell hasn't issued next prompt yet).
> o if input to a subsequent command is received prior to completion of
> current command and issuance of next prompt, there are no guarantees
> that output of the current command and echoing of input for
> subsequent command(s) won't be intermingled.
Thanks a lot for this answer. It looks like on a UNIX/Linux terminal,
the intermingle of output of previous commands with the echo of later
input commands is unavoidable if the later input is sent too soon. I
was thinking of some shell setting or stty tinkering would do the
trick.
> > $ expect
> > expect1.1> echo 'a'
> > echo 'a'
> > echo 'a'
> > 'a'
> > expect1.2> 'a'
> > expect1.3> 'a'
> > expect1.4>
>
> I don't see anything incorrect in the above.
> I see three commands:
> echo 'a'
...
My point here is that this application, Expect, does the same as csh:
echo of later input precedes the display of earlier command output. You
don't see anything incorrect. You just see something annoying (at least
to me!). If we could make it so that echo of later input always lags
behind the display of prior command output, that would be ideal. In
this regard, bash does a better job than csh or Expect.
Thanks again.
Yong Huang
jKILLSPAM...@math.uu.nl
Not really. It's actually quite useful, if not necessarily tidy; if
entering some commands that take a while to execute by hand (and that
is still most likely in a shell), one can already type and edit the next
command before the last one is finished.
Joachim