The Windows equivalents of the most used Linux commands(techkettle.blogspot.com) |
The Windows equivalents of the most used Linux commands(techkettle.blogspot.com) |
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
Use one of these instead:
-TERM then wait, if not
-INT then wait, if not
-HUP then wait, if not
-ABRT
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.
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.
Is it still passed when a terminal is disconnected? I understand a dial-up modem was involved in the original intended use.
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://learn.microsoft.com/en-us/windows/wsl/filesystems#ru...
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've had it on every Windows computer I used at work since forever now, and it is extremely useful to be able to use things like `sed` and `gawk` (and even `make`) from the command prompt
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.
set filepath="C:\some path\having spaces.txt"
for /F "delims=" %%i in (%filepath%) do set dirname="%%~dpi"
for /F "delims=" %%i in (%filepath%) do set filename="%%~nxi"
for /F "delims=" %%i in (%filepath%) do set basename="%%~ni"
echo %dirname%
echo %filename%
echo %basename%
$file = Get-ChildItem "C:\some path\having spaces.txt"
Write-Output $file.DirectoryName
Write-Output $file.Name
Write-Output $file.BaseName
$file = gci "C:\some path\having spaces.txt"
echo $file.DirectoryName
echo $file.Name
echo $file.BaseName
Get-Item "C:\some path\having spaces.txt" | select DirectoryName, Name, Basename> 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.
Most of my issues with it are probably just skill issues tho since like i said i dont really use or know it alot so i am happy to be corrected :) I mean if every Windows Sysadmin tells me how great powershell is, i cant just assume that they all are wrong (Or maybe its just the only way todo something thats otherwise simple over the terminal on windows, idk)
This applies to errors of course, there are a number of properties for an error that you can look at (and use in scripts to handle errors) if the full output is too much or unclear.
Just because it's the mess we are all intimately familiar with, doesn't make it less of a mess.
ctrl+r
Why this entry is in the top 30?
I'll start:
Linux : trash-empty
windows equivalent: format C:
Linux : sudo apt update && sudo apt upgrade
Windows equivalent: shutdown /rThat's why you can't just vibe-code something and expect it to work 100% correctly with no design flaws, you need to check the AI's output and correct its mistakes. Just yesterday I corrected a Claude-generated PR that my colleague had started, but hadn't had time to finish checking before he went on vacation. He'd caught most of its mistakes, but there was one unit test that showed that Claude had completely misunderstood how a couple of our services are intended to work together. The kind of mistake a human would never have made: a novice wouldn't have understood those services enough to use them in the first place, and an expert would have understood them and how they are supposed to work together.
You always, always, have to double-check the output of LLMs. Their error rate is quite low, thankfully, but on work of any significant size their error rate is pretty much never zero. So if you don't double-check them then you're likely to end up introducing more bugs than you're fixing in any given week, leading to a codebase whose quality is slowly getting worse.
So really what "kill" would be doing is automating a common procedure, which is different than taking responsibility for doing it correctly. It would need to be configurable.
I still think it would be a net benefit since right now incentives push people toward doing something the wrong way (even if they know better). But I can also see how it might give people a false sense of security or something along those lines.
It's not common. If `kill` on its own (which does just SIGTERM) doesn't work, you're already in "something wrong is happening" territory, which is why:
>>> Given that this is the right way, it shouldn't be more tedious than the wrong way!
is also the wrong way to think about this. Trying a sequence of signals is not so much "the right way" as it is "the best way to handle a wrong situation". The right way is just `kill` on it's own. SIGTERM should always suffice. If it doesn't to the user's satisfaction for a nonjustifiable reason, then you can just `kill -9`, but this should be rare.
Trying a sequence of SIGINT, SIGHUP, and SIGABRT is technically better than SIGKILL but not really important unless you also want to write a bug report about the program's signal handling or fix it yourself. About SIGINT and SIGHUP, if SIGTERM doesn't work, it's unlikely that SIGINT or SIGHUP would. Likely, it would only be through oversight and the execution of default handlers.
`kill -9` is just like `rm -rf`. I wouldn't suggest that `rm` automatically run with `-r` or `-f` when `rm` on its own didn't work, and I wouldn't call automatically trying those flags "the right way".
I just dont see how Remove-Item is superior to rm and thats just the first example that came to mind (Atleast there are aliases for most stuff afaik so i guess its not AS bad).
I also just googled and there seem to be 3-4 different commands (not including the aliases) that do EXACTLY the same thing, atleast the Microsoft article used 1:1 the same description for all of them.
It's about having a high degree of systematization and standardization and detailed guidelines around command structure and behaviour. The same with parameter naming and handling. About actually being able to work with typed data at input/output/pipes instead of only raw bytes, with all the benefits that entails (and a "standard library" of cmdlets/modules liberally making use of that). And so on. Having the whole .NET runtime available as a first-class citizen if needed is a nice bonus as well.
Don't mistake lack of familiarity for obtuseness.