Cash: a cross-platform implementation of Unix shell commands in JavaScript
github.com
github.com
It comes with an easy to use installer and `pacman` package manager. Their repositories have lots of stuff already compiled to windows usage (the silver surfer, gnu global, etc).
Also, sshd works mostly out of the box. Ability to ssh to Windows box into a functional shell (not crippled cmd.exe) is a killer feature for me.
pacman -S msys/apackage
Some notable changes are:
- It has its own package repository, using PKGBUILDs on github. It can also be updated from within its own shell. Cygwin doesn't do this, for very important reasons, involving autorebase hell which MSYS2 is certainly still subject to.
- In their fork of cygwin1.dll, they removed support for symlinks (i.e. `ln -s` creates a full tree copy); and the /cygdrive/ root directory was replaced with / (just like the old/deprecated MSYS1).
- It has three startup links, in which gcc/ld/make and the like are all "symlinked" to different versions (e.g. targeting win32, targeting win64, or targeting MSYS2 itself). It makes it easier to compile software targeting windows. You should install separate -devel packages for each "environment".
- MSYS2 focuses on packaging dependencies that would be useful for compiling software targeting the Windows platform (e.g. libXYZ). In comparison, Cygwin is more of a mini-OS, packaging applications for general use (e.g. rsync, BIND, MySQL and X11). There is a lot of overlap, but many exclusive packages.
- MSYS2 is amenable to merging back with Cygwin, but, the patches they've made to cygwin1.dll can't be upstreamed. Cygwin proposed a new plugin system that would allow MSYS2 functionality within Cygwin, but, nobody has done the work to port MSYS2 to this new system. (maybe outdated information)
We didn't remove support for symlinks, you can enable them in the MSYS env. var winsymlinks:nativestrict if you want. If symlinks didn't require special permissions, we'd enable them by default, but unfortunately they do. Maybe one day Microsoft will change their minds on this. I can only hope so. I guess you may have meant that we don't create the 'Cygwin special' symlinks that winsymlinks:native falls back to when it doesn't get permissions? Yes those are an interoperability disaster for MSYS2 when native programs read them.
The 'msys2' software repository (as opposed to the 'mingw32' and 'mingw64' ones) contains things that link to msys-2.0.dll which is GPL, and yes it includes compilers and linkers that in turn generate new PECOFF objects that in turn link to msys-2.0.dll. This repository exists mostly as build scaffolding (Autotools, bash) to support building native Windows software (as exists in the other two repositories) and that is the real goal of MSYS2. If you want POSIX-y GPLed software on Windows, use Cygwin.
You are right to caution people on the naive usage of our msys2/gcc package, but you've made it sound like something much worse than it is.
You can explicitly include it if you need the POSIX compatibility parts missing from Windows, but most software doesn't.
I'm really using `tmux` inside `mintty` so I have an emulation of tabs inside one terminal. It's not super-convinient, requires the user to setup his/her own .tmux.rc, but it gets the job done (still orders of magnitude better than cmd.exe or "even" powershell).
But there is cygwin connector: https://conemu.github.io/en/CygwinMsysConnector.html
it work quite well, and yeah ssh to a windows box with a real shell is definitively something you want :)
[1] http://pubs.opengroup.org/onlinepubs/009696699/utilities/con...
That's not to say that standards are bad and shouldn't be followed. Just that, sometimes, you really don't need a 250 page committee-designed specification to get some basic shit done.
(Open) standards-compliance becomes essential if we want our work to outlast us. Yes, we all know design by committee is horrible and gets nothing done. The solution is get rid of specs completely though. I don't trust "javascript developers" to have any sort of discipline. I'm sorry if this sounds like stereotyping but it just seems like a trend that we can't ignore.
Do you know how long I spent working on getting the specs right in Cash? Cash isn't perfect, but it took me months of "discipline" before I would let myself do even the initial release, which is `v0.1.0` btw.
I do actually agree with your point about compliance. It would be really cool if we had a POSIX-conformant set of shell commands written purely in JS, as an alternative to having to find and install compiled binary ports that run on our particular non-Unix systems. At least, it's an interesting idea.
Instead whenever something like this comes up, we see a bunch of grumpy systems programmers waving their fists in the air, as if C is the only language powerful enough to manipulate basic strings in the shell. Seems a bit silly to me when you think about it.
However, why do we need to write shell commands in java script? I keep hearing about this new fancy systems language called rust which should be good enough for most projects. Why do we insist on using the same one language everywhere?
https://github.com/aisola/go-coreutils - in Go.
https://github.com/search?l=Nimrod&q=coreutils&type=Reposito... - in Nim (didn't seem to take off)
You know how people write a to-do list, or a forum, or a blog to better learn a language? Some people write coreutils.
Things seem to live on here:
"Why do we insist on using the same one language everywhere?" Who is this "we" you're talking about? Where is this "insistence"? It's not like there is some cabal out there that is organizing a campaign to rewrite everything in JS and also delete everything else. What does it matter to you that people started a new project, that re-implements functionality of a dear, favorite project of yours, without taking resources away from that dear, favorite project? These people, who are only wasting their own time, who would have never worked on your dear, beloved project anyway? If you don't want to use JS, just don't. Stop reading posts about JS.
Because, yeah, that would be an awful thing to happen to shell utils.
In all seriousness, I am struggling a bit to see a point in porting everything to JS (beyond a weekend project because why not, let's learn something).
I might be a bit out of the loop since it's been a while that I worked on Windows (and have been using msys2 instead of cygwin back then), but how come DDL and native compiling are the issues in cygwin?
And the 1/15th of the size bit. It's largely simply negligible with hard drives (and even SSDs recently) nowadays.
No snark intended (well, other than the first line, sorry), just genuinely curious.
The value of this is that it works easily, portably, and with minimal overhead.
By bigger question is, why does posix sh deserve to win? It's plaintext pipes approach is really frustrating in 2016.
I think that in many aspects plaintext has won. Many historical records of the last century will be or have already been lost, because of formats that nobody can read.
OTOH, plaintext is readable and supported by almost everything under the sun.
But keep in mind I think it is bad for pipes only.
And about why POSIX deserve to win ?
For me it's about cross-platform command-line, I need to be able to run command-line tools that just behave the same under Windows, Mac OS X and Linux.
So far, Windows has ignored the command-line for years, and when they don't ignore it they change it every couple of years, from scripting hosts WSH to PowerShell to whatever else ...
Just sayin' it's hard to take Windows seriously when it come to the command-line environment, it is a huge mess.
Then join my headache world of all 3 versions of bash doing subtly different things. We used to think our automation/deploy scripting could be cross platform if we used bash. Oh what heady and foolish days those were.
NPM makes cross-platform installation simple, easy, and scriptable by default.
Dependency management. The package manager supports both local and global installations, as well as the ability to manage multiple versions of a dependency where necessary. Not by convention, by default. Dependency hell simply isn't an issue in the JS ecosystem.
More secure. Scipt installation/management doesn't require root privileges. The runtime uses it's own sandbox. No matter how safe the underlying OS is, it's virtually impossible for a malicious script to break out and mutate memory/data outside of it's context. PwnToOwn competitions are frequently held to test, identify, and harden security.
Project hosting is trivial to setup. Package installation, upgrade, removal is supported by default.
Scripts aren't tightly coupled to the OS. So you don't have to import the entire universe to use them. For example, Cygwin or MiniGW not required.
Scripts don't require compilation. If you run into problems, it's trivial to open up the source and correct the issue yourself. Shorter iteration/feedback loops on OSS projects means more users are capable of contributing fixes and/or new features.
In short, all of the pain points that suck about native application development have been solved in the JS ecosystem.
Just the 'import the universe' point alone is enough to deter any dane dev from porting a *nix binary to Windows. Disk space isn't the concern, surface area for potential security issues, bugs, and the maintenance overhead of keeping an OS emulation layer updated are.
Javascript is a truly cross-platform solution.
No GCC or compilers, which I would think is one of the biggest reasons most people use Cygwin? Cygwin isn't just shell commands, and surprisingly PowerShell doesn't suck as much it features some unixy commands. As well as others have mentioned Clink makes cmd.exe suck even less.
If you have something customizable, but not cygwin I'm all ears
But I suppose at least you only had to press one key to type it ;)
* https://blogs.windows.com/buildingapps/2014/10/07/console-im...
* http://www.nivot.org/blog/post/2016/02/04/Windows-10-TH2-%28...
* http://www.hanselman.com/blog/Windows10GetsAFreshCommandProm...
No, it's not perfect, and PuTTY isn't always the answer, but who'd have thought https://github.com/PowerShell/Win32-OpenSSH would ever be a thing.
ConEmu is a great container for a tabbed interface of Babun, PuTTY or powershell instances.
Awful fonts, worse rendering, crappy copy/paste, limited
size, no split screen or tabs
Guess we're in opinion-mode at this point.
Can you provide an example of what you feel is a beautifully designed.. terminal container? We're still talking about the border of a shell are we not?
I must be missing something here.
It is slick, has nice copy/paste, can resize, do split terminals, and tabs.
think of it, what is the utility to implement shell commands in a cross-platform way ?
only for Windows
You don't need an ES6 implementation of `ls` on Linux and Mac OS X, the tools are already there and yeah they are "ugly" compiled to native executable, but it is exactly what you want for shell commands
so you are basically trying to solve a Windows problem, but sorry you're doing it wrong
Windows problem is not about lacking shell commands, it's about lacking a POSIX environment
sure you want command line utilities like `ls`, but those are mainly useful when run inside a POSIX environment, and that is exactly the problem that cygwin have solved.
Now about some statements
"No ugly DLLs":
try to do a `ldd /bin/ls` on a Linux system you will see dependencies on `libc.so`, `libselinux.so`, etc. having tool like `ls` being dependent on `cygwin.dll` etc. is perfectly normal, nothing ugly about it
"Works in any terminal":
all the cygwin binaries can work inside a `CMD.exe` prompt, just add the "C:\cygwin\bin" path to your environment variables.
when you run Bash shell like Mintty, you also have access to the `CMD.exe` environment on top of the POSIX environment, for ex: you can call powershell scripts.
"Let's mix some Windows & Unix commands together"
`$ ipconfig | grep IPv4 | sort` works perfectly fine under Cygwin with bash
"but I only want certain commands"
maybe use package management, for ex you could use apt-cyg with cygwin, and do things like `$ apt-cyg install ncurses` or `$ apt-cyg remove ncurses`
Cygwin is an entire OS ecosystem of dependencies, tools, libraries. POSIX utilities are so tightly coupled to the OS, it's virtually impossible to use them with any degree of confidence without importing the entire universe. There's nothing 'perfectly normal' about such a poorly structured architecture.
JS dependencies are explicitly defined in a package's package.json so it's trivial to track a package's dependencies.
Likewise, one could create a powershell implementation in JS and -- barring windows-specific features -- Powershell scripts would 'just work' in a nix environment as well.
This package makes it trivial to port POSIX tools to Windows. What about greenfield development of utilities that need to work in both nix and Windows? Instead of building for one platform first then porting it to another (incl all the maintenance issues involved in maintaining separate forks in sync) why not use a truly cross-platform language from the start?
The Javascript ecosystem comes with it's own package management system.
Apt-get attempts to be 'everything to everybody'. It requires a monumental effort from the OSS community to maintain the different sources. Outdated packages are the norm making it harder for software maintainers to resolve bugs. Submitting new packages or publishing new versions of existing packages is a PITA. Etc...
NPM's source is centralized and provides a very useful online portal for: searching for packages by keyword and/or tags; publishing the Readme ad human-readable HTML (ie via Markdown); finding related links to the source control, issues, project pages; tracking downloads and development progress stats.
If you prefer not to publish to NPM the NPM directory, packages can be installed directly from GitHub, Bitbucket, etc.
Tapping the broader exosystem is easy for both users and developers.
The big benefit is that you get cross platform support and anyone can contribute!
Overall, it just plays well with JS applications. If I have a bunch of domain-specific utils used in my application and I want to use em as I move some files around, using something like shelljs makes it very to mix and match.
I'm interested in giving cash a try, though. It's not immediately clear how it differentiates itself.
EDIT: I just scrolled to the bottom of the README and it has a section on the difference with shelljs. It appears that they have different goals.
Cmd.exe isn't so bad after installing clink for readline behavior and learning a few idioms.
The only thing really bothersome is the lack of job control (partially obviated by ConEmu), which I didn't see in Cash.
For Javascript we have the engine as V8 VM already, is it possible we can use javascript the way as python/bash(i.e. #!/bin/js) someday? that means ignoring the DOM/web related portion and make javascript a true client/server side script language, then it's really close to 'one language rules all'.
#!/usr/bin/node
console.log("hello");
Unless that's not really what you were getting at with your comment. If I misunderstood, sorry!