bug-parallel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNU Parallel Bug Reports Bug in 'parallel -uXj1 vim'


From: Gary Johnson
Subject: GNU Parallel Bug Reports Bug in 'parallel -uXj1 vim'
Date: Tue, 3 Mar 2015 01:17:59 -0800
User-agent: Mutt/1.5.20 (2009-06-14)

I recently updated parallel on a couple of my Linux systems from
version 20100922 to version 20150222.  I soon discovered that using
parallel to run vim with a list of files from stdin no longer works
properly.

For example, using the old version:

    $ cd /usr/local/src/parallel-20100922/parallel-20100922/src
    $ ls *.1 | ./parallel -uXj1 vim

This opens vim with an argument list of "parallel.1 sem.1 sql.1".
Quitting vim then restores the terminal to the state it was in prior
to executing parallel.  This is what I would expect.

Using the new version:

    $ cd /usr/local/src/parallel-20150222/parallel-20150222/src
    $ ls *.1 | ./parallel -uXj1 vim

The first thing that appears on the screen is this message:

    Vim: Warning: Input is not from a terminal

Then vim opens with an argument list of "niceload.1 parallel.1 sem.1
sql.1" and seems to work fine.  Quitting vim leaves the terminal in
a corrupted state without echo or carriage returns.

Before running parallel, stty shows this:

    $ stty
    speed 38400 baud; line = 0;
    eol = M-^?; eol2 = M-^?; swtch = M-^?; stop = <undef>;
    ixany iutf8

After running the new parallel, stty shows this, edited to restore
the carriage returns:

    $ speed 0 baud; line = 0;
    intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = 
<undef>;
    start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>;
    werase = <undef>; lnext = <undef>; flush = <undef>; min = 0; time = 0;
    -brkint -icrnl -imaxbel
    -opost -onlcr
    -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

The behavior of the new parallel with the new --tty and -X options
is even worse.

    $ ls *.1 | ./parallel --tty -X vim

Nothing happens after hitting Enter on that line except that the
CR/LF is echoed.  Ctrl-C has no effect.  Executing 'ps -Hfu gary' in
another terminal shows the command apparently running--there is just
no output to or control from the terminal.

    bash
      perl ./parallel --tty -X vim
        vim niceload.1 parallel.1 sem.1 sql.1      

Killing vim from another terminal with sigterm causes the following
to appear on the terminal in which parallel was running.

    4 files to edit

    .\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
    .\"
    .\" Standard preamble:
    .\" ========================================================================
    .de Sp \" Vertical space (when we can't use .PP)
    .if t .sp .5v
    .if n .sp
    ..
    .de Vb \" Begin verbatim text
    .ft CW
    .nf
    .ne \\$1
    ..
    .de Ve \" End verbatim text
    .ft R
    .fi
    ..
    .\" Set up some character translations and predefined strings.  \*(-- will
    .\" Set up some character translations and predefined strings.  \*(-- will
    .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
    .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
    .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
    .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
    .\" nothing in troff, for use with C<>.
    Vim: Caught deadly signal TERM                                1,1           
Top
    Vim: Finished.
    Vim: Warning: Output is not to a terminal

I also tried using 'vim -N -u NONE' instead of just 'vim' to remove
the effect of my ~/.vimrc, but there was no difference in behavior
(except for the appearence of the first file because of settings in
my ~/.vimrc).  The behavior is also the same using xterm or GNOME
Terminal.  The results above were obtained from a system running
Ubuntu 10.04.4, but I observed the same behavior on a system running
Fedora 17.  I am currently using Vim 7.4.640.

I hope that's clear.  Please let me know if there is anything else I
can do to help resolve this.

Regards,
Gary




reply via email to

[Prev in Thread] Current Thread [Next in Thread]