4 ms·
Counter argument: most of these commands are great if you want to do shell scripting (including one-offs that you never save to a file), where you chain command
by TheRealPomax 2y ago
Counter argument: most of these commands are great if you want to do shell scripting (including one-offs that you never save to a file), where you chain commands to do work for you. But I've never needed anything except for `ls` and (rarely) `chmod` for my actual day job, especially since everything I write needs to work cross-platform. Shell script has been the bane of "and folks on Windows should also be able to contribute" open source developers. I consider these great commands to know for personal automation, or when doing Unix(like)-only dev work, but they're the complete opposite of essential for cross-platform development. Not intimately knowing them means you literally can't be tempted to integrate them into a team-wide/project-wide workflow.
Maybe if Windows had grown up with the same Unix tools from day one, the story would be different, but as it stands if I want to do cross-platform development, I'd much rather use the tools I know that Windows devs on my team (and community contributors) can also use, so that we're all using the same tooling and everyone can help everyone else when that tooling falls short.
A lot of things in this article are (for better or for worse) "just do X in VS Code" these days, with support for a "project-recommended extensions" file that you check into version control so that folks forking/cloning automatically get told which extensions they will want to get up to speed with the rest of the team. Because if there's a "common" unix command chain, good chance there's an equivalent cross-platform extension for VS Code for it. If it's not already built in of course.
The essential part is knowing how to do get the result you need for yourself, and how to automate the tasks of getting those results using tools that everyone will be able to use if you're doing dev work (paid or as volunteered) for someone else.
- theamk 2y agoIt's 2024, why are we still caring about windows native development? Sure, if you have unlimited resources, or your target audience is predominantely Windows (gaming or non-web large enterprise apps), you can worry about Windows. Otherwise, tell them to install WSL and do all you day-to-day work in *nix environment. No one but your CI have to touch Windows.
- TheRealPomax 2y agoI didn't say "native Windows", I said cross-platform. The kind where the tooling you use works on every OS. Cross platform is literally the opposite of "anything-native": you workflows and tooling are OS-agnostic, even if the end results are binaries specific to all major OSses (and of course, a lot of dev work never involves generating binaries)
- theamk 2y agoSorry, I was not clear: by "native Windows", I meant the Window-specific tooling (batch files, powershell, registry etc...). This is a whole separate world in the opposition to *nix (which today means Linux, BSDs and Max OS) which use things like bash, coreutils, and so on. My point that now, in 2024, there is really no need to bother with both Windows and *nix support, unless you have special requirements. "Cross platform including non-WSL Windows support" is much more complex and limited than "cross platform which requires WSL on windows", and no one should waste their resources on that without a very good reason. It's perfectly fine to require *nix-like OS for your workflows and enjoy the ease and compatibility that this brings to the table. This is especially important for open-source contributors, too: someone running Mac OS or Linux is going to be heavily discouraged from contributing any scripts if all scripts are required to be Windows-compatible. And someone running Windows might contribute powershell script but that would be useless for non-Windows people, limiting its utility. My advice to everyone is: unless your app is in Windows-heavy niche, drop non-WSL windows support requirement.
- TheRealPomax 2y agoI also didn't say "windows specific tooling". A modern code editor or IDE already covers 80%, if not more, of what the article's tools cover. You don't need separate applications for the things that article explains as use-cases. And by not using or advocating unix-specific command line utilities, you solve two problems: people don't need to learn commands they don't want to learn, and the tools that you do use tend to be cross-platform by default. Anyone on Windows, Linux, MacOS, FreeBSD, etc can use those same tools. Telling a contributor "we recommend using VS Code with these extensions" in 2024 is pretty much the lowest barrier to entry you could ask for. Whether your build tooling requires platform-specific tools is a completely different issue: this article and my comment on it isn't about that context. They're about commands that the article claims are essential to you, a person, in order to be a better developer. And to that statement my response is: you really don't. These can certainly be useful to know, but they're also completely optional.
- ElectricalUnion 2y agoI find Git Bash (bundled with Git for Windows, MSYS2 based), MSYS2 or WSL2; at least one of with I expect being installed on any "developer machine"; works fine for any non-obscure shell scripting need.
- TheRealPomax 2y agoThey all work, and a good cross-platform project setup forces you use exactly none of those. WSL/WSL2 in particular is the absolute worst in terms of "okay now use not your OS inside your OS". Just give your team a docker image then.