181–190 of 260 posts
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.
Earlier quoted context omitted.
NT shipped with USC-2 as UTF-8 (and -16) did not yet exist. USC-2 naturally translated to UTF-16, hence the choice. NT/Win32 is also designed for fixed-with code units, something UTF-8 doesn't support. 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 chang…
> 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 :-) I think you're making a joke, but it still doesn't make sense. Linux does avoid breaking changes to its userspace ABI
You encounter encoding requirements not in kernel system calls but in more user-facing sides of the OS. So your comparison should include all the userspace components of a Linux system (e.g. gettext), if you're considering the places where you encounter actual Unicode string-based operations where UTF-16 comes into play in Windows.
ALL OF THE equivalent Windows libraries (user32.dll, kernel32.dll, ws2_32.dll, shellex.dll ...) to the Linux ones I counted above and more are ABI and API stable.
Earlier quoted context omitted.
Most (everything?) on Windows actually works with forward slashes. However, much of the tooling will overwrite your version with a backslash wherever it can.
At which layer? dir /w, for example, is never going to list the contents of \w.
Earlier quoted context omitted.
> 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 :-) I think you're making a joke, but it still doesn't make sense. Linux does avoid breaking changes to its userspace ABI
Linux kernel's ABI/API surface is completely byte-based and is tiny compared to Win32 API. The stable ABI of Windows is strictly in the user space and it covers the entire useful operating system. Don't forget that glibc isn't that ABI stable nor anything that goes all the way up to systemd/X11/gettext/Wayland/cairo/GTK/Qt/glade/Pipewire/xdg. Nothing equivalent in Linux environment is stable, especially compared agai…
> We don't want the NT kernel to end up like Linux, after all
(Emphasis mine)
And that's... The one part of the OS where Linux is ABI stable.
Earlier quoted context omitted.
> The Windows ecosystem handles it fine (by using a single standard). Linux doesn't. That's its problem. It's always funny to see how the fanbois treat their way as the one and only 'True Way'.
I didn't say it was the one and only True Way. My intended meaning - which I admit I may have poorly conveyed - is that tools from the unix ecosystem are intended to work on unix conventions, and do, and that works. Windows has different standards, which is also fine, but it follows that you shouldn't expect unix tools to follow Windows standards even if you make them run on Windows. This is like getting Windows soft…
Multi-platform is very easy and a solved problem if you try juuuust a tiny amount.
For example the Rust stdlib iterator for lines() handles both conventions. It just works. Very easy.
I live in a cross-platform world. Line endings in text files should not be a breaking problem because some CLI tool refuses to support both. That’s just plain bad software engineering.
I expect Unix tools that process text files to be capable of supporting text files that have different conventions. This is very easy. Refer to previous comments on stubbornness out of spite.
Earlier quoted context omitted.
A big part of the point is so you can use scripts made for other platforms on windows natively, which you lose when you have to alter them to pass absolute paths
It actually failed even before that. The project states "The goal is to make moving between Linux, macOS, WSL, containers, and Windows frictionless: the same commands, flags, and pipelines work the same way, so *existing scripts carry over without translation.*" ... but they failed to provide a port of Bash - so how exactly do they expect someone to run a bash script in Windows "without translation"? If the answer is…
Will we ever see a Windows-optimized version of unix utilities that avoids creating new processes? It seems like that's the step that's really slow, and if you could reuse a process to continue running more commands, that would speed things up a lot.
I would have liked to see head, tail, tr, uniq, and cut. I end up dragging over the old "gnuwin32" versions of those to a lot of Windows machines. Those are my go-to tools for quick-and-dirty log analysis. 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 Uni…
> I would have liked to see head, tail, tr, uniq, and cut. The project includes all of those. Or were you talking about the past?
"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.