Hacker News Reader

Comment by pjmlp | Hacker News Reader

> Several commands share names with built-ins in CMD and PowerShell. Whether the Coreutils version runs depends on the shell, the PATH order, and (for PowerShell) the alias table.

Well this is not very satisfying, what about proving a way where it actually works without us having to guess where the failure root cause happens to be?

View on HN

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

So ls in many systems will match the behavior of dir, and only accept the flags for dir. But if you use a system with the newer coreutils release here, ls will expect ls flags!

Not that it detracts from your point, but PowerShell defined Linux-like aliases for PowerShell commands, not the old CMD.exe binaries.

So ls would actually match the behavior and accept the flags for Get-ChildItem, not dir.

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

What a great developer experience out of the box!

I was going to comment that any sort of script that you are using in multiple environments probably should have all of the paths completely written out. I usually try to do this myself as I have gotten burned by binaries from unexpected paths on new systems a number of times.

But then I realized that the point of this project is to make it easy to write scripts that can be used on multiple OSs... and that is going to make fully-qualified paths possibly a nightmare. Anyone know if these get put at `/bin/`?

On nixos they're not, there's a single executable in /bin -- /bin/sh, and a single executable in /usr/bin -- /usr/bin/env

Sounds like a case for GNU Autoconf and ./configure.

A big part of the point is so you can use scripts made for other platforms on windows natively, which you lose when you have to alter them to pass absolute paths

Busybox helps you avoid this nicely on Windows. When you run one of one of its shells, it uses all it's own builtins in preference to anything external.

Get the 64-bit version: "there's some advantage in using the 64-bit executable busybox64.exe. In particular, it can be quite a bit faster."

https://frippery.org/busybox/index.html

Busybox is nice, but it's kind of like the Blender default cube to me: my only memories of it are removing it on sight to replace with something better.

It actually failed even before that. The project states "The goal is to make moving between Linux, macOS, WSL, containers, and Windows frictionless: the same commands, flags, and pipelines work the same way, so *existing scripts carry over without translation.*"

... but they failed to provide a port of Bash - so how exactly do they expect someone to run a bash script in Windows "without translation"? If the answer is WSL, then there's no need to port the coreutils over because WSL distros already include them. If the answer is to port the scripts over to PowerShell, then you wouldn't want to call Windows coreutils in your PowerShell scripts and run into unexpected behaviour (and also lose out on the object manipulation advantages of PowerShell).

And finally, they failed to port over commands that would actually be useful - like dd, for writing ISOs to a flash drive or backing up drives. chroot could've taken advantage of Windows' new sandbox feature to switch to a virtual C: drive. chown could've been an easier alternative to takeown/icacls. chmod could be used to remove the annoying network file blocks and also change file attributes and so on.

This whole project seems like a half-assed attempt at nothing.

Bash itself is an odd duck in scripting, with some dark historical crevices: http://tiswww.case.edu/~chet/bash/POSIX

A better option is a pure POSIX shell, the best-known of which in Linux is dash, but there is an existing Ada port to Windows here:

https://github.com/AdaCore/gsh

If non-POSIX features are required, the Android decision for mksh might suggest oksh for Windows.

I guess, it's for yaml CI scripts.

Don't do the absolute paths. Do the environment.

Maybe someone out there mixmashes PowerShell, bash, sh and cmd scripts from different platforms in one session - but usually it's one, quite straightforward 'flow' which requires a quite specific environment.

How do you propose for this to be solved without breaking existing CMD batch files and PowerShell scripts and invocations by applications?

The same way as cygwin, mingw?

Start a terminal session where they come first in the PATH?

That way one knows where they are getting into.

Well, you can have that now? Where is the problem?

The problem is that not only I have to manually do it myself, it is incomplete, quite the opposite of what is already out there.

In what sense is this half baked job supposed to be better?

In the case of find and sort, the command invoked also depends on argument sniffing, with a fallback through the registry when that is indecisive: https://github.com/microsoft/coreutils/blob/main/src/nthelpe...

Maybe it’s for the llm tool use PATH?

That was the most plausible reason to even mention it, that I could think of.

Reply on news.ycombinator.com