FilterHN

Yes and no, with `find` I know I'm getting "live" results from the filesystem, whereas plocate (and s/locate) merely searches through a database updated god knows when, assuming it's even installed and the bulk of the files indexed.

▲

jmclnx

5 hours ago

[-]

Not bad, but one big criticism, never do a 'kill -9' first, that will stop the program from cleaning up after itself if killed using -9.

Use one of these instead:

    -TERM   then wait, if not
    -INT    then wait, if not
    -HUP    then wait, if not
    -ABRT

If you are sure all of these fail, then use -9 (-KILL). But assume the program has a major bug and try and find another program that will do the same task and use that instead.

▲

adrianmonk

1 hour ago

[-]

Maybe this logic should be built into the "kill" command (or some other standard command). Given that this is the right way, it shouldn't be more tedious than the wrong way!

It could also monitor the target process and inform you immediately when it exits, saving you the trouble of using "ps" to confirm that the target is actually gone.

▲

BenjiWiebe

2 hours ago

[-]

How often does plain 'kill <pid>' not work, but some other signal other than SIGKILL works?

Usually the process is either working correctly and terminates when asked, or else not working correctly and needs to be KILLed.

▲

consp

13 minutes ago

[-]

Lots of commandline tools will hold on to dear life except for the sigkill. I often have this with running background tasks which get one of their threads in an infinite loop or wait state.

▲

consp

15 minutes ago

[-]

This is article is likely LLM generated and it regurgitates as first go what the last resort should be. After seeing that command I stopped reading.

▲

hackyhacky

3 hours ago

[-]

> Author's note: From here on, the content is AI-generated

Kudos to the author for their honesty in admitting AI use, but this killed my interest in reading this. If you can use AI to generate this list, so can anyone. Why would I want to read AI slop?

HN already discourages AI-generated comments. I hope we can extend that to include a prohibition on all AI-generated content.

> Don't post generated comments or AI-edited comments. HN is for conversation between humans.

▲

rmunn

3 hours ago

[-]

If the author had also included a note explaining that he'd *reviewed* what the AI produced and checked it for correctness, I would be willing to trust the list. As it is, how do I know the `netstat` invocation is correct, and not an AI hallucination? I'll have to check it myself, obviating most of the usefulness of the list. The only reason such a list is useful is if you can trust it without checking.

▲

tobyhinloopen

57 minutes ago

[-]

How would you know the invocation is correct when written by a human? Don’t humans make mistakes?

▲

pjmlp

13 minutes ago

[-]

If I get that kind of content, my first reaction is to close it, it is kind of low effort content nowadays.

Unfortunely at work it isn't as easy with all the KPIs related to taking advantage of AI to "improve" our work.

▲