Yes, both of you show examples where bg <PID> would work and is exactly what I talk about.
balooctl yadayadayada &
Then while seeing the chatter just type bg and all processes visible in cli is sent to the background.
You can biring it back with fg.
You can also specify PID if you have multiple things running simultaneously.
This is not a bug, it’s a feature.
@bedna, we’ve aforexplained in detail why that is incorrect. You’ve merely restated (albeit in a thankfully more precise manner) what you’ve aforestated rather than contradict our responses. I suggest you re-read them.
No friend, you explained you do not understand. 
Try what I typed and you’ll see. (end the balooctl command with an & to get to cli after the command)
balooctl enable &
Id Name PSJobTypeName State HasMoreData Location Command -- ---- ------------- ----- ----------- -------- ------- 1 Job1 BackgroundJob Running True localhost balooctl enable
@bedna, I don’t quite understand how this relates.
Exactly, it is running, and in cli type bg and recheck, it will still run but without chatter.
You can use jobs or ps | grep balooctl to see the process.
@bedna, regardless, I fail to understand why this is superior to the standard method of providing output — taking control of the shell — especially since it means that my terminal’s prompt interrupts its output.
That is cli, that is how it is SUPPOSED to work. 
Would be pretty worthless with a console if it didn’t give feedback.
@bedna, not with any other command. For instance, zypper, apt, pkg and dnf do not do this, even though they continually provide output like balooctl does.
Likewise, nor do more directly comparable commands, like those which output logs for running GUI programs, like konsole or plasma-discover.
???
Does apt, zypper, pkg and dnf not give you any feedback in cli until they are done?
Now you are just silly buddy.
@bedna, that response demonstrates a lack of reading comprehension, and I’ve no interest in someone willing to so casually disparage me when I’m trying to (painfully) inform them.
Re-read:
Ok, if you do not want to learn, I am not investing time.
@bedna, I am willing. You are not. Merely stating otherwise shall not convince onlookers, especially since I’ve quoted you. Your constant passive aggression further demonstrates this.
You could have merely apologized — still, I shall accept one, or a reasonable explanation of why what I have stated is incorrect.
This is infantile. You should read FAQ - KDE Discuss again, too.
@bedna No, you are wrong. Try it.
The example code I’ve shown isn’t exactly what balooctl is doing, but it is similar enough that bg and fg will not work on that. The shell commands bg and fg do not work on process IDs (“pid”), they work on “shell jobs” and they take “jobspec”:
fg [jobspec]
Resume jobspec in the foreground, and make it the current job. If jobspec is not present, the shell’s notion of the current job is used.
I’ll repeat the example shell code I wrote for completeness:
( while true; do echo test; sleep 3; done & )
The backgrounding of the task using the & indeed creates a shell job, but it is a job inside a sub-shell and as soon as that sub-shell ends - its job management ends and you cannot create a jobspec that addresses the job in the shell that ended.
The balooctl case isn’t even that - its just spawned a process in the background directly using fork(), it has no shell job and there never was a job that you could reattach to.
@guss77, I don’t actually see a relevant report at Bug List, so I’m going to file a Log in to KDE Bugtracking System myself, referencing "balooctl purge" fails to stop Baloo - #33 by guss77.
I do not want to use baloo, so I can not.
My bad, I was stressed, the & and bg is obv the same thing. LOL.
I was thinking of using ctrl + z, % and all that jazz.
You need to use the OTHER I mentioned, disown.
You can ofc also just redirect the output with yadayadacommand --andstuff > /dev/null &.
Yes, ok? Kinda what you want right?
If you run sudo apt upgrade -y you kinda want the application to end when it is done.
Not sure what your point is.
Just type disown, add -h if you want to be able to log out and having it still running.
The fact you get feedback when starting something in cli is obviously not a bug, it’s a feature.
I think you missed the point of what I was trying to say, but NM. I think this has gone long enough of course as it is.
Nobody has ever debated that, @bedna.
Ah Baloo, a solution in search of a problem. It reduces my computer to a very slow crawl, and has done so since KDE 4, every time I try it.
The last time was when I thought I’d give Kmail, my go to email client on KDE 3, a try, and Baloo was activated when I attempted to import my email from Claws-Mail. Thus ended my attempt to use KMail, which I promptly removed, as well as making sure Baloo never again caused me any problems
I had my share of issues with Baloo, but right now we are living together in peace.
I like the fact that when I search for files, I don’t have to wait until the entire 1TB disk is scanned, but it is important to tell Baloo to ignore several directories that include a lot of files but are otherwise not a likely to be useful as search results, like ~/.cache, ~/.config or ~/.local. Also - its good to keep an eye on the size of the Baloo database at ~/.local/share/baloo - mine is at about 1.2GB, which is a good size. If it grows to more than 10GB - see if you can blacklist some more folders you have many files in but don’t actually need to search in, then purge the baloo database and let it index it again.