In powershell everything is much better than cmd, but it's just not enough.
WSL is generally great, but there are annoying downsides. I often get "catastrophic" crashes and the zone identifier files drive me nuts. Plus it takes so much longer to start VSCode when connecting with WSL, and now you've got two file systems. WSL1 was in many ways better than WSL2 for these reasons.
"UTF-16 is used by the Windows API, and by many programming environments such as Java and Qt. The variable-length character of UTF-16, combined with the fact that most characters are not variable-length (so variable length is rarely tested), has led to many bugs in software, including in Windows itself.
"UTF-16 is the only encoding (still) allowed on the web that is incompatible with 8-bit ASCII. It has never gained popularity on the web, where it is declared by under 0.004% of public web pages (and even then, the web pages are most likely also using UTF-8). UTF-8, by comparison, gained dominance years ago and accounted for 99% of all web pages by 2025."
You can use UTF-8 on a per-application basis, within limits.
https://learn.microsoft.com/en-us/windows/apps/design/global...
Conversely, UEFI is UTF-16 only, thanks to Windows.
UTF-8 only would be an ABI breaking change, so that's not going to happen. We don't want the NT kernel to end up like Linux, after all :-)
Worse are the byte order marks required to support both endians that end up in files.
Web browsers use UTF-16 internally. So Windows isn't even largest "platform" that uses UTF-16.
an interesting tidbit, some Windows kernel developer realized that most registry keys are ascii anyways so they could save up to 50% space simply by storing the name as ascii. The flag is called "compressed name" and they will pad with 0x00 when reading the name to make a proper utf-16 string.
You cannot ditch CRLF, Microsoft isn't Apple.
Windows accepts backslashes and forward slashes, only old applications that manually search for one of them get it wrong.
Really not possible as most of POSIX semantics arise naturally from the kernel (or are enforced/executed at the kernel level). Windows technically provides some of them (or semantic equivalents) so you could make something work, but in order to do a full port you'd need to strip out too many concepts for it to be worthwhile. For instance the idea that "everything is a file" or the single root filesystem layout (which iirc is segmented deeply at the kernel level).
The kernels undoubtedly take different approaches. But there's nothing in NT that strictly prohibits POSIX compatibility layers. As we see with the many compatibility layers that have existed for Windows over the years.
> For instance the idea that "everything is a file"
POSIX doesn't have a concept of "everything is a file". That's Plan 9. UNIX and POSIX actually made numerous concessions here and there are plenty of constructs that are not exposed as a file.
Windows does already abstract a few primitives as files too. In fact even DOS has the concept of device files, though in typical Microsoft fashion, it's implementation was a clusterfuck that took MS 40 years to fix.
> or the single root filesystem layout (which iirc is segmented deeply at the kernel level).
NT uses an object system for filesystem objects, but it still has a root. As you can see in the WinObj (eg screenshot below)
https://learn.microsoft.com/en-us/sysinternals/downloads/med...
The C:\ convention is really more there for compatibility with DOS-lineage software but the underlying filesystem APIs work fine with NT objects.
For example, C:\foo.txt might be equivalent to \Device\HarddiskVolume3\foo.txt
In this regard, it's similar to how POSIX has a database of inodes and the filesystem hierarchy is actually just an abstraction that sits on top of that
Interix[0] did a pretty good job of this, but MSFT killed it. I was compiling GNU tools w/ GCC and running bash under Interix back in in 2000 under Windows 2000. It was grand.
The only places that still forced CRLF were batch files and clipboard.
That has been my experience as well. I can't remember the last time I had an issue related to CRLF.
All software accumulates warts over time. Linux is overflowing with horrible warts and tech debt. As is any software that has successfully served customers for decades.
But multiple line endings are quite possibly the easiest most trivial thing to support and there is absolutely no negative cost of any kind in doing so. Linux ecosystem chooses to be stubborn and provide a strictly worse user experience out of pure spite and for zero user benefit. It’s very irritating.
The Linux ecosystem handles it fine (by using a single standard). Windows doesn't. That's its problem.
Hahahahaha. That's hillarious.
Oh god, you're serious?
Do you have any idea how much of Windows, and user software would break? Any idea at all?
You really want MS, who has built backwards compatibility as a core feature of Windows, to break countless thousands of pieces of software that run on it?
I'm sure there's some idealized fantasy in which that change gets wrapped in a neat little abstraction that prevents anything from breaking. I promise you, there is no way of encapsulating or abstracting that change that works for everyone.
If I could wave a magic wand and make it so without breaking it, I would. But it's a fantasy.
I'd estimate millions
{To the extent such stuff is pragmatic:} I think we should switch to Pascal-style strings everywhere, and then have no need for having special-purpose characters like path separators (a path now being a list of strings).
powershell is good. its much better than unix's everything piped is Text idea. godawfull that. outputs being objects is a really solid take.
WSL is trash.
besides that, lf vs. crlf is silly as you mention but crlf is more logical considering what its implementing. that being said the notion of these control chars is already based on outdated and limited ideas.
if you want a consistent system to do things with dont pick a system which tries to be two systems.
Linux has wine. Windows has WSL.
I'd recommend BSD. any flavor will do.
might take some adjustments but you will have a more 'rational' system if that is what you desire.
(otherwise, embrace the madness!)
Glad I'm not alone here ha!
Being able to go someoutput | Format-Table | Select ColumnName,ColumnName,CloumnName is great. Beats memorizing the output format of any specific command and trying to wrangle it with awk.
Windows needs to ditch itself.
Otherwise just don't do it, if it is going to be a mess to work with.
Well this is not very satisfying, what about proving a way where it actually works without us having to guess where the failure root cause happens to be?
So ls in many systems will match the behavior of dir, and only accept the flags for dir. But if you use a system with the newer coreutils release here, ls will expect ls flags!
So ls would actually match the behavior and accept the flags for Get-ChildItem, not dir.
Start a terminal session where they come first in the PATH?
That way one knows where they are getting into.
That was the most plausible reason to even mention it, that I could think of.
The shred command relies on a crucial assumption: that the file system and hardware overwrite data in place.
...
many modern file system designs do not satisfy this assumption. Exceptions include:
...
Log-structured or journaled file systems, such as.
...
NTFS.
When on Windows, the models default to bash / coreutils conventions until they realize it doesn't work / not available unless explicitly instructed otherwise.
Even on Mac, they tend to default to bash instead of running things in zsh.
If you told me during the Windows 7 era the Windows CLI would not only be getting nice but getting pretty comfortable I would never have believed it.
If they just kicked them out and left the Windows div alone it'd be a decent OS. All the bones are there.
I know I could use Powershell for those kinds of tasks, and I certainly do make a lot of use of Powershell, but the familiarity of those simple tools and the decades-old "muscle memory" of using them on various Unix, Linux, and Windows boxes makes them hard to ditch.
The project includes all of those. Or were you talking about the past?
A gigantic idiot. Sorry.
"Note: Any command not mentioned is included in this suite. "
which I found quite confusing. It's a very large set, potentially infinite depending on what the universe of all commands is :)
You should link to the list of all the commands in your package.
More project information: https://gitforwindows.org/
Official download: https://git-scm.com/install/windows
I explained the differences here: https://news.ycombinator.com/item?id=48375716
There's a "%SystemRoot%\System32\find.exe" on every Windows NT-derived OS. That's absolutely a conflict.
Also, the "find" command from "findutils" is in no way functionally similar to the "original DOS command" (which is for finding text in files).
Aside: Eschew "find.exe" on Windows for "findstr.exe". The latter is vastly more efficient. I discovered that by happenstance once and have trained my hands to type "findstr" when I mean "find" on Windows.
This is one of the few features that Linux file systems do not have.
It’s annoying enough to support the differences between BSD and Linux, and now Linux has GNU and uutils, and now we’re gonna need Windows variant of uutils…ugh.
It seems to be working as intended for uutils.
Microsoft "loves" Linux for years and the entire point was to bring the Linux userspace on the Windows Desktop.
The reason seems to be a few windows specific fixes (https://github.com/uutils/coreutils/compare/main...microsoft...) which can probably be upstreamed into the main repo.
WSL2 is great, but native POSIX is even better. Of course it’s a big undertaking, but it makes Windows a first-class dev platform for those who need POSIX in production.
And that would suck.
However, I'm not keen on using yet another Unix clone as well. At least Windows NT brought the world into 90s in the OS state-of-the-art where Unix clones are stuck in 80s and each of them patch around the deficiencies of POSIX. Native asynchronous APIs and truly object-oriented system call infrastructure is nowhere to be found in POSIX.
Also, MS does absolutely support EoL versions of their OS - it took MSVC's STL until 2024 to finally drop support for Windows 7 (whose final ESU update was 2023): https://github.com/microsoft/STL/issues/4858 - it isn't unlikely that they (STL maintainers) are not going to get approval for dropping Windows 10 support before 2029.
https://unxutils.sourceforge.net/
Busybox's shell is ash, but the above set includes an old zsh IIRC.
Note also that the Frippery Windows busybox is available as a 64-bit version, in case 2gb is not enough (easy with some big awk associative arrays).
If anyone from MS is reading this can we please also get an equivalents (or even alias) for the thing that shows IP address? The windows equivalent of "ip a" is some convoluted PS command that I can never remember
> gip
You could also make your own alias if you specifically want to type "ip a" just add a powershell function to your $PROFILE. function ip { param($argument)...." etc. have it call Get-NetIPAddress, else fallback to ipconfig.
https://www.gnu.org/software/coreutils/manual/html_node/dir-...
winget install uutils.coreutils
winget install -e --id frippery.busybox-w32
https://www.gnu.org/software/coreutils/manual/html_node/ln-i...
I didn’t see less or a decent pager. MS needs their analytics on WSL and implement the top 50 commands on powershell
Powershell is very good, but lacks brevity and convenience of coreutils so this should be a big win.
On Windows it is possible of course, WSL, msys, what not, but it is cumbersome. And I hate the default compiler on windows. So if coreutils on windows helps simplify all the base toolchain, I am all in favour of it. Windows really needs to make compiling stuff a LOT easier by default. I don't want to download some x GB of stuff I don't really need.
Wine and other compatibility layers show that non-trivial software doesn't work if even one of the many layers uses something unsupported.
Remove batch, VBS and switch from powershell 5 to 7, add bash
Replace DSC in favour of Ansible
Remove windows registries
Switch to systemd for services
Rename folders like Users to home, programdata to etc, program files to opt, store/winget apps /usr
and call it microsoft linux server hybrid
