31–40 of 72 posts
My most used windows command is, and will always be, `ls`. Then I'm reminded that it's not a know file or directory.
Same! Closely followed by 'cat' lol. 'type' just doesn't register in my brain
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.
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.
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.
I'll start:
Linux : trash-empty
windows equivalent: format C:
Linux : sudo apt update && sudo apt upgrade
Windows equivalent: shutdown /rNot 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.
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.
Is it still passed when a terminal is disconnected? I understand a dial-up modem was involved in the original intended use.
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.
How often does plain 'kill ' 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.
Signal 9 cannot be ignored.