Finally a modern shell that understands the importance of COMPATIBILITY! This gives it a realistic chance of getting real adoption. Shells like zsh and fish will never get mainstream adoption because they are not compatible with bash.
> /bin/bash your_script.sh
And if your script is written with bash in mind, use a shebang:
> #! /bin/bash
And it will work perfectly fine on fish. As long as I have a bash binary, why do I need COMPATIBILITY?
1) what you paste might not be exactly what you copied. i.e: http://thejh.net/misc/website-terminal-copy-paste
2) possible licensing issues
3) it enables cargo cult programming
Actually, my zsh config mostly behaves like fish with great completion, syntax coloring and sensible history handling, with zsh syntax which is close to bash. So I can copy paste stuff from the internet and reuse my knowledge from the time I used bash because it was the default, and still leverage the improvements brought by zsh.
I don't understand 2.
For 3, of course you should understand what you run, but I don't want my tools to get in the way. My tools should allow me to do what I want, not prevent me from doing something for technical reasons. This is a question of education. If people want to run something without understanding it, I bet they will type it blindly, if they can't copy paste it. They will just be slower at running things blindly, leading them to a disaster just a bit slower. Please let me not lose my time even more when I cause disasters.
(Yes, true, retyping stuff forces your more to think about it, but I already review the things I paste into my shell)
> CC=gcc make
And if your program is written with gcc in mind, put that in the Makefile:
> CC ?= gcc
And it will work perfectly fine on LLVM systems. As long as I have a gcc binary, why do I need COMPATIBILITY?
----
A big part of the long-term objectives of OSH is that it provides a way to move to a better language, without having to entirely rewrite your codebase. Think of it in a similar spot to C++ (originally); a big part of the design is that your old C (bash) code is already valid C++ (osh), and you can start using new C++ (osh) features wherever you see fit in the codebase, without having to rewrite anything first.
But a shell script is a script, not a codebase - they're written for one-off scenarios in very specific environments. I imagine that some folks have very large, complicated systems that depend on many bash scripts. But in such a case one can still use fish to just execute the bash scripts and pipe the output around as needed. If you have a single, large bash script that does some really complicated stuff, you can begin porting it by separating it into smaller scripts, calling those from a modern scripting language like Python and rewriting aspects of the process as you go.
A C or C++ codebase is in no way equivalent to a bash and scripting codebase since C and C++ are not nearly as easy to call from different versions - you would have to split up your build process across different versions of a compiler and build a library to accomplish the same thing.
Exactly? What you just said is true for CC and SHELL; I'm not sure what is confusing.
> But a shell script is a script, not a codebase - they're written for one-off scenarios in very specific environments.
Ahh, there it is. IMO, a big part of the reason why many people think that people shouldn't write shell scripts is that they've only had to deal with shell scripts written by people who didn't treat it as a real codebase.
It's hard to say what private codebases are doing but:
- Docker, which is expected to run in many different environments, has thousands of lines of shell. That isn't one-off, and isn't for a specific environment.
- Most GNU/Linux distros can generally be thought of of many separate upstream packages glued together by many thousands (if not millions) of lines of shell. It might be expected to run in a fairly specific environment, but it isn't one off, and is massive enough, I'd have a hard time not treating it as a codebase.
> ... you can begin porting it by separating it into smaller [programs], calling those ...
> A C or C++ codebase is in no way equivalent to a bash and scripting codebase since C and C++ are not nearly as easy to call from different versions
C is very easy to call from different versions, the ABI(s) has been very stable over the years (unfortunately, this isn't as true for C++). Just say `myobj.o: private CC=gcc-4.7` or whatever compiler is needed for myobj.c, to set the compiler for just that object.
You seem to be saying "I don't need C (bash) compatibility, I just need an FFI that makes it easy to call C (bash) code."
C/C++ and Bash/OSH are different, but not that different.
Having bash compatibility is a quality of life feature, no need to debug all the werid cases where it breaks for purely syntax reasons.
So basically you should never make /bin/sh fish, because then you will no longer have a Unix system (according to POSIX).
On ubuntu, /bin/sh is always dash and it's not possible to change without changing the symlink:
https://wiki.ubuntu.com/DashAsBinSh
So, if you use chsh to make your shell fish, it would have no effect on os.system or the system function in C.
zsh and fish don't really belong in the same comparison IMO.
zsh is, like bash, a ksh-like shell with a Bourne-style grammar. Obviously it depends on the exact use case, but in practice, for basic scripting purposes, it is almost a super-set of bash, and it provides several emulation options (like sh_word_split) specifically designed to increase compatibility with POSIX and with bash in particular. It even provides shims to support bash completion functions. (It is fair to point out that, even with all the emulation stuff enabled, it's still not completely bash-compatible, nor POSIX-compliant. It's close enough that the changes required are usually extremely trivial, though.)
fish on the other hand has its own completely different grammar and makes no attempt to provide POSIX/ksh/bash compatibility at all.
Zsh isn't a new kid on the block. Both it and bash are actually about the same age: 28 years:
e: sorry some connection interruption and now this is redundant to other comments.
But of course your argument has the fundamental flaw that the Bourne Again, Korn, and even Bourne shells were not compatible with their various predecessors, but that turned out to be not as problematic in practice as you paint it to be. And we've had all sorts of things gaining "real adoption" over the years, from Norton Commander clones to Perl. The world is nowhere near as narrow as you think.
https://en.wikipedia.org/wiki/Shebang_(Unix)
I used fish for years, never had a problem with bash or zsh scripts.