WSL1 is generally better for these usecases.
Coreutils for Windows
201–210 of 260 posts
Re: Coreutils for Windows
#202Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes. Or better yet, just switch everything to full POSIX. 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 con…
maybe windows should actually just become linux
Re: Coreutils for Windows
#203Nice. I appreciate the effort to make things less painful for powerusers. I had noticed some of these working already in PS. 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
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.
Thanks. Wasn’t aware of gip
Re: Coreutils for Windows
#204ReFS -> ZFS
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
Re: Coreutils for Windows
#205Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes. Or better yet, just switch everything to full POSIX. 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 con…
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…
UTF-16 is the internal format of the ICU library (International Components for Unicode, the support library from the Unicode standards people) which is a common way to add "full fat" Unicode support to a programming language. This has knock-on effects everywhere. If you're using ICU, you either use UTF-16, too, or you constantly convert back and forth every time you interact with ICU. You're often best off using UTF-16 in memory and only converting to UTF-8 when you write files or transmit over the network.
Re: Coreutils for Windows
#206Earlier quoted context omitted.
POSIX was implemented as a subsystem. And it was never _fully_ implemented, as my post said. The NT kernel doesn't support certain POSIX semantics (fork).
WSL1 DOES implement fork() for WSL1 lightweight processes in the lxcore.sys driver: https://learn.microsoft.com/en-gb/archive/blogs/wsl/windows-...
The NT kernel does not understand fork(). You can-sorta-fake-it, which is what WSL1 did. There's no equivalent to fork() in any version of Windows. From your link:
> As an example, the Linux fork() syscall has no direct equivalent call documented for Windows. When a fork system call is made to the Windows Subsystem for Linux, lxcore.sys does some of the initial work to prepare for copying the process. It then calls internal Windows NT kernel APIs to create the process with the correct semantics, and completes copying additional data for the new process.
The MSFT driver prepped something-like-fork and then called the native NtCreateProcess, which does not implement anything like fork().
Re: Coreutils for Windows
#207Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes. Or better yet, just switch everything to full POSIX. 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 con…
>> Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes.
{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).
Re: Coreutils for Windows
#208Earlier quoted context omitted.
users , especially non-technical, find it highly useful in my experience. Is it a net positive to get rid of them, or will it largely only make developers happier ?
It’s arcane and technical for no reason. /Users/ME/Documents, /Media/MyThumbDrive/…, etc. are much clearer and less confusing than C:\…
At the very least, drive letters do make SMB shares a bit simpler for the non technical folks. T:\MyData is easier for them than \\0010-somehost-win.site1.mycorp.loca\Share01\MyData\
I used to support a group of completely tech illiterate users in construction & manufacturing. Them figuring out T:\ was hard enough, ask them to type in a UNC path into the address bar in explorer and you get "Wtf is file explorer? Wtf is an address bar? Where is the backslash key??"
Re: Coreutils for Windows
#209So dir is not shipped due to conflict with built-ins, echo and rmdir are shipped despite conflicts, and sort is deemed not to have a conflict? What is the logic?
I think if it conflicts with a CMD command it's not shipped, but if it conflicts with a powershell command it's ok.
Echo doesn't conflict with CMD?
Re: Coreutils for Windows
#210So dir is not shipped due to conflict with built-ins, echo and rmdir are shipped despite conflicts, and sort is deemed not to have a conflict? What is the logic?
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.
Echo doesn't conflict with the DOS command?