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.ra...@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 c...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>
--
Met vriendelijke groet,
Valentin Bajrami
