Loading ...
Sorry, an error occurred while loading the content.

Wait for T_CRV / T_U7 response when shut down on some UNIX terminals

Expand Messages
  • Hayaki Saito
    Hi, lists These days ago, Yukihiro Nakadaira found garbage output problem in gnome-terminal. Here are some reproducing examples: $ cd
    Message 1 of 4 , May 10, 2013
    • 0 Attachment
      Hi, lists

      These days ago, Yukihiro Nakadaira found "garbage output" problem in gnome-terminal.
      Here are some reproducing examples:

      $ cd /path/to/vim/src/testdir
      $ ../vim -u unix.vim -U NONE --noplugin -s dotest.in test85.in
      $ 1;3400;0c <- response for T_CRV

      $ vim -u NONE -N -c quit
      $ R <- response for T_U7

      $ cat quit.in
      :quit
      $ vim -u NONE -N -s quit.in
      $ R1;3400;0c <- response for T_U7 and T_CRV

      This problem is caused by T_CRV / T_U7 response sent by some VT200 compatible terminals.
      It depends on the timing factor, so it has no reliable reproducibility, and it often occurs during SSH session.

      The workaround for the similar problem with T_CRV when vim is launched with -c option already exists. (See the comment around main.c:932.)
      Notwithstanding, this example will reproduce the same problem with -c option.

      $ vim -u NONE -N -c 'call feedkeys(":quit\<CR>")'
      $ R1;3400;0c <- response for T_U7 and T_CRV

      The attached patch will fix above problems.
      This code waits some seconds when vim goes to shut down if T_CRV/T_U7 status is sent already.

      Regards, Hayaki


      ---
      Hayaki Saito

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Bram Moolenaar
      ... Thanks. Waiting for 100 msec is a bit long, does it also work when waiting for 20 msec? I guess any time will do so long as we give the terminal a chance
      Message 2 of 4 , May 11, 2013
      • 0 Attachment
        Hayaki Saito wrote:

        > Hi, lists
        >
        > These days ago, Yukihiro Nakadaira found "garbage output" problem in
        > gnome-terminal. Here are some reproducing examples:
        >
        > $ cd /path/to/vim/src/testdir
        > $ ../vim -u unix.vim -U NONE --noplugin -s dotest.in test85.in
        > $ 1;3400;0c <- response for T_CRV
        >
        > $ vim -u NONE -N -c quit
        > $ R <- response for T_U7
        >
        > $ cat quit.in
        > :quit
        > $ vim -u NONE -N -s quit.in
        > $ R1;3400;0c <- response for T_U7 and T_CRV
        >
        > This problem is caused by T_CRV / T_U7 response sent by some VT200
        > compatible terminals.
        > It depends on the timing factor, so it has no reliable
        > reproducibility, and it often occurs during SSH session.
        >
        > The workaround for the similar problem with T_CRV when vim is launched
        > with -c option already exists. (See the comment around main.c:932.)
        > Notwithstanding, this example will reproduce the same problem with -c option.
        >
        > $ vim -u NONE -N -c 'call feedkeys(":quit\<CR>")'
        > $ R1;3400;0c <- response for T_U7 and T_CRV
        >
        > The attached patch will fix above problems.
        > This code waits some seconds when vim goes to shut down if T_CRV/T_U7
        > status is sent already.

        Thanks. Waiting for 100 msec is a bit long, does it also work when
        waiting for 20 msec? I guess any time will do so long as we give the
        terminal a chance to get some CPU time.

        stoptermcap() is also used for shell commands. If someone has a shell
        command in his startup script then tcflush() might cause a problem.
        It might help to call it only when exiting.

        --
        GUARD #1: What -- a swallow carrying a coconut?
        ARTHUR: It could grip it by the husk!
        GUARD #1: It's not a question of where he grips it! It's a simple question
        of weight ratios! A five ounce bird could not carry a 1 pound
        coconut.
        The Quest for the Holy Grail (Monty Python)

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Hayaki Saito
        Hi, Bram ... No, I think 20 msec is too short for waiting for responses from terminals. Considering SSH session, It is required about 100 msec at least. The
        Message 3 of 4 , May 13, 2013
        • 0 Attachment
          Hi, Bram

          > Waiting for 100 msec is a bit long, does it also work when
          > waiting for 20 msec?

          No, I think 20 msec is too short for waiting for responses from terminals.
          Considering SSH session, It is required about 100 msec at least.
          The latency is almost as same as vim's "timeoutlen" option theoretically.

          > I guess any time will do so long as we give the
          > terminal a chance to get some CPU time

          Please note that the second argument of mch_delay in my patch is FALSE, so it returns as soon as the response from terminal arrived. Actually, It is rare case that it takes just 100 msec.

          > stoptermcap() is also used for shell commands. If someone has a shell
          > command in his startup script then tcflush() might cause a problem.
          > It might help to call it only when exiting.

          I agree, tcflush(fileno(stdin), TCIFLUSH) has some risk of discarding key inputs or terminal responses.
          But I think there is more risk that T_U7 / T_CRV responses are passed into shell commands.
          Typically, its echo-back sequence causes "garbage output" problem, and T_U7 response sequence may be interpreted as <Shift-F3> by shell commands.

          Best regards, Hayaki

          ---
          Hayaki Saito

          On 2013/05/11, at 22:50, Bram Moolenaar <Bram@...> wrote:

          >
          > Hayaki Saito wrote:
          >
          >> Hi, lists
          >>
          >> These days ago, Yukihiro Nakadaira found "garbage output" problem in
          >> gnome-terminal. Here are some reproducing examples:
          >>
          >> $ cd /path/to/vim/src/testdir
          >> $ ../vim -u unix.vim -U NONE --noplugin -s dotest.in test85.in
          >> $ 1;3400;0c <- response for T_CRV
          >>
          >> $ vim -u NONE -N -c quit
          >> $ R <- response for T_U7
          >>
          >> $ cat quit.in
          >> :quit
          >> $ vim -u NONE -N -s quit.in
          >> $ R1;3400;0c <- response for T_U7 and T_CRV
          >>
          >> This problem is caused by T_CRV / T_U7 response sent by some VT200
          >> compatible terminals.
          >> It depends on the timing factor, so it has no reliable
          >> reproducibility, and it often occurs during SSH session.
          >>
          >> The workaround for the similar problem with T_CRV when vim is launched
          >> with -c option already exists. (See the comment around main.c:932.)
          >> Notwithstanding, this example will reproduce the same problem with -c option.
          >>
          >> $ vim -u NONE -N -c 'call feedkeys(":quit\<CR>")'
          >> $ R1;3400;0c <- response for T_U7 and T_CRV
          >>
          >> The attached patch will fix above problems.
          >> This code waits some seconds when vim goes to shut down if T_CRV/T_U7
          >> status is sent already.
          >
          > Thanks. Waiting for 100 msec is a bit long, does it also work when
          > waiting for 20 msec? I guess any time will do so long as we give the
          > terminal a chance to get some CPU time.
          >
          > stoptermcap() is also used for shell commands. If someone has a shell
          > command in his startup script then tcflush() might cause a problem.
          > It might help to call it only when exiting.
          >
          > --
          > GUARD #1: What -- a swallow carrying a coconut?
          > ARTHUR: It could grip it by the husk!
          > GUARD #1: It's not a question of where he grips it! It's a simple question
          > of weight ratios! A five ounce bird could not carry a 1 pound
          > coconut.
          > The Quest for the Holy Grail (Monty Python)
          >
          > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          > \\\ an exciting new programming language -- http://www.Zimbu.org ///
          > \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
          >
          > --
          > --
          > You received this message from the "vim_dev" maillist.
          > Do not top-post! Type your reply below the text you are replying to.
          > For more information, visit http://www.vim.org/maillist.php
          >
          > ---
          > You received this message because you are subscribed to the Google Groups "vim_dev" group.
          > To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          > For more options, visit https://groups.google.com/groups/opt_out.
          >

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Bram Moolenaar
          ... OK, let s keep the 100 msec value then. ... I think we should be careful. I have seen quite a few cases where typeahead was lost, and that can be very
          Message 4 of 4 , May 13, 2013
          • 0 Attachment
            Hayaki Saito wrote:

            > > Waiting for 100 msec is a bit long, does it also work when
            > > waiting for 20 msec?
            >
            > No, I think 20 msec is too short for waiting for responses from terminals.
            > Considering SSH session, It is required about 100 msec at least.
            > The latency is almost as same as vim's "timeoutlen" option theoretically.

            OK, let's keep the 100 msec value then.

            > > I guess any time will do so long as we give the
            > > terminal a chance to get some CPU time
            >
            > Please note that the second argument of mch_delay in my patch is
            > FALSE, so it returns as soon as the response from terminal arrived.
            > Actually, It is rare case that it takes just 100 msec.
            >
            > > stoptermcap() is also used for shell commands. If someone has a shell
            > > command in his startup script then tcflush() might cause a problem.
            > > It might help to call it only when exiting.
            >
            > I agree, tcflush(fileno(stdin), TCIFLUSH) has some risk of discarding
            > key inputs or terminal responses.
            > But I think there is more risk that T_U7 / T_CRV responses are passed
            > into shell commands.
            > Typically, its echo-back sequence causes "garbage output" problem, and
            > T_U7 response sequence may be interpreted as <Shift-F3> by shell
            > commands.

            I think we should be careful. I have seen quite a few cases where
            typeahead was lost, and that can be very annoying. When checking the
            "exiting" flag turns out not to work well we can make another change.

            --
            A poem: read aloud:

            <> !*''# Waka waka bang splat tick tick hash,
            ^"`$$- Caret quote back-tick dollar dollar dash,
            !*=@$_ Bang splat equal at dollar under-score,
            %*<> ~#4 Percent splat waka waka tilde number four,
            &[]../ Ampersand bracket bracket dot dot slash,
            |{,,SYSTEM HALTED Vertical-bar curly-bracket comma comma CRASH.

            Fred Bremmer and Steve Kroese (Calvin College & Seminary of Grand Rapids, MI.)

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ an exciting new programming language -- http://www.Zimbu.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          Your message has been successfully submitted and would be delivered to recipients shortly.