Earlier quoted context omitted.
Use powershell. Get-ChildItem /w
Too many keystrokes, people won't use it.
Aliases
Coreutils for Windows
221–230 of 260 posts
Re: Coreutils for Windows
#222Earlier 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.
All the layers, except applications where devs still look for the wrong slash manually.
OSes and modern programming languages have APIs for file navigation for a reason.
On Windows this implies old applications from another era, good old command window, or people that don't know better.
Re: Coreutils for Windows
#223Earlier quoted context omitted.
At which layer? dir /w, for example, is never going to list the contents of \w.
The kernel and ntfs does not care about slash direction. Specific programs like dir might though and honestly if you're on windows just use powershell and avoid legacy cmd stuff.
Additionally on programming languages use the apis for path management, instead of explicit looking for the \ or / characters.
Re: Coreutils for Windows
#224Windows 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).
Windows has been doing for quite a while, that is how COM strings work.
Re: Coreutils for Windows
#225Earlier quoted context omitted.
There's almost no point to this, especially since they're already shipping a (strictly) limited subset with the reasoning "not useful on Windows" despite Windows equivalent facilities _clearly_ existing. They should have at least considered a full native port.
They've already made a few attempts over the years (Windows Subsystem for UNIX comes to mind), neither really caught on, except WSL. I also don't quite get why one would want such a setup - why not just use MSYS2 or WSL? As it is, it's just a mishmash of CMD builtins, Windows utils, Powershell, and these Coreutils. Will one have to use CMD-style (%var%) variables or will it be the POSIX way ($var)? Also just keeping…
You are missing part of the history,
Windows NT shipped with three personalities, OS/2, POSIX and Win32.
OS/2 was more of a compatibility thing than anything else, given the OS/2 history between IBM and Microsoft.
POSIX subsystem was half backed implementation, only enough to check some boxes in US government contracts, naturally it never took off. In fact, many people including myself, only never considered GNU/Linux, if Windows NT POSIX support was at the same level as any other UNIX, like it happens on mainframe and micros OS environments, e.g. PASE on z/OS.
Then as Windows actually started to take over UNIX workstations, with Win32 as main subsystem, there was MKS Toolkit as commercial product, Microsoft felt the complaints about the POSIX subsystem, then we had Interix acquisition, which evolved into Windows Services for UNIX, that you mention. Still not without quirks.
WSL took off, because given the experience on OS X, where devs buy Apple expecting GNU/Linux instead of POSIX, Microsoft took the right decision to offer GNU/Linux right from the start instead of yet another POSIX attempt.
By the time WSL came to be, it was already a standard practice to use Virtual Box or VMWare workstation instead of mingw/cygwin, so even better not having to install them.
Ironically I learnt UNIX on Xenix, when it was still sold by Microsoft, maybe they should have kept it.
Re: Coreutils for Windows
#226Windows 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…
> ... 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
The experience with Windows Services for UNIX wasn't that great, so yet another good product killed via acquisitions?
I only know it post acquisition.
Re: Coreutils for Windows
#227Earlier quoted context omitted.
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 consist…
> outputs being objects is a really solid take. 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.
Inspired by the ways of Xerox, Genera and ETHZ.
It can be verbose, but the object approach, and having .NET, DLLs and COM as first class primitives is quite flexible.
Naturally you can have a similar experience on UNIX, e.g. fish, but very few do it.
Re: Coreutils for Windows
#228Earlier 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…
UNIX and Windows aren't the only OSes on the planet, even though UNIX folks tend to assume that.
Heck many mistake UNIX with GNU/Linux even, and then complain when given a UNIX that isn't a Linux distro.
Re: Coreutils for Windows
#229It's not seamless now is it if half the commands don't work.
Wine and other compatibility layers show that non-trivial software doesn't work if even one of the many layers uses something unsupported.