Re: Possibly a bug

[Valentin Bajrami]

Hi Chet,

I see. But how would I avoid this? Using Fedora 21 here and my command_not_found_handle()  is

command_not_found_handle ()
{
    local runcnf=1;
    local retval=127;
    [[ $- =~ i ]] || runcnf=0;
    [ ! -S /var/run/dbus/system_bus_socket ] && runcnf=0;
    [ ! -x /usr/libexec/packagekitd ] && runcnf=0;
    if [ $runcnf -eq 1 ]; then
        /usr/libexec/pk-command-not-found "$@";
        retval=$?;
    else
        echo "bash: $1: command not found";
    fi;
    return $retval
}

Would I then use  kill -ttin %1  for example to remove the specified job from the jobs list?  Is this the behaviour of  command_not_found_handle function?

Thanks!

On Mon, Apr 20, 2015 at 11:13 PM, Chet Ramey <chet.ramey@case.edu> wrote:

On 4/20/15 5:01 PM, Valentin Bajrami wrote:

> Now when running ./history | his  where his is not an existing command it
> fails and adds an entry in the job list.
>
> $ ./history | his
>
> [2]+  Stopped                 ./history | his
> bash: his: command not found...
>
>
> Running twice the output becomes:
>
> $ jobs -l
> [1]-  6556 Killed                  ./history
>       6557 Stopped (tty input)     | his
> [2]+  6830 Stopped (tty input)     ./history
>       6831                       | his
>
> I seem not to be able to clean up the jobs.
>
> Can anyone explain what is really happening?

It's most likely that you have a shell function defined for your
command-not-found hook (command_not_found_handle) and that function
attempts to read from the tty, or calls a program that does, causing the
process group to stop due to SIGTTIN.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

--

Met vriendelijke groet,

Valentin Bajrami