Fully-qualify the path to the target program, and it should be no concern.

The best part is the reason it conflicts with a lot of PowerShell is PowerShell shimmed Linux commands over to their Windows equivalents for years even though the flags were different.

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!

As hex4def6 said, the idea was that DOS command conflicts are not a good idea, while overriding PowerShell builtins in interactive sessions (PSReadLine) is acceptable, if not a good idea. We open-sourced DOS sort and published a port of the DOS find command. The suite then dispatches to the GNU/DOS variant based on heuristics.

No idea, this is broken at start, I would expect at least a reasoning on how they expect to improve the mess going forward.

Otherwise just don't do it, if it is going to be a mess to work with.

I think if it conflicts with a CMD command it's not shipped, but if it conflicts with a powershell command it's ok.

AI said to do it.

The intent was simply to give people coming from macOS and Linux more of the CLI tools they're familiar with. In other words, agents weren't the focus at all. But if it ends up helping them, that's a good added benefit of course.

For sure. I wonder how long until the agents learn about this though. At least a year, right?

Most (everything?) on Windows actually works with forward slashes. However, much of the tooling will overwrite your version with a backslash wherever it can.

Windows is also a rare bird in UTF-16.

"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."

https://en.wikipedia.org/wiki/UTF-16

No worries, eventually Xenix will make a comeback.

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.

On Windows, I've mostly avoided CRLF by configuring text editors and git to use LF, and writing text files in binary mode.

The only places that still forced CRLF were batch files and clipboard.

Don't think this will ever happen, especially since this is Microsoft you are talking about [0]

[0] https://www.youtube.com/watch?v=bC6tngl0PTI

> Or better yet, just switch everything to full POSIX.

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).

> ... Or better yet, just switch everything to full POSIX.

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.

[0] https://en.wikipedia.org/wiki/Interix

They might as well create a new OS with a different name, because none of the existing applications will work, and no enterprise customer will use it.

No, they need to ditch drive letters first. The NT kernel and NTFS don't even require them (I used to mount disks without drive letters back in the NT 4 era). They just don't care enough to get rid of this annoyance.

the two filesystems can be a super power... i seamlessly use the same driver between wsl2 and my dual booted opensuse.

honestly your point is a bit weird.

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!)

>Windows really needs to ditch CRLF...

Windows needs to ditch itself.

Or MSYS2, to go even further. https://www.msys2.org/

Always wondered if git bash was cygwin, I don't think it is, but it seems very similar.

Windows has lacked decent ports of recent GNU tools for a while. I still use some very old ones. It would be great if MS worked on the other tool groups like textutils.

I use those commands also to filter output and fee ai agents with that. Tail and Head are my favourites to avoid wasting tokens. Wayy too many fancy build logs messages.

Shred isn't very useful on SSDs in general. Because of TRIM, deleting a file instantly makes the sectors read back as 00 bytes. (Yes the data is technically still on the flash chips scattered across memory blocks without any mapping telling you where each piece of the data is, but is not readable through normal drive commands)

From shred man:

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.

I assume it requires something exposed by the underlying filesystem.

No .DLLs would be the primary reason.

Not similar at all - too heavy weight when you just want to use a small tool.

this conflicts with native shell utilities of the same name - take that, cygwin!

Windows 10 is end-of-life; so the question itself is odd. It may work on Windows 10, but they definitely don't support an EoL version of their OS.

in PowerShell there is a built-in alias.

> 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.

ipconfig works pretty well.

They should give up.

The command line team has been doing some solid work for a while. I recognize lhecker from the also great wt & edit projects.

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.

With these AI agents using lot of linux commands, I think they have to do it.

So “supports Windows” doesn’t mean supports Windows.

Apparently the creator of the fork is also a maintainer of some uutils repositories.

citation needed

The case for that statement (if there's a case at all) is wsl. This is outside wsl.

It was really obvious.

Microsoft "loves" Linux for years and the entire point was to bring the Linux userspace on the Windows Desktop.