3 ms·
> 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 PowerShel
by pjmlp 5mo ago
> 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?
- chasil 5mo agoFully-qualify the path to the target program, and it should be no concern.
- LoganDark 5mo agoA 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
- chasil 5mo agoBusybox 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 https://frippery.org/busybox/index.html
- LoganDark 5mo agoBusybox 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.
- d3Xt3r 5mo agoIt 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.
- chasil 5mo agoBash itself is an odd duck in scripting, with some dark historical crevices: http://tiswww.case.edu/~chet/bash/POSIX 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 https://github.com/AdaCore/gsh If non-POSIX features are required, the Android decision for mksh might suggest oksh for Windows.
- GoblinSlayer 5mo agoI guess, it's for yaml CI scripts.
- justsomehnguy 5mo agoDon'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.
- pjmlp 5mo agoWhat a great developer experience out of the box!
- larkost 5mo agoI 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/`?
- deleted 5mo ago[deleted]
- ocdtrekkie 5mo agoThe 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!
- zanecodes 5mo agoNot 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.
- scoopr 5mo agoMaybe it’s for the llm tool use PATH? That was the most plausible reason to even mention it, that I could think of.
- layer8 5mo agoHow do you propose for this to be solved without breaking existing CMD batch files and PowerShell scripts and invocations by applications?
- pjmlp 5mo agoThe 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.
- Tobu 5mo agoIn 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/nthelpers.rs https://github.com/microsoft/coreutils/blob/main/src/nthelpe...