On one our linux machine filesystem became strange, probably because somebody mistyped `ls /bin` as `ln /bin`. I think docs say hardlinking folders is impossible or maybe /bin was a symlink.
> 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.
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.
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.
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.
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.
Different programs may take different amounts of time to cleanup and close. To know if a signal failed takes human judgment or heuristic. A program receiving a signal is even able to show a confirmation dialog for the user to save stuff, etc. before closing.
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.
Ah, I see, googling the equivalent of "clear" was too much work and you had to get an LLM to do it for you. Well at least you were honest about it
Then I'm reminded that it's not a know file or directory.
I understand that DEC TOPS 20 influenced CP/M and MS-DOS, so that could be the source for type.
https://en.wikipedia.org/wiki/TOPS-20
Edit: type has its own wiki, and TOPS-20 implemented it.
https://en.wikipedia.org/wiki/TYPE_(DOS_command)
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.
Unfortunely at work it isn't as easy with all the KPIs related to taking advantage of AI to "improve" our work.
> Linux: find / -name "config.txt"
This is not how you find a file across the entire system, you use plocate for that. find would take ages to do what plocate does instantly
In fact, "find" is guaranteed to be more correct. And more widely available.
Use one of these instead:
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.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.
Is it still passed when a terminal is disconnected? I understand a dial-up modem was involved in the original intended use.
Usually the process is either working correctly and terminates when asked, or else not working correctly and needs to be KILLed.
Signal 9 cannot be ignored.
ctrl+r
netstat works perfectly fine on linux as well. If you're looking for https connections it's certainly far more efficient than 'lsof'.
also if you use '-n' then you're not going to get service names translated, so that probably should be:
netstat -n -a | find "443"
I'll start: