Grep this: Microsoft grafts (most) Linux commands onto Windows

Steve Ballmer’s darkest fear has come to pass: Linux has worked itself into the deepest innards of Microsoft Windows itself. At the company’s annual Build developer conference this week, Microsoft released coreutils, a Rust-built multi-call binary file for Windows that serves over 75 Unix commands directly in the Windows CMD …

[JimmyPage]

There is almost nothing

you can't do in BASH, with the right few programs.

[RegGuy1]

Re: There is almost nothing

Hey, bash, sed and awk (especially awk, they wrote that in the 1980s :-O ) gave me a 30-year career.

If you are putting these tools on Windows (spit), why not just ditch Windows and go to Linux?

[R Soul]

Re: There is almost nothing

Or why not go one better and just go direct to BSD?

[Rich 2]

Re: There is almost nothing

Several better I think

[Eric 9001]

Re: There is almost nothing

I don't understand why you wouldn't go directly to the best OS (GNU/Linux-libre) with full access to all the finest GNU programs with no compromises and rather install some proprietary BSD (all of them are proprietary software, name a BSD and I'll link to some of the proprietary software).

If you currently have defective hardware and you want convenience, maybe practically you would go for the proprietary GNU/Linux (which has more support for defective hardware than BSDs).

[PB90210]

Re: There is almost nothing

BSoD is already built in

[isdnip]

Re: There is almost nothing

Because there is a huge ecosystem of Windows applications, especially on the desktop. Linux is strongest as a server and as a developer desktop; muggle users are usually better off in Windows. And in many (most?) businesses, Microsoft Office, or 365, or whatever they're calling it these days, is still the standard for document and spreadsheet production, and it doesn't run well (if at all) on Linux. Nor do the Linux office suites interwork perfectly with it.

Maybe these enhancements will help the Unix/Linux crew feel a little better when they have to work on or support a Windows system.

[Roland6]

Re: There is almost nothing

What! And do without paying the reassuring Microsoft subscription/tax.

[theOtherJT]

Re: There is almost nothing

I once wrote a webserver in bash. I'm not saying you should (or even that I should have) but it seemed like the thing to do at the time...

[Sproggit]

Imitation is the Sincerest form of Flattery

Getting on for 7 years ago, Steven Vaughan-Nichols wrote an article in Computerworld, titled, "Call me crazy, but Windows 11 could run on Linux". See here:-

https://www.computerworld.com/article/1658541/call-me-crazy-but-windows-11-could-run-on-linux.html

As he rightly put it at the time, "Desktop Windows has had so many problems, desperate measures may be needed." While I think that might be a bit hyperbolic, it's becoming increasingly clear that Linux is as important to Microsoft's future success as their own code, mainly because they are never going to win over enterprise clients. The massively scaled platforms used by e.g. Amazon and Google all run on Linux variants... and run well.

Linux is capable of running on lower-power hardware, because it's possible to run it in headless mode, without all the expense of the GUI. Which means it's faster and more cost-effective.

I think that this latest move by Microsoft is entirely unsurprising. Maybe not the full, "If you can't beat 'em, join 'em" acceptance, but certainly the acknowledgement that if Microsoft want to remain viable in the enterprise space - and avoid going the way of Apple - then they need to become a lot more "Linux-friendly."

My suspicion is that SVN was probably right, just maybe a decade or so ahead of his time.

[jake]

Re: Imitation is the Sincerest form of Flattery

ESR was babbling about Windows eventually becoming an emulation layer on Linux in roughly the same timeframe. ElReg covered it, if you care enough to go looking for details.

Other people were discussing it, some seriously, others TIC, over the previous decades ... I remember one comment on USENET in roughly 1995 that suggested (paraphrased) ":Let's just concentrate on getting into the year 2000 in one piece first" ... They were talking about Wine.

Back in '92 (at COMDEX), Sun Microsystems introduced WABIWabi, their Windows Application Binary Interface for running Win 3.x programs on their UNIX workstations. It worked, kinda. Seems to me it shipped on Solaris 2.0, at no extra charge to the purchaser. Later versions of Wabi didnlt require it, but allowed installing Win3.1 _{as an application}, which you then installed Windows programs on "natively". For somewhat obvious reasons, what little interest there was waned after this move.

Back to today ... I'm already running my favorite distribution of Linux on a modern Linux kernel. Why would I need/want to downgrade to Windows software of any kind?

[Bebu sa Ware]

"Let's just concentrate on getting into the year 2000 in one piece first"

I imagine not a few are currently thinking "Let's just concentrate on getting into the year 2028 in one piece first"

[An_Old_Dog]

"Why would I need/want to downgrade to Windows software of any kind?"

Because there are many useful, niche programs written for MS Windows which which have no *nix equivalents, and which will never be ported to *nix, because:

* The original authors do not know how to port them to *nix; and/or,

* The original developers have no interest in porting them to *nix.

Many of these programs do not have the source code available, so you can not even port them yourself.

[Fruit and Nutcase]

Simple!

Copilot, create a *nix equivalent of the dooh-dah-thingy Windows utility

[that one in the corner]

Re: Simple!

> Copilot, create a *nix equivalent of the dooh-dah-thingy Windows utility

"Please insert credit card" - slurp - "Hungry!"

"Insert credit card" - slurp - trickle of output tokens - "HUNGRY!"

"CREDIT CARD" - slurp - tokens spew out then stop - "HUNGRY NOW!"

[that one in the corner]

Re: "Why would I need/want to downgrade to Windows software of any kind?"

> Because there are many useful, niche programs written for MS Windows which which have no *nix equivalents, and which will never be ported to *nix, because...

Have a little WINE.

[Roland6]

Re: "Why would I need/want to downgrade to Windows software of any kind?"

What you want me to CrossOver to the dark side?

[Eric 9001]

Re: "Why would I need/want to downgrade to Windows software of any kind?"

In reality, most of that is functionally garbage programs, that should not be run for practical reasons alone, as there are functionally superior free software replacements already available, that you should be using instead.

More free software exists than proprietary software, even though there's the tendency for proprietary software to include what previously was free software, to implement most of the functionality.

If you feel you can't do without a program that runs on windows, you should for your own sake, break the digital handcuffs by looking for a free replacement, or get it developed.

Name a proprietary program and I will see if there is a free replacement for you.

[The Dark Side Of The Mind (TDSOTM)]

Re: "Why would I need/want to downgrade to Windows software of any kind?"

Schlumberger's Petrel suite(s)... AFAIK they integrated a huge amount of flows, processes and knowledge (scientific, organizational, operational) in a unified interface. That interface was designed specifically for the Windows GUI environment.

Gemini told me that some had limited success using CrossOver Linux, but this is not open-source either.

Anyway, one can look at what SLB says about this: https://www.software.slb.com/-/media/software-media-items/software/documents/external/product-sheets/petrel-20-years-book.pdf

[Eric 9001]

Re: "Why would I need/want to downgrade to Windows software of any kind?"

That is a harmful software collection that should not exist - the world would be better off without even more oil and gas extraction to accelerate global heating harder.

What the world needs is not a free software replacement of that software collection (as the program would be harmful even if it was released as free software) - rather what the world needs is for every copy of such software collection to be deleted.

[The Dark Side Of The Mind (TDSOTM)]

Re: "Why would I need/want to downgrade to Windows software of any kind?"

Well... a rock can be used in many ways, including the way that implies hitting your fellow primate in the brainbox. An axe has similar uses... ask a forest how it sees it. A knife...

Exploration, reservoir characterization and all the management implied by those (and many other activities that I'm not familiar with) needed an industry accepted tool, with common processes, lingo and philosophy. It started with oil and gas industry because they had (and still have) more money than most others, but it had also uses in carbon reduction technologies (namely CC[U]S ~ Carbon Capture [Utilization] and Storage) for identifying the best candidates among known and newly found reservoirs, deep [saline] aquifers and whatnot.

Truth be told, there are many FOSS tools that can do the same job, but with significant amount of work and fuss from the part of the scientists and technicians (manglement intentionally left out of this picture, as I suspect they were responsible for a lot of this suite's DNA).

End point: a tool is just a tool - the users are responsible with how they use it and for what purpose.

[An_Old_Dog]

Re: "Why would I need/want to downgrade to Windows software of any kind?"

@ Eric 9001:

It's not proprietary Windows programs I'm running on my Linux box. They all are freeware, and they are niche programs, which typically scratched one person's itch to write, and which no one else cares enough about to rewrite for *nix.

[Eric 9001]

Re: "Why would I need/want to downgrade to Windows software of any kind?"

"freeware" is almost always used to refer to proprietary software that is merely available gratis.

As the user doesn't get the source code and is also not allowed to modify it and/or redistribute it and it typically comes with no license (or a proprietary license), it is proprietary software.

Niche programs tend to be not that difficult to replace with a bit of GNU bash scripting, or have functionality that is already implemented in existing free software.

If nobody, not even you can be bothered to rewrite it, clearly that task is not worth bothering to do and therefore the solution is to cease doing that task and cleanse the world of a bit of filth, by deleting all known copies of such proprietary software - then the world is a better place.

*nix is a harmful loose pattern match, as that pattern match conflates a bunch of completely different things, such as; Unix, GNU's Not Unix, GNU/Linux, Linux & minix.

After all, the only relevant points of comparison between Linux and Unix, is how Linux uses a monolitihic design like Unix kernel's (SYSCALLs and drivers etc are totally different) and Unix kernel's and Linux are proprietary software.

[Anonymous Coward]

Re: "Why would I need/want to downgrade to Windows software of any kind?"

Hi, AC here, because I don't want to give away who I work for, and I think I've mentioned it in the past.

We develop exclusively Linux software on exclusively Linux platforms in the automotive space. We work with some big names to put some of our software into their vehicle computer systems.

The only way to do this is with Windows. Yeah. It's dumb. We hate it. But it's what it is. The last step in the "upload this binary onto the vehicle computer" is via a proprietary windows utility supplied by the vehicle manufacturer. There is no free replacement for that, and I very much doubt there ever will be unless someone can convince some multi-billion dollar companies that they should change their processes upstream.

[gsej0]

Re: "Why would I need/want to downgrade to Windows software of any kind?"

Phonak Target

[Zonker Zoggs]

Re: Imitation is the Sincerest form of Flattery

I agree with you, but MS being Linux friendly is not a new thing.

Steve Ballmer frothing about Linux is a distant memory.

Today you can build, and deploy .NET apps on Linux.

I would be interested to know the modern split between .NET apps deployed to Windows v Linux in Azure, but would be surprised if its not skewed to Linux (perhaps heavily)

You can run SQL Server on Linux (I'm doing that locally)

This announcement is more a quality of life enhancement than some big news. Microsoft embraced Linux a long time ago.

[Sproggit]

Re: Imitation is the Sincerest form of Flattery

"Today you can build, and deploy .NET apps on Linux."

Indeed - I run a Primary/Secondary pair of Technitium DNS at home [on multi-homed Pi4Bs] for my home network. That project is developed on Windows and ported to Linux using the .Net runtime.

Good project with a very responsive team of developers... but I do notice some inconsistencies in the edge cases - and they turn out to all be down to .Net failing to properly implement / call down to the Linux networking stack. For example, Technitium has an admin parameter that allows users to specify which adapter or which address should be used for communication with fellow Zone Servers. But on my Pi setup it doesn't matter what configuration you use, the code will ignore it and use the primary network adapter for the host.

Very much an edge case, but the sort of thing that would make me wary of deploying .Net on Linux to anywhere sensitive - like a DMZ. Probably fine for your internal network segments though.

[drankinatty]

Re: Imitation is the Sincerest form of Flattery

It is indeed, and good for MS for choosing the best tools for the job. Nobody goes looking around in windows when then need the Swiss Army Knives of text-processing slice and dice a project. Add sed and awk to the mix and you are covered.

Personally, I'd still prefer firing up a MSys2 shell in windows and have all the native Linux tools at my fingertips. Only drawback is reaching in/out of the MSys2 (MinGW) environment to the rest of the windows filesystem -- but, that's not any less cumbersome from the the dos (command) prompt or powershell........

[Jamie Jones]

Re: Imitation is the Sincerest form of Flattery

Many have been saying that (or similar) for far longer than that.

I clearly remember around the time that consumer windows switched to the NT kernel saying that they should have made the GUI and windows compatibility an interface on top of FreeBSD.

Which is what Apple more or less did with MacOSX a few years later.

It has always been a pretty obvious solution - I'm sure MS had thought of it too, but of course, pride, "not invented here", culture issues, management resistance etc. made it a non-starter.

[isdnip]

Re: Imitation is the Sincerest form of Flattery

But why? The NT kernel is the strongest point in Windows. It's essentially a reimplementation of VMS; David N Cutler did "v1" of both. Windows went awry when the GDI was moved into kernel space, in the 4.0 time frame, in order to run a little faster, and it lost more reliability when the HAL went away and all the drivers moved into the kernel, again for speed. But those were product management decisions that abused the kernel, not underlying faults. Part of what has hurt Windows over the years is a serious lack of quality assurance and control; MS could do low quality work on top of a Linux kernel too.

[Jamie Jones]

Re: Imitation is the Sincerest form of Flattery

Yeah, that's a fair point. But we don't mean just the kernel, but the whole operating system.

I actually really liked the UI of windows 95. - The idea would to be to make windows just a GUI. Of course, it would be a bit more complicated than that, but that's the gist, as I said, more or less what OSX does - of course, the OSX OS is highly modified with their mach and other systems, but you can still drop down to a shell and see a Unix system underneath.

And yeah, MS could screw up their apps, but at least their OS (not just the kernel) would be ok (well, until they bastardise it like they did to the original NT kernel!)

I actually used to use NT, voluntarily ! If I didn't need to do unixy things on the machine itself, and just use it as a "power consumer" it was great! Sure there were some bugs and lack of drivers, but that could have been fixed without morphing into the dreaded XP!

[JulieM]

Re: Imitation is the Sincerest form of Flattery

VAX/VMS had full version control baked right into its file system. Every file was given a version number, allocated sequentially, and "overwriting" a file created a whole new version.

Literally everyone (except VAX users .....) has, at some point in their life, mistakenly overwritten a wanted file with an injudicious "save". If Microsoft had included the file versioning functionality of VAX/VMS in Windows NT, they would have had the killer feature.

[Jou (Mxyzptlk)]

Re: Imitation is the Sincerest form of Flattery

> VAX/VMS had full version control baked right into its file system.

Take a look how busy filesystems are today. To avoid IO-Disk trashing for everything all applications must be aware of sich a feature. Literally all. And then be very careful to activate it where needed, not just blind global. There is a reason why that went away, 'cause it looks nice on paper, but is performance hell in reality. For a single user OS though, I agree here, and it could at least be an "activate that feature" in NTFS - but I would bet it scrapped due to lack of demand, and (since Server 2003) snapshots are good enough for > 99%.

[dmesg]

Re: Imitation is the Sincerest form of Flattery

Back in the 90s or so, a fellow grad student was an X Windows maven and had been so for a decade or two. He told me of interviewing at Microsoft back in the DOS-only days, when they knew they wanted a GUI for their OS and apps and were looking into possible ways to do it. They asked a lot of technical feasibility questions. Yeah, that was back in the day when MS could get free consulting by dressing it up as a job interview. Too bad, he said, that they decided to go with a home-brew solution.

[Eric 9001]

Re: Imitation is the Sincerest form of Flattery

microsoft will never use Linux as the kernel for windows.

The only reason a lot of used, use windows anymore is because of their handcuff-in.

For windows, there's a lot of legacy cruft software that depends on bugs and race conditions in the NT kernel, as well as digitally handcuffing software that uses rootkit modules in the NT kernel.

Replace the NT kernel with Linux and those programs would cease to run and therefor the would no longer be any reason to run windows - running GNU/Linux would be more convenient.

If microsoft was to turn windows into a bad GNU/Linux distro, then only fools would use it, over decent GNU/Linux distros.

As for Azure, while it does run mostly GNU/Linux virtual machines (despite the insanity of paying microsoft a fortune to run GNU/Linux for you, over running it on your own computers for far cheaper), the Azure hypervisor OS is in fact windows (which of course causes reliability to be pretty bad, even though windows mostly sits there, doing the limited task of allowing the hypervisor hardware to run the VM's).

Amazon and google run GNU/Linux, with minimal or no changes to Linux.

microsoft's goal is to turn computers into thin clients that are running windows, that remote into virtual machines that are running windows (GNU/Linux will manage the internet routing and also will be available in a carefully controlled additional virtual machine, but otherwise won't be used).

There is also then be the additional goal of implementing remote attestation, to ensure that only windows (and as a compromise, other approved restricted proprietary OS's, like iOS, macos and Android), can access governmental and banking website for "security" (the whole idea is to make using a non-backdoored and non-surveilled OS such as GNU/Linux-libre, to access governmental or banking websites (sorry, "web apps"), a cryptographically impossible problem, rather than the current technological problem of needing to support TLS, HTTP and 50MiB of JS).

[Anonymous Coward]

Does "user" == "agent"?

"... the user must suss out which identical command takes precedence..."

But why use Windows? Besides the hard core Visual C++ users that are retiring, which developers are they for? Realistically and not sarcastically ransomware and other scammers will probably benefit the most from these tools.

Ironically this tool migration is ultimately for reusable code written by humans, not AI. They're not sneaking this past people and this is a bad look for AI and Microsoft doesn't need anymore bad looks this decade.

Does a AI "agent" qualify as a "user"? If you're scripting an agent do you have the ability to hard code the interpreting environment? I bet you don't and I'd bet that someone is going to have a Powershell script do funny things with important things.

[Alex 72]

But why use Windows?

Because some Developers like to get paid. Often they are paid by companies deeply invested in Active Directory, Entra ID, Microsoft SQL Server, or a firm who uses the windows desktop clients widely. It may not be the cheapest, fastest, or most secure way to build in a fully greenfield environment. Even in greenfield projects, organisations rarely have greenfield infrastructure and developers work with what they have if they want to get paid, which it seems many do, sone kind of powerful need to eat or something.

[Roland6]

Re: But why use Windows?

>” developers work with what they have if they want to get paid”

They also tend to work with stuff which they would like to know more about and so improve their pay.

A couple of years back migrated(*) a system away from AWS to a simple LAMP server, not only did this save the AWS costs, it also saved the costs of running Microsoft software on top of AWS…

From conversations with the developers/contractors, it seemed they could see the value of adding AWS development experience to their existing MS (on-prem) experience and so used this project as their learning vehicle…

(*) because of the use of Windows and AWS API’s this was more of total rewrite than a simpler port. But the porting costs were recovered within the first year of operation on the new platform…

[that one in the corner]

Re: But why use Windows?

I worked a bit on an embedded product that was all in C++ except for one module that was written in (not particularly good Python). So the entire Python interpreter was pulled into the project, plus a layer to map the C++ objects into Python and back again. The argument from the contractors seemed to be that this meant the system was easy to configure - all our support engineers had to do was learn all the ins and outs of the Python-wrapped classes. Oh, and learn to program in Python. Actually, getting them to learn programming in the first place might be useful.

Once the external contractors who did all this turned the code over to their client (us), for some strange reason that Python module was replaced with C++, the Python subsystem was excised (saving a good deal of space in RAM and flash - did I mention, embedded?) and a nice simple name/value config parser was dropped in.

Funnily enough, this was a few years ago, round about the time a lot of fuss was being made that Python was "the language you ought to know", it was rising up the usage charts on Github...

Occam's razor, the sanest reason that Python ever appeared in this application was because the contractors decided they could get paid to learn how to add it into a C++ program (and be paid to write My First Python script from the looks of it). Otherwise...

[Anonymous Coward]

Re: But why use Windows?

"From conversations with the developers/contractors, it seemed they could see the value of adding AWS development experience to their existing MS (on-prem) experience and so used this project as their learning vehicle…"

That's what we (unfortunately) call Resume/CV-driven development.

[DS999]

Re: Does "user" == "agent"?

Everyone is bringing back CLIs because that's far less expensive token-wise for AIs to interface with than GUIs. So I think it is 100% certain Microsoft did this for AI, not for humans.

[captain veg]

DOS era?

'They will no longer need to remember the standard “ls” command for listing the contents doesn’t work in Windows, and that they have to type the DOS-era “dir” command instead.'

I'm pretty sure that dir was snaffled from CP/M, which got it from TOPS-10, predating Unix.

It's pretty ironic that it's still in Windows when they've been trying for so long to re-educate us all that they are /folders/, not directories.

-A.

[Anonymous Coward]

Re: DOS era?

In the physical world a directory would be represented by a file cabinet.

In the physical world a folder would be represented by ... a folder.

Do you put multiple file cabinets in a folder?

Do you put multiple folders in a file cabinet?

There is evidence that before the existence of a directory|folder|thing-to-put-things-in that only the word "directory" existed for analog storage. There is no evidence that the word "folder" existed before the existence of putting thing-to-put-things-in for analog or digital storage.

[jake]

Re: DOS era?

I was using library in the 1960s ... as in "I'm sure that's in my tape library, somewhere."

Which became "Tape archive". Which by the late 1970s became the "tar" command, still in use by real sysadmins the world over.

[Fruit and Nutcase]

BJ/AJ

In El-Reg forums, there is...

BJ - Before Jake...

AJ - After Jake...

...started fiddling with computers

icon: I was going to put a thumps up, but I think Jake would prefer a beer

[that one in the corner]

Re: DOS era?

> In the physical world a directory would be represented by a

Directory.

Like, you know, a University directory, a book with a chapter full of the names of staff, directing you to the department they belong to. And a chapter with a list of all departments, directing you to a page which describes the department, including the building(s) they are housed in. And a chapter with a list of all the buildings, directing you to the square on the map where you find the building represented.

Or a company directory, with a chapter listing all the members of staff, directing you to which desk they sit at.

You get the idea? A "directory" is something that directs you to where (or how) to find something (or someone) if you know what the name is.

Or, and bear with me on this, you may find this a bit complicated, a telephone directory, aka the Phone Book: a big fat book full of the names of people in a city/region, in alphabetical order, with their phone numbers. Or the Yellow Pages directory: a big fat book full of the names of companies in a city/region, in alphabetical order, with their phone numbers. Or the towns and villages directory: a big (but not very fat) book of the names of all the (small) towns and villages in alphabetical order, with the name of the city or region whose phone book/Yellow Pages included that town or village.

Gosh, you could almost say that those directories are "nested" or perhaps "multi-level".

Let's go back to the University directory: the page for a department also lists the number for the departmental secretary's phone. If you can remember the secretary's name, you can look them up in the Phone Book for the town/city the University is in OR if you only remember they are the Maths Dept. secretary you can look them up in the University directory, following the path described above.

Tada! You have two distinct and separate sets of directories, maintained by two completely different groups (the GPO for all the national Phone Books, the University for their directory) AND THEY BOTH LEAD YOU TO THE SAME THING, they both end with a pointer/address/unique identifier/phone number which, if you invoke/dereference/dial will get to access to all the data contained within (via a nice conversation with the secretary, maybe over a cup of coffee after a nice dinner out, followed by a show and a moonlit walk along the river).

You might be winding yourself up to say that, in the digital world, you would do all that using a database, not directories. Tell you what, you go off and read up on how file systems work, the big complicated ones we use on terabyte drives, the sorts of data structures they use to store the directories. Then try looking up those same data structures, but this time in the Boys Big Book Of Databases. Guess what you'll discover!

> There is evidence that before the existence of a directory|folder|thing-to-put-things-in that only the word "directory" existed for analog storage.

Yer wot?

Maybe you'd better *stop* taking the dried-frog pills; I don't think you are really Bursar-level material.

[Anonymous Coward]

Re: DOS era?

You're too excitable for your own good.

You wrote alot and still only gave 1 example: a phone book.

So a phone book can be put inside another phone book? Groovy.

P.S. I'm disappointed that no one used the counter argument of punch card folders... so it goes.

[Jamie Jones]

Re: DOS era?

Doubling down? Really?

[LionelB]

Re: DOS era?

You used to put folders in other folders? I always found they'd split down one side when you did that, or get wedged in, and you couldn't read the labels, and you'd get a proper bollocking from Mark in Accounts.

[Jamie Jones]

Re: DOS era?

Oh, that was you?

Was it also you that put folders in folders in folders? That straw really pissed off Mark in Accounts even more.

folders in folders in folders.jpg

[that one in the corner]

Re: DOS era?

> You wrote alot and still only gave 1 example: a phone book

FOUR examples - a towns & villages directory, the phone book, a company directory and a university directory.

That should have still left you with a thumb free on your counting hand.

> So a phone book can be put inside another phone book? Groovy.

Inside? No, one references the other... and references are the life blood of data processing... hang on...

You didn't actually understand any of it at all, did you? You don't have the faintest clue about data, why we organise it and shove it into files and directories and databases and...

There I am, carefully explaining each and every step, and the whole thing just goes - whoosh, right over your head.

The discussions in this forum page about what Unix "ln" does must have you curling up and mewling in despair.

[steelpillow]

Re: DOS era?

Back in the day we stored digital stuff on tapes, be they punched or magnetic, or even on punched cards, all of which we kept in a library. When magnetic discs came along, somebody got the bright idea of putting more than one set of stuff on it and calling them files. They soon got so many files they organised them into directories.

Then pretty GUIs came along, and the filing cabinets vs. folders war started. The command-line world still called them directories.

Nowadays we spin up a "disc" by dropping a .iso file into a directory or folder on a virtual "drive" that lives on a virtual machine in "the cloud".

[Peter Gathercole]

Re: DOS era?

I'm pretty certain that some OS's that did not have a hierarchical structure used to have files (were they called files?) indexed in a 'catalogue' rather than a directory.

But I used UNIX from 1978, very early in my computing life, so files/directories/filesystems were natural to me, and I used the term for things that may not have been appropriate, like FILES-11 (version 1 on RSX-11) filesystems.

I'm trying to think of some of the terminology used by more obscure systems (things like PrimeOS, Vulcan/VOS, and I've even forgotten that for MTS), and also for more mainstream ones like George, VM/CMS (files/minidisks maybe) that I had some exposure to. I'm sure that they each had their own way of indexing files on disk, but I just can't remember them all!.

Even BBC/DFS had named directories and files on floppy. IIRC, CP/M had user regions (not that anybody used them).

Back on the topic of the article, I've been using the tools that get installed with Git (not sure which version, I'm not the admin) on the Windows systems I still have to use. Full bash and most other coreutils toolset, with vi for an editor. A bit slow sometimes, and interaction with files and shares can seem s bit slow and clunky sometimes, but installed, available and usable.

[captain veg]

Re: DOS era?

> I'm pretty certain that some OS's that did not have a hierarchical structure used to have files (were they called files?) indexed in a 'catalogue' rather than a directory.

In Pick (which is only slightly hierarchical) files are accessed through a "dictionary"/

-A.

[PhilBuk]

Re: DOS era?

Try IBM System 38 (and, I believe, AS/400) - the file system was a database and everything was accessed by a database query.

[Jou (Mxyzptlk)]

Re: DOS era?

Like the thing MS tried with WinFS, but failed so miserably?

[jn5250]

System/38 etc

Well, not like MS. I do not think AS/400 (iSeries, IBMi...) has failed on the database thingy. It works like a charm - and not requiring to add additional charged software.

[Jimjam3]

Re: DOS era?

Your assumption about the words Folders and Directories is made up. Much like a lot of AI content.

Back in the 1970s I remember using both those words for things which had inside them, sheets of paper information.

Furthermore I can also recall putting a phone Directory into a folder in a Filling cabinet.

We truly are heading towards a future of nitwits.

[Bebu sa Ware]

We truly are heading towards a future of nitwits.

Heading towards… but very likely not arriving — there are currently too many rather powerful destructive nitwits whose existence is a cogent argument for effective contraception or indeed infanticide.

[Phil O'Sophical]

Re: DOS era?

And doesn't Windows still have.cab (cabinet) files?

[GBE]

Re: DOS era?

I'm pretty sure that dir was snaffled from CP/M, which got it from TOPS-10, predating Unix.

The story I heard was that Gary Kildall based a lot of that stuff on RSX11-M and the DCL shell — but that's a distinction without a difference due to the way things were shared between RSTS, RSX11, TOPS, VAX/VMS, etc.

[jake]

Re: DOS era?

"due to the way things were shared between RSTS, RSX11, TOPS, VAX/VMS, etc."

In that era, everybody was sharing with everybody else. We were inventing an entire industry that had never existed before, and there were no real rules. Not legal ones, anyway. We had an AUP (of sorts) for the ARPANET in the early 1970s, although I could make a case for there being one as soon as the first bits were sent and received between two University campuses in 1969 ("Proper use of University Equipment" and "Sharing of Research between Universities" or similar went back decades before this). That's why the frustrated Bill Gates wrote his laughable "Letter to Hobbyists" in 1976. Little did we know what the then fledgling Internet would become, and how it would aid that sharing.

[Peter Gathercole]

Re: DOS era?

I would say it's a bit more like RT-11.

[isdnip]

Re: DOS era?

Yes, as I recall Kildall based CP/M on RT-11. And by then DIR was established in the DEC world. But old-time RSX users might remember PIP, and not miss it either.

[Peter Gathercole]

Re: DOS era?

DIR appeared on RSX-11M at or around version 4, when a limited version of DCL was added. I started using RSX-11M at version 3.2, which was MCR only. Definitely had to use PIP on that.

RSX-11 naming was confusing. -11A, -11B, -11C, -11D, -11M -11M-Plus, -11S, Micro/RSX, IAS etc. All with different features, different version numbers and features, and some were only available on certain models of PDP-11.

It evolved over the years as the PDP-11 architecture evolved, eventually culminating in -11M-Plus for systems with separate I&D, and -11M for systems without it (plus some specialised versions for embedded and personal systems).

Pretty much every model of PDP-11 after the 11/34a was a separate I&D system, but many older PDP-11s had very long lives, prolonging RSX-11M.

[HXO]

Re: DOS era?

> /folders/, not directories

Over in .NET land it is directory, fex System.IO.DirectoryInfo. But me using folder in naming.

Also, I could use a stable rsync...

www.osnews.com/story/145198/rsync-opens-the-slopgates-regressions-and-bugs-ensue/

[find users who cut cat tail]

Re: DOS era?

Folders hold things inside, directories list or reference things.

We have hardlinks, meaning a single file can be shown in multiple places with no single primary location ‘holding it’. So these places are lists, not containers. (It is also how filesystems work internally, otherwise mv would often have to do a lot more work.)

[Michael Strorm]

Nice, but...

...isn't this just a more integrated verison of what the venerable Cygwin has already been doing for decades?

[David 132]

Re: Nice, but...

To be fair, the article makes that point:

"One could run Grep before on Windows through third-party packages such as Cygwin, though Coreutils has the speed of native functionality, thanks to its implementation in Rust."

[Persona]

Re: Nice, but...

I remember using it maybe 25 years ago. It was pretty good even then. It was a lot more than grep: it even had "awk", and I could do a lot with awk back then.

Now all I remember about using awk is the classic error message: "awk: bailing out near line 1"

[Paul Crawford]

Re: Nice, but...

I also used cygwin back in the day but found the UNIX principle of chaining multiple commands together was really slow on Windows, something to do with the cost of starting process I guess, so quickly dropped that and stuck with native Linux operations.

Also a few commands did not exist, or work as expected, on Windows so it was not always a simple way to do the same on both.

[Doctor Syntax]

Re: Nice, but...

The implication there seems to be that Cygwin isn't written in a compiled language. Really?

[David 132]

Re: Nice, but...

Yeah, I was a little puzzled by that, too. I think that as Rust is the language du jour the inference we're expected to draw is that anything written in it is automatically New and Hot and very very Now, whereas anything written in boring old Boomer C++ "might as well be written in QBASIC, grandad".

[David 132]

Re: Nice, but...

Ah, a downvoter who doesn't grok sarcasm, I see. Or is a fully paid-up member of the Cult of Rust. How sweet.

[Persona]

Re: Nice, but...

Was there ever a version of awk written in that new and fashionable C++? I was using awk back in 1987 when my AT&T C++ complier spat out "C" that I then compiled using the native C complier.

[ICL1900-G3]

Re: Nice, but...

Langage du jour svp

[Dan 55]

Re: Nice, but...

What? They both end up calling the Win32 API, you call C's fopen in Cygwin and it's converted by cygwin1.dll to Win32's CreateFile, you call File::open in Rust and it's converted by mscvrt.dll to... Win32's CreateFile.

[tiggity]

Re: Nice, but...

Cygwin has always been one of the first "extras"* I install on a Windows box

* I always install a variety of useful "utilities" on Windows to make life far easier in future usage of that box.

[TonyHoyle]

Re: Nice, but...

More likely gnuwin32 which is a native port (and already in winget).

The MS coreutils is probably OK but no bash means I'll probably stick to the gnuwin32 versions for scripting.

[NetMage]

Re: Nice, but...

gnuwin32 has been abandoned for 15 years?

If you want something recent, this is the best thing available.

[that one in the corner]

Re: Nice, but...

> gnuwin32 has been abandoned for 15 years?

And yet, somehow, when I try them, all the commands still happily work. Weird that.

[Sandtitz]

Re: Nice, but...

Some of those utils have severe vulnerabilities, and not just the outdated openssl.

[Doctor Syntax]

Re: Nice, but...

It sounds more like Busybox.

[jake]

Re: Nice, but...

Yes, as a single binary. I wonder why they went that route on Windows. It makes sense for Busybox, given it's targeted environment, but Windows? Hardly.

[that one in the corner]

Re: Nice, but...

Possibly because it is the easiest way to get all of those commands with a licence that Microsoft is happy to use (and in the funky language that all the cool kids are using these days)?

The single-binary is then just an oddball side-effect. And somewhere inside Microsoft QA there is an unhappy person who can't figure out why installing so many programs doesn't require over a gigabyte of disk space ("but this goes against company policy!").

[druck]

Re: Nice, but...

Microsoft QA - what's that?

[Paul Herber]

Re: Nice, but...

QA = Questions and Answers.

So many, so little time, so little point, so what.

[Brewster's Angle Grinder]

Re: Nice, but...

I've got the mingw versions in my PATH, but they do sometimes struggle with DOS file paths. I must play with these, see how they go.

[Jou (Mxyzptlk)]

Can it output objects?

grep and the like rely on pipes, which are inherently slow. The output is text/binary, i.e. whatever you input. ls output is text.

So I am asking the most evil question: Can this grep and ls output an object, and what methods does this object have? While some commands are practical, once you got used that you don't have to parse text output and get a structured object, which in turn allows you to modify the "creation date" and "last write date" of a file as example, you start to like the object orientation which came with Win32 subsystem.

[BinkyTheMagicPaperclip]

Re: Can it output objects?

The article links to the project, which then links to the list of commands and what they can do, but the spoiler is : no, at least not based on the documentation.

If you're going to fiddle with structured objects, you're better off using PowerShell, which is explicitly designed to work in that way.

[Jou (Mxyzptlk)]

Re: Can it output objects?

Yep, you got the point. But as soon as I mention the keyword shell you mentioned a storm is triggered... I mix the shell you mentioned sometimes with an actual unix-win32 command, not its pseudo-alias, for lazyness. If you add .exe to the actualy command is executed in the shell you mentioned executed instead of the alias. But the older shell available on that OS I cannot mention still has the fastest search with "dir c:\*filespec* /b /s /a". Was better in Window 2000 search, bevor indexing was forced upon us.

[BinkyTheMagicPaperclip]

Re: Can it output objects?

Yeah.. I'm aware of the issues of :

expecting cmd to be the same as Powershell, and then finding out that e.g 'cd progra*' does not work in PowerShell

running Unix utilities ported directly to Windows, and having to deal with back/forward slash confusion

running both Cygwin and Windows programs within Cygwin's shell, and then having to integrate with the different filesystem layout

These utilities may remove some of that confusion

[jake]

Re: Can it output objects?

If you have a need for that kind of capability in a Windows-ish environment (why? Not taking the mick, genuinely curious), you'd probably be better off specing the hardware for a new OS/2 (ArcaOS) box and doing it in Rexx.

Yes, it's a commercial product and costs money. But its TCO is much less than Windows.

Be careful, it can become addictive.

https://www.arcanoae.com/arcaos/

_{Not affiliated, don't own stock, just a long-term satisfied customer, yadda ...}

[Flocke Kroes]

Re: pipe speed

I tried piping through cat multiple times. Each extra pipe through cat added about 13 seconds of CPU time on a 5.5GB file. Over 400MB/s - on a Raspberry Pi 4. Real world time was longer because the data came from a spinning disk. In other words a cheap CPU doing multiple pipes can keep up with a spinning disk. For plenty of real world tasks pipes are fast enough.

[Peter Gathercole]

Re: pipe speed

The overhead depends on the implementation of pipes in the OS. With early versions of UNIX, pipes used to go through a filesystem, like an unnamed FIFO. As more memory became available in systems, and the address space for the kernel increased, it became more normal to just link pipes together with memory resident I/O buffers.

I suspect that modern implementations on Linux may be able to use shared memory segments to hold the data in the pipe, although I've never looked.

Cat is not, as far as I'm aware, multi-threaded, so each process will be a read followed by a write, with little overlapped I/O. This means there will be a measurable amount of system time associated with each of the read and write, together with some copying time into and out of the buffer (cat is not just a data copying tool, it can do other things), so it is probably not the overhead of the pipe that is adding to the overall elapsed time. In addition, if you go over four processes, a Raspberry Pi 4 will probable also have to context switch, although this could happen during the I/O. But as you say, this is dwarfed by the time for disk I/O.

[Paul Crawford]

Re: Can it output objects?

grep and the like rely on pipes, which are inherently slow.

Not they are not, but Windows seems to have a big overhead of creating them and/or the processes running between them so that is a feature of doing the Linux way on Windows (e.g. cygwin in the past). If you really want to use the object approach for Windows then this is not for you.

[LionelB]

Re: Can it output objects?

Um, yes, grep and ls are text utilities – that's what they are for. If you have other, non-text requirements, e.g., to manipulate "objects" (whatever those might be) I'm sure you can find software for that.

And they don't "rely" on pipes. Like any Linux program that read/writes from/to stdin/stdout, their input/output may be piped. If you want.

And no, pipes are not "inherently slow".

[BinkyTheMagicPaperclip]

Fantastic!

If I can get work to have this installed in a build by default, or at least in the company software centre, this means I don't have to run the gauntlet of trying to explain 'first install Cygwin', or rewriting what can be done easily with existing Unix utilities using Powershell.

It'd be nice to have diff as well, but comm and uniq will do a lot of what I'd want. There's no worry about licenses or provenance if Microsoft are maintaining this too.

[Doctor Syntax]

Re: Fantastic!

"There's no worry about licenses or provenance if Microsoft are maintaining this too."

Don't you think it might introduce a whole lot of other stuff to worry about in that case?

[BinkyTheMagicPaperclip]

Re: Fantastic!

Not particularly. Most of the utilities are pretty mature, and I don't see them changing much.

I mean, that's assuming the Rust versions are actually any good, and haven't introduced new bugs - which undoubtedly they have, in the corporate driven rush away from C.

[Eric 9001]

Re: Fantastic!

uutils has still not implemented much of the functionality of GNU coreutils and an audit by a single developer uncovered 113 issues, 44 of which were assigned a CVE; https://seclists.org/oss-sec/2026/q2/332

[Dan 55]

Re: Fantastic!

But you can't run bash scripts because it's not bash, it's still Cmd or Powershell. It's only useful for interactively entering commands.

[BinkyTheMagicPaperclip]

Re: Fantastic!

For the sort of tasks carried out at work, it's more than adequate.

If it needs the sophistication of a bash script, I would *much* rather use PowerShell. It's very powerful; I just wish Microsoft didn't try to hide it as a scripting language, rather than a way to drive the .NET runtime.

I've also been fiddling with sh scripting recently (not under Windows) and it is an incredible fussy chore. That's not surprising given the age of sh, but PowerShell really is several orders of magnitude better.

[Eric 9001]

Re: Fantastic!

Were you trying bash scripting, or sh scripting?

sh scripting is pretty bad, but even that is far superior to the pile of flaming garbage that is powers hell.

It's very easy and pleasant to write a good bash script, but it is hellish to write a powers hell script (capitals in commands named in a way that you can't remember them is a terrible, terrible thing).

[BinkyTheMagicPaperclip]

Re: Fantastic!

sh - which is itself an issue because pretty much every online resource refers to bash.

It really, really, isn't superior to PowerShell. In sh whitespace is very important, the syntax isn't well documented, and the errors are opaque. I do find PowerShell irritating at times, but it's far easier to find resources, documentation, and examples.

With PowerShell, because it's .NET, in a few lines of code you can pull in an external DLL (SQLite has one), construct an in memory database, easily work with a text or XML file that includes Unicode, manipulate it in that database, and write it out.

[BinkyTheMagicPaperclip]

Re: Fantastic!

I probably shouldn't repeatedly comment, but I've been doing further fiddling with sh and it is an utter pain.

sh scripts by themselves are sort of tolerable

sh scripts run as a list using the -c command are a bit painful as one set of escapes are needed to pass various characters

sh scripts passed as a list through make are even worse because there's a set of escapes used to pass characters through sh -c, and another set through make

Yes, there are reasons for this. Yes, the automatic expansion of environment variables by the shell can be useful, but they also confuse things.

Doing this mostly as an exercise, and thoroughly understanding why many people choose to use awk instead.

Windows does this differently, is arguably not as flexible, but also tends to be easier to get your head around.

[jake]

Re: Fantastic!

"and it is an utter pain."

I'm not surprised. While sh CAN do what you are trying to do (probably, I'm reading between the lines), there are better tools for the job. Try perl, for example.

Horses for courses and all that.

_{Are you really using sh? Try file /bin/sh ...}

[Maximus Decimus Meridius]

All very well

But does it support cowsay?

[jake]

Re: All very well

More importantly, does it support sdate?

_{Today is September 4242, 1993.}

[that one in the corner]

Re: All very well

Ok, I have to admit that I g**gle'd the name (clearly my Linux-foo has a few holes and must be downgraded to merely Linux-bar status).

But if I hadn't then I'd've missed the joy of being told of the website that offers to tell me all about "Using Cowsay Linux Command Like a Pro"!

Type two commands into the cli? Now I don't need to copy AND paste anymore, I can just cowsay and go!

[that one in the corner]

Re: All very well

PS

In case that last paragraph doesn't make sense to you, when I were a lad and we wanted to change what the cow was saying, we 'ad to find it in t'archive document of doodles we'd half-inched from email sigs (and 'oo knows where they'd blagged it from) then paste it into own file. Copy'n'paste we did, aye, columns as well, to make speech bubble fit what we thought was witty that day. 'appy we were, whiling away the cold winter evenings, 'uddled around only machine big enough to 'old compiler, warming 'ands by glow o' disc activity light, making ASCII art in t'traditional way.

Now t'is all done wit' yon program, every cow perfect, none o' wee nicks, t'imperfections that show you're readin' creation of person willin' to put in time for craft.

[Bitsminer]

awk, grep and bark?

Wayyy back in the day, $WORK was inundated by Sun Microsystems folk who were pushing Sparc workstations on every desktop.

We were happy with NCD terminals and bigger servers.

Being an obvious VAX/VMS guy at the time, I distinctly recall teasing the distinguished Sun customer engineer about "You Unix guys and your awk, grep, and bark."

"What's 'bark'?", he innocently asked.

Mission accomplished.

[hammarbtyp]

good..now add it to Outlook Search.

[redwine]

grep should be ubiquitous.

[Stephen7Eastern]

Git better, non-MS nix utilities for Windows

A better way to get grep et al is to download git portable, extract it, and place these files somewhere in path,

.\git\usr\bin\

The bin dir contains all of the classic nix utilities. Unlike microslop software, these utilities respect user privacy, work on Windows 7 -so no Windows 11 requirement, and work as nix utilities were intended.

https://git-scm.com/downloads

[Bebu sa Ware]

work as nix utilities were intended.

Namely work.

[Eric 9001]

Re: Git better, non-MS nix utilities for Windows

I checked, as those are rather mostly GNU's Not Unix programs, as well as programs originally written for or ported to the GNU OS.

As for GNU, there's GnuPG, less, GNU coreutils, gawk, gsed, ggrep, bash, findutils, gdbm, gzip, nano and much more.

As for the other programs, there's perl, vim, vi, strace, xxd, dash and more.

GNU programs were intended to run on free OS's, that respect the users freedom, such as GNU/Linux-libre - portability to proprietary OS's is a secondary concern, to give the suckers a taste of freedom.

[TheMaskedMan]

While I can definitely see the advantages of having these tools to hand in Windows, it would be better if they were part of the core system rather than an optional download - you just know you're going to find yourself stranded on a PC that doesn't have the option installed and lacks the ability to install it.

Assuming they they work as expected, this goes some way towards eliminating my need for WSL I wonder if this might be a first tentative step towards leading it out back for a last cigarette?

[Doctor Syntax]

I've had all these things as part of the core system for more than 40 years.

[jake]

The MKS toolkit was quite handy, yes ...

[Doctor Syntax]

I see the list of commands includes ln. How does that work with MS file systems?

[Jou (Mxyzptlk)]

Enter mklink.exe /?. Included since Windows 2003 (I think), was available for NT 3, 4 and w2k as well as downloadable util. One difference to the unix filesystem variant: Can link to \\server\share\directory, and whether you can access the target depends on your login. Junction and link are like the unix variants, however a hardlink is deeper since two filesystem entries point to the same file instead of one linking to another. Google for "Hardlink Shell Extension", makes it easier, and then enter \Windows\System32.

[that one in the corner]

> Junction and link are like the unix variants, however a hardlink is deeper since two filesystem entries point to the same file instead of one linking to another.

Um, isn't the result of using "ln" without any special options to simply create another directory entry (in the same filesystem) that points to the same file, what Windows calls a hardlink being just what Unix calls, well, normal?

Then Unix added symlinks, one directory entry pointing at another directory entry which then points at the actual file.*

* All nice and easy to understand, no need to add terminology like "reparse points" into the mix, although I'm sure the Windows system has its good points.

[Jou (Mxyzptlk)]

If you remember what "crosslinked files" means for FAT file system, this is what NTFS can do by design. Hardlinks are not a directory entry pointing to the actual file in some other directory. It is the same file having two directory entries. You must read into it to see the difference.

[that one in the corner]

> Hardlinks are not a directory entry pointing to the actual file in some other directory. It is the same file having two directory entries. You must read into it to see the difference.

Yes.

And that is exactly what I said:

>> the result of using "ln" without any special options to simply create another directory entry (in the same filesystem) that points to the same file, what Windows calls a hardlink being just what Unix calls, well, normal

When you do "ln fred jim" under Linux the file data that is pointed[1] to by "fred" is now also pointed to by "jim". You can delete "fred" but the data still exists and can be accessed via "jim".

[1] the basic semantics of a directory entry is that it points at the file data; "small file optimisations" do put data into the inode but that should not be visible outside of the filesystem driver code.

[jake]

Even pre-Windows versions of DOS allowed some of this functionality.

See SUBST, ASSIGN and JOIN. Crude, and almost useless for those of us brought up properly, but it was a help. Occasionally.

[Paul Crawford]

I have used them and were very handy for what I wanted (e.g. a drive letter I could point to differing directory places as needed) but they really are not quite comparable to the UNIX links.

Fundamentally though the Windows file systems are just not like UNIX file systems so you can't do atomic updated by renaming, or update running process the same way. I have not tried the recent Windows links but in the past they were a horrible kludge that did not do the same "two names point to one bloc of data" that UNIX hard links supports, or one name is an alias for another name elsewhere that soft links do for all programs and not just some Explorer-aware ones.

[Jou (Mxyzptlk)]

NTFS can real hardlink. Used in c:\windows extensively since Vista.

HardLink Shell Extension - install it, and then look in c:\windows\}system32

DupeMerge the other tool from him...

If you check the history: Even NT 4.0 could (with Sp4 sesz waikipehdia).

[JLV]

clarification requested

So, should I understand that, in a powershell shell, those coreutils commands will just output a stream of text? No more, no less? With all the limitations, and advantages, of that format?

(After some quick use, I could easily see the advantages of Powershell for configuring systems due to its precise typing/object orientation, if you're wearing a sysadmin. For casual developer scripts and workflows on the other hand, this seems, to me, is an unwanted complication).

[Jou (Mxyzptlk)]

Re: clarification requested

You understood that correctly, this is what they HAVE to do to avoid breaking compatibility. In comparison to the powershell builti-in aliases which do output objects.

> For casual developer scripts and workflows on the other hand, this seems, to me, is an unwanted complication).

That is a point of view thing. If you have an object which has a clear defined .Name, .FullName, .Directory and .Extension property instead of fiddling around with a text filter which may break on funny file names... 'cause you CAN create a file name which contain a / or \ or * or ? or & and so on, the filesystem does actually allow it on Windows and Unix, but the layers in between don't like it. Or try to handle unicode...

Edit: The file or directory name can include a CR, an LF, and Escape character and other things you cannot type... Yes, I have seen those in reality on Windows, on Linux not yet.

[Dan 55]

Re: clarification requested

Just quote properly or use the --print0, -0, -z, or --null option depending on the command when you have a pipeline of commands.

[Jamie Jones]

Re: clarification requested

On Unix systems, a filename can contain any 8 bit character other than null and '/'. All parsing code should assume that.

The number of times I see programs fail if a filename contains newline characters (particularly at the end of the filename where shell substitutions strip them off), unprintable characters , and even some fail to grok a simple space!

And note how many "/tmp clearing" scripts will happily hose your system if you create a directory along the lines of "/tmp/plop\n/etc" and then create in that directory a file called "passed"...

[Jou (Mxyzptlk)]

Re: clarification requested

Thanks for confirming! But were they not upgraded to unicode capability somewhere along the last decades?

[Dan 55]

Re: clarification requested

On most filesystems there was no need to upgrade it to unicode capability, a filename in a path is everything that isn't a / or a \0.

[Jou (Mxyzptlk)]

Re: clarification requested

Yeah, but the API and a few things must be updated to handle those extended characters. Remember VFAT when it first came up? That was fun!

Here some "normal looking" unicode characters to test what your API is doing with then - these are totally legit normal characters, no \ or / or | etc in there although it LOOKS like they are in there:

？＞＜＆￤￥＼｜／＊＇＂：；＾《》¿⸮ΨⲮⲯ

[Jamie Jones]

Re: clarification requested

II'm surprised you managed to post those! I know El Reg allows some utf-8 unicode, but just about every one I've tried in the past gets rejected!

As Dan pointed out, there was nothing to update from the filesystem point of view, and that also extends to the API.

Sure, you'd need awareness on the application level, but not on the filesystem level. Put it this way, if you got an old version of some unix OS that predates unicode and utf-8, but you were using it with a utf-8 capable terminal, you'd be able to create filenames with utf-8 characters.

You could type "ls" and they'd display correctly. And as long as the version of "ls" and any other utilities were not written to specifically block non-asciii characters, they'd work fine.

Sure, if you wanted to count the length of a string in characters as opposed to bytes, you'd be on your own there, but as long as the commands you use aren't specifically altered to block non-ascii, they'd work transparently.

Where I think the confusion lies is that on Windows, I think the filesystem is made to be character-set aware. Correct me if I'm wrong, but whatever character set you use is I think translated into a common internal format.

On typical unix systems there is no conversion - you just create/access/delete a file using a name that is "just a bunch of bytes" terminaed with NULL. The only processing on that would be rejecting the '/' character. Everything else is just passed through "as-is". Unix doesn't care about character sets, it just stores the bunch of bytes you throw at it, it just accepts them, and throws them back to you unaltered when you read the directory etc.

Basically, it's the lack of character set awareness that makes it work with everything. The flip-side of the coin is if someone creates a file using (for example) iso8859 extended characters, don't expect them to display properly on your terminal if it isnt iso8859 aware, or is converted by some application that is.

[Peter Gathercole]

Re: clarification requested

Some UNIX systems had conversion modules that you could stack for a particular device to allow, say, a CP437 device to work with ISO8859-1 character sets. You would decide on a 'default' character set, and then have inbound and outbound translation methods stacked on the line discipline for data to/from the device. This was typically for character devices such as TTYs and printers.

SVR4's STREAMS based TTY driver had them, and AIX still has them, but nobody bothers to set them up any more. It was most useful back in the days when trying to interface CP437 (US PC) and CP850 (most PC's in Europe) devices, as well as X11s use of ISO8859, to handle currency symbols and other special characters back in the early 1990s.

At a device level, AIX can work and translate old ASCII national code pages, ISO sets even UTF-8, although the UTF-8 is not complete, as some things, such as aixterm (the AIX specific variant of xterm) has not got UTF-8 support, but strangely it seems to have been added it to dtterm (the X11 terminal emulator for CDE). Things stored in files are just bytes, and have to be treated correctly by whatever program is using the data. Just be careful about the Locale settings for your session!

[doublelayer]

Re: clarification requested

That works fine for UTF-8. It would not work fine with other encodings of unicode which can have bytes of value 0 or 47 which don't mean null or /. Partially, this is good, as I think standardizing on UTF-8 is usually the right thing to do because it involves the least need to worry about byte order and it has the least chance that something's going to break when it was only built for ASCII. But be careful when you say something supports Unicode to state if it only supports one encoding of it.

[Jamie Jones]

Re: clarification requested

LOL. Yeah, you're right, but are there any?

Still, I like your way of thinking! You have to expect the unexpected!

[that one in the corner]

Re: clarification requested

Not sure which bit you were responding to, so:

>> It would not work fine with other encodings of unicode which can have bytes of value 0 or 47 which don't mean null or /.

> Yeah, you're right, but are there any?

UTF-16 (as found inside 32-bit and larger Windows; sort of; depending upon precisely which Windows) or UTF-32; simplest cases, convert some ASCII text and ta-da, loadsa zero bytes which don't mean the null character.

>> But be careful when you say something supports Unicode to state if it only supports one encoding of it.

> Yeah, you're right, but are there any?

Loads of them. For example, lots of Windows programs will only do UCS-16 and call it Unicode (fine until you go past 0xffff). Too many programs in general don't include read/write options to convert encodings to/from whatever they are using internally: which is fine much of the time, whoever sees files in anything other than ASCII/UTF-8?

Whether you'll come across those nasty programs is another matter entirely; there are many more programs written and constrained to live inside on developers/company's/organisation's computers than there are let free to roam the world. Although, now so many people are using IDEs/LLMs that seem to feel the need to create a Github repo the moment "New project..." is clicked...

[geoff61]

Re: clarification requested

It's not just that unicode capability is not needed; adding it would break POSIX conformance, which requires that filenames are byte strings, not character strings. How/whether those bytes are treated as characters is a matter for the application.

[JLV]

Re: clarification requested

To be fair the number of websites that can’t be arsed to strip out spaces in a credit card number is even more impressive.

[Anonymous Coward]

Re: clarification requested

IF they work like the Unix versions, they'll do binary too - binary and text work perfectly fine with stein, stdout, pipes, redirections etc.

Text is just a subset of binary after all

[Peter Gathercole]

Re: clarification requested

Yes, pipes are a character stream, with little structure. Line orientation is applied to the character stream by what is being used to read from the pipe.

I did some playing around with iso8859 and UTF-8 a while ago (when using X11 between a system that was not 100% capable of handling UTF-8 [AIXs only has partial support, aixterm does not work with a UTF-8 locale] and a Linux system), and after that, I'm not 100% certain that even the character encoding is maintained through a pipe, making a pipe a byte stream, not a character stream.

[Jamie Jones]

Re: clarification requested

Yeah, it's definitely a byte stream.

After all, if it wasn't, you'd not be able to do things like :

gzip -c filename | uuencode

or any other piping that involves non-text data.

[Peter Gathercole]

Re: clarification requested

The point about character and byte streams is that UTF-8 is text data, just not as you would think of it. The fact that each character can be represented by 1, 2, 4 or more bytes is actually irrelevant to commands like uuencode, whose function is to represent any byte stream as 7 bit characters, so that they can be passed over non-8 bit clean transmission paths (such as modems), and reconstructed at the other end. Also see base64.

Gzip also does not care. Just bytes.

[sansva]

scoop is better

scoop is better

here's the list of what i have installed via scoop:

7zip 26.01 main 2026-04-28 12:54:57

autoruns 14.11 sysinternals 2025-05-18 09:58:35

coreutils 5.97.3 main 2026-01-31 16:36:12

eza 0.23.4 main 2025-10-04 22:15:39

findutils 4.4.2 main 2025-11-24 13:12:56

git 2.54.0 main 2026-04-26 10:47:09

grep 3.11 main 2026-04-28 13:19:51

less 702 main 2026-05-23 15:07:40

process-explorer 17.12 sysinternals 2026-05-09 20:52:49

procmon 4.02 sysinternals 2026-05-09 20:52:55

scoop-search 2.1.0 main 2025-07-20 21:15:02

sdelete 2.06 sysinternals 2026-03-05 15:15:57

tcpview 4.19 sysinternals 2025-05-18 09:58:28

telnet msys-inetutils-1.7-1 main 2025-07-23 17:11:27

vim 9.2.0555 main 2026-05-29 10:04:11

xz 5.8.3 main 2026-05-26 10:33:48

[that one in the corner]

Re: scoop is better

Gripping. The chilling horror of the cliff-hanger was worth wading through the stultifying first paragraphs, but when will we get the next installment?

[Jimjam3]

Embrace, Extend, you know the rest.

Best way to beat it is to not engage them.

[Bebu sa Ware]

Oooh noo, please, it's wicked to mock the afflicted†

"If I understand correctly, this means I can now use sudo instead of start -> CMD -> right click -> run as administrator when I want a sandwich?"

† As Lurcio (Frankie Howerd) often reminded the viewer.

[Andrew Williams]

Can't help thinking...

If soon regular grep etc will start behaving badly, slower etc

After all, embrace, extend, extinguish.

[jake]

Re: Can't help thinking...

Of course not.

I mean, I still have source code from yesterday, don't you? Not even the lawyers at redmond can change that ...

[Sandtitz]

Re: Can't help thinking...

Damn right.

Some of the Gnu herd have really odd nightmares.

[Denarius]

scanning logs

grep has its uses but I prefered sed. Awk if log has structure which rarely happens. Used the AT&T UWIN commands for years which had Win32 native commands and a POSIX environment as much as practical. Pity thats all gone. Nice to see M$ catching up after a mere 26 years. They might even write a light, fast reliable OS eventually after borging QNX or equivalent. Yes, Satan wears thick coats, why do you ask ?

[M.V. Lipvig]

Ugh

It took 20 years of me wanting to switch from Windoze to Linux for me to actually do so and when I finally do, what happens? Wondoze goes Linux.

[steelpillow]

MS are good at breaking their own standards

Give it a few years, and all the standard bash commands will be in there. The option to make bash your default shell will appear, with it and PowerShell executing certain commands differently. MS will then add a "PowerShell" mode to bash, initially via an explicit command but later with an auto-detect mode. It will be available for Linux and MacOS as well. At this point MS will deprecate PowerShell, and remove it entirely from Windows 13.

Well, I can dream.

[Eric 9001]

Re: MS are good at breaking their own standards

Bash is GPLv3-or-later and ancient versions are GPLv2-or-later - there is no way microsoft will include it as a system shell for that reason.

microsoft is implementing remote attestation - the idea is that the computer remotely attests that the computer is running an approved proprietary OS, that is unmodified (the core parts at least at first), to be able to access a website.

If bash was to be a system shell on such restricted system, in order to comply with the license terms, microsoft would need to supply source code and installation information, sufficient to allow modification and reinstallation and execution of bash as the system shell.

If remote attestation needs to pass to allow for the execution of bash after reinstall (GPLv2 & GPLv3), or for other parts of the system to continue executing after merely reinstalling bash (GPLv3), then microsoft would need to provide any required signing keys to allow remote attestation to pass - which microsoft would clearly not want to do (as such keys could then be utilized to allow free OS's to access websites restricted to only approved proprietary OS's).

Why would microsoft need to port a program that is already cross platform and available for GNU/Linux, windows and macos?

Still, you're best off executing bash in a real OS (GNU/Linux-libre).

[Pete 2]

Reverse Pacman?

So is this MS finally recognising the superior functionality (of command line tools)?

Or is it the first / next step in claiming ownership if the Linux domain.

[Fruit and Nutcase]

Satya Nadella - Report

B+ for effort in bringing in Unix commands

F/Unclassified for the abomination that is the current version of Notepad

[UncleDavid]

Re: Satya Nadella - Report

Classic Notepad is still there, and I have it pinned to my taskbar. Windows-2 brings it up.

[Forget It]

Cygwin

for the Win!

[Jason Hindle]

From the notes I keep on the single Windows dev system I maintain:

"PowerShell style grepping:

svn diff | Select-String -Pattern 'Index' -CaseSensitive -SimpleMatch"

I've just downloaded coreutils...

[AVee]

Re: From the notes I keep on the single Windows dev system I maintain:

> I've just downloaded coreutils...

I've just downloaded Linux.

[redwine]

My my

How the turns have tabled.

[Anonymous Coward]

The die was cast

When they invented Headless Windows servers, from there on it was uphill to full Linux and then on to Mainframes as terminals, now that Cloud has been wholly discredited on the grounds of Cost and Security.

Similarly my snazzy Rover motor car -> EV with AI -> horse and trap.

Motto being "make up your own damn mottos'

[Anonymous Coward]

Didn’t Microsoft offer this back in 1999 already ?

Windows Services for UNIX. https://en.wikipedia.org/wiki/Windows_Services_for_UNIX

I remember using this long ago.

[martinusher]

Cygwin has allowed us to do this for many years now

Installing Cygwin makes common Linux/Unix commands available to the Windows command line. In addition it allows proper scripting. Cywin's been around since the Dawn of Time (it seems) and not only gives you command line and scripting tools but it turns Windows drives into something resembling a proper filesystem (including file links, something Windows still doesn't seem to have figured out properly).

I'd guess that this move by MSFT is just another of their "Embrace, Extend, Extinguish" moves. They stuck with their DOS box for decades, well past its sell-by date, and then introduced their own verrsion of scripting which, like everything else, is just another proprietary tool you have to learn that works almost as well as what its copying but is subtly incompatible so nothing you learn from it can be used elsewhere.

[Nik_S]

Not sure why I'd use it

I have Windows Services for Linux and SSH installed on my Windows systems and pretty much use BASH in WSL for any command line stuff I need to do, other than adding a registry key I pretty much never use the old Windows command line.

[smalldot]

Re: Not sure why I'd use it

Nice. I had lost hope of seeing a mention of WSL before scrolling down eventually hits bottom of the page.

Cygwin does its job and I happily used it for decades. WSL completely took over once MS fixed the annoying issues in it.

[gosand]

So... are pipes supported? I did some looking, but don't see it mentioned or in examples given.

Grep is great, but its use would be limited if you can't use pipes, as would a lot of these tools.

I can't just download this on my work computer (the only place I use Windows) because it's not approved software.

I currently use cygwin when I need to do things like this, but it can be quite slow at times.

[doublelayer]

Why shouldn't pipes work? Pipes have been present in the Windows CLI for ages. Why should these programs handle them any differently than all the other programs do?

[Richard Crossley]

From a Linux perspective…

Phase 1: Ignore You (They don't think your idea will matter)

Phase 2: Laugh at You (They mock your vision as unrealistic)

Phase 3: Fight You (They push back as you gain real traction)

Phase 4: You Win (Your idea becomes the new normal)

[Evaluator]

Its 2026. Who still talks about legacy Windows or legacy Mainframes? Thats all behind us now and its quite safe to leave it behind. Efforts to make it somehow relevant again are futile, and reek of desperation.

[jake]

Be sure to tell the ER folks that you don't need or want legacy code used in your diagnosis and treatment next time you are admitted.

While waiting on the above to happen, get on the phone and let all your financial institutions know that you want nothing to do with mainframes.

Presumably, you want to shut down mass transportation and shipping, and anything to do with space exploration. And I guess mining is right out.

Need I go on?

[Eric 9001]

It's incredible that the register now posts blatently wrong articles

But the fact checker has arrived - all is saved.

After all, GNU commands (and in this case, inferior clones of the programs implementing such GNU commands) have nothing to do with Linux - microsoft's own page doesn't make the error that UNIX-style command-line utilities are somehow "Linux" (although of course in the next paragraph, it proceeds to refer to GNU as "Linux").

GNU powers are somehow "Linux powers", despite how such power is fully accessible without or with Linux (for example, how "WSL1" had GNU, but didn't have Linux)?

>Unix was built on the philosophy of small programs that can be easily piped together to build larger workflows, so that, say, the output of grep can be combined with other material through the cat (concatenate) command

It doesn't seem like the author has ever properly used GNU commands and Unix pipes - although cat can be used to concatenate the output of grep in GNU bash like so; `cat <(grep text file0) <(grep text file1)` (process substitution is a GNU extension), in practice I can't think of a case where such command would produce useful output - generally grep would be used in a command such as; `printf "%'.2f\n" $(pdftotext -raw $file - | grep 'total' | sed 's/total//' | tr -d '\f' | tr -d ',' | tr ' ' '+' | bc -l)`

>for Linux expats who occasionally work in the Windows CMD: They will no longer need to remember the standard “ls” command for listing the contents doesn’t work in Windows, and that they have to type the DOS-era “dir” command instead. Now both work.

`ls` did work in powers hell for years, as that's aliased to `Get-ChildItem` - it's only in cmd.exe that there is no `ls`.

Don't tell me I have been unfortunate enough to have more experience with windows than the article author?

>Several long-time Linux commands conflict with existing CMD and PowerShell commands of the same names, such as date and rmdir.

GNU date predates Linux - src/date.c in sh-utils-1.12.tar.gz; "/* date - print or set the system date and time\n Copyright (C) 89, 90, 91"

GNU mkdir predates Linux - src/mkdir.c in fileutils-3.13.tar.gz; "/* mkdir -- make directories\n Copyright (C) 90"

>One could run Grep before on Windows through third-party packages such as Cygwin, though Coreutils has the speed of native functionality, thanks to its implementation in Rust.

Yet another incorrect claim - GNU grep for "Cygwin" is compiled into a native .exe.

I would be surprised if the rusted implementation didn't run slower.

>Microsoft built Coreutils from the uutils open source effort of rewriting Linux core commands in Rust, for the purposes of memory safety and cross-platform portability.

Wrong.

uutils exists to clone GNU coreutils, so the enemies of humanity have half functional coreutils available to attack people with as proprietary software.

Memory safety is a minor security issue with a coreutils, the important security issue is logic errors, such as TOCTOU races etc.

uutils still has less functionality than GNU coreutils and a single audit by a single developer discovered 113 issues, 44 severe enough to be assigned CVE's; https://seclists.org/oss-sec/2026/q2/332

Meanwhile, GNU coreutils has been working out logic errors and also memory errors for decades (I reckon it would have taken less work to develop a mathematical proof for gcoreutils, to eliminate the remaining memory mistakes, than to write uutils).

Rust has poor portability - GNU coreutils already supported far more systems and more processor architectures.

>No doubt, it also helped Microsoft that this package was written under the permissive MIT open source license, thereby sidestepping the sticky GNU GPL requirements that so spooked Ballmer.

Most MIT licenses were proprietary ones (although that looks about right for the typical "open source" development model project).

MIT expat predates "open source" by years.

Ballmer was complaining about the GPLv2-only - GNU coreutils since 2007 has been GPLv3-or-later.

>There are some Unix/Linux commands that this project won’t touch, such as dd

*Unix & GNU

>rather than POSIX permission bits, none of the Linux permission-setting commands (chcon, chgrp, chmod, chown, chroot, groups) make any sense to Windows, so any scripts changing file permissions still must be massaged (Linus Torvalds created Linux to adhere to the POSIX standards that define the Unix commands).

You couldn't write a more misleading and wrong statement.

Linux was not written to adhere to any POSIX standard - just consider that POSIX.1 (IEEE 1003.1-1988) was as proprietary as could be, which clearly prevented Linus from getting a copy (not much in POSIX is applicable to kernels either - the parts in POSIX that relate to kernels are left mostly undefined and therefore implementation specific - for example, the numerical values of exec, write and read permission bits are not defined).

Linus, after getting his quick and dirty kernel to boot, implemented support for MINIX's filesystem - MINIX was not POSIX (only version 2.0 of MINIX, released in 1997, was POSIX-compliant).

MINIX's filesystem used Unix-like permission bits, which Linus re-implemented; #define MAY_EXEC 1 #define MAY_WRITE 2 #define MAY_READ 4 (see fs/namei.c in Linux-0.01 (released as proprietary software)).

Later filesystems such as ext and ext2 implemented the same UNIX-like permission bits, but the - but Linus did not implement the GNU chcon, chgrp, chmod, chown, chroot & groups commands and those were not originally implemented for Linux - those years prior were used to set permissions on proprietary Unix's and were only later ported by GNU to also support GNU/Linux (excluding chcon and groups, which came later and were primarily developed for GNU/Linux - groups is also portable) .

GNU/Linux still doesn't adhere the to the POSIX standard - Linux implements a lot of custom SYSCALLs that POSIX doesn't define and while it does allow implementing open() and close() etc, which is defined in POSIX - it ignores most of POSIX - while GNU tends to implement parts of POSIX if it has a good ideas (for example the chmod & chown commands) and now has some optional support for parts of POSIX, it ignores the bad parts and therefore does not adhere to POSIX.

>When Windows was king at Microsoft, Linux was public enemy number one.

The public enemy number one was rather GNU - although Microsoft realized that if they named the GNU even once, they would lose, thus they referred to it as "Linux".

>larger competitive threats to worry about than open source

It is an error to imply that Linux is "open source".

While Linux uses an "open source" development model, it is not "open source", as is not even 50% source-available!

>newfound love for grep probably has more to do with its recent popularity as an agent tool for finding the needles in the haystack.

It's rather likely related to a defect of how LLM's can output GNU bash commands in response to a prompts for powers hell commands and how embarrassing it is for simple commands to not work after being pasted into powers hell.

[UncleDavid]

Not only have we had cygwin for decades, but the author seems to think there were no UNIXes before Linux. I mean, when was I first using awk and grep? Late 1980s for me, because I was working on proprietary OSes until then.

[Eric 9001]

Linux isn't even a Unix - it's only a Unix-like kernel, but the extent on its Unix-likeness is;

- How it's proprietary software.

- Its monolithic design.

- Its support for Unix-style permission bits in filesystems (although everything else is more or less completely different).

The author has tied the article into knots, by writing "Linux", where GNU's Not Unix, or at least GNU/Linux (or GNU+Linux or GNU with Linux or GNU without Linux) belongs.

[mattrmine]

Nice article. Just a small request for the author. Stop quoting Steve Ballmer, https://www.boxofcables.dev/stop-quoting-steve-ballmer/

Although, they did tie it back in with a relevant comment about the GPL, so not as lazy as most that reference the Linux is a cancer quote.

I'm with others, I just use Git for windows and it gives me the same tools, been using it for years.