5 ms·

Why do people care about "COMPATIBILITY" so much w.r.t. shells? It's so easy to use other shells to run your script. > /bin/bash your_script.sh And if your sc

Why do people care about "COMPATIBILITY" so much w.r.t. shells? It's so easy to use other shells to run your script. > /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?

yjftsjthsd-h 9y ago
If you use the same shell interactively as you script in, then you only have to learn the one language.
- jamesgeck0 9y ago
  Except Oil has both POSIX compatibility and Oil. It's not much difference from Fish, where you can largely ignore the built-in scripting language and just write bash scripts if you'd like.
  - yjftsjthsd-h 9y ago
    Yeah, with oil I agree. It appears that fish is sometimes incompatible, though; there's a comment down thread about 'Foo=bar baz' working differently, and I have actually used that interactively.
jhasse 9y ago
To copy and paste stuff from the internet.
- partycoder 9y ago
  That's a great argument for fish.
  - jhasse 9y ago
    That you can't?
    - partycoder 9y ago
      Why not to copy and paste: 1) what you paste might not be exactly what you copied. i.e: http://thejh.net/misc/website-terminal-copy-paste http://thejh.net/misc/website-terminal-copy-paste 2) possible licensing issues 3) it enables cargo cult programming
      - jraph 9y ago
        For 1, my configuration of zsh solves the problem and avoids surprises by marking pasted shell code and letting me review it before running it, even if there are several lines. This is great for just pasting stuff from the internet and adapt as I wish without having to retype the entire thing or use an editor. I think this is a default behavior in oh-my-zsh. 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)
        jraph 9y ago
        Okay, bracketed paste does not help against attacks.
LukeShu 9y ago
Why do people care about "COMPATIBILITY" so much w.r.t. C compilers? It's so easy to use other compilers to build your program. > 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.
- aspaceman 9y ago
  I'm very confused by your analogy. In the same way that I can hold onto a binary for /bin/bash, I can do the same for gcc-4.7 or whatever. If your software depends on a very specific version to remain compatible, you just keep that thing around which is precisely what the CC env variable is for. Eventually, you'll want to add / change / or update that software, and that's where it's nice that updated versions remain compatible so you don't have to rewrite everything in your codebase. 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.
  - LukeShu 9y ago
    > I'm very confused by your analogy. In the same way that I can hold onto a binary for /bin/bash, I can do the same for gcc-4.7 or whatever. If your software depends on a very specific version to remain compatible, you just keep that thing around which is precisely what the CC env variable is for. Eventually, you'll want to add / change / or update that software, and that's where it's nice that updated versions remain compatible so you don't have to rewrite everything in your codebase. 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.
hrktb 9y ago
One of the werid cases with fish as default shell is scripts and programs that expect bash when executing “system” commands. For instance a php or Java program running shell commands. Having bash compatibility is a quality of life feature, no need to debug all the werid cases where it breaks for purely syntax reasons.
- djsumdog 9y ago
  That's just lazy programming, and if anything, we should have more incompatible shells so that developers will start to write their programs to stop shelling out and run individual programs, or if they do shell out, actually declare the shell you're using at that point and don't assume it will be sh compatible.
  - deleted 9y ago
    [deleted]
- Symmetry 9y ago
  Personally I leave bash as my login shell and just set my terminal emulator to launch fish on startup.
- chubot 9y ago
  Right, the system() function in C, which PHP probably uses, and is os.system() in Python, is DEFINED to run /bin/sh. You never know when a program might call it (although I agree it is almost always bad practice to use it -- use fork/exec instead.) So basically you should never make /bin/sh fish, because then you will no longer have a Unix system (according to POSIX).
  - hrktb 9y ago
    PHP somewhat takes the user’s login shell, so I guess it’s yet a different system. If it was taking /bin/sh it would have been fine actually.
    - TylerE 9y ago
mtkd 9y ago
... and if you're going to disrupt existing shells - why would you not use JS? (I don't care for JS, but it is the lingua franca du jour)

yjftsjthsd-h 9y ago

If you use the same shell interactively as you script in, then you only have to learn the one language.

jamesgeck0 9y ago
Except Oil has both POSIX compatibility and Oil. It's not much difference from Fish, where you can largely ignore the built-in scripting language and just write bash scripts if you'd like.
- yjftsjthsd-h 9y ago
  Yeah, with oil I agree. It appears that fish is sometimes incompatible, though; there's a comment down thread about 'Foo=bar baz' working differently, and I have actually used that interactively.

jhasse 9y ago

To copy and paste stuff from the internet.

partycoder 9y ago
That's a great argument for fish.
- jhasse 9y ago
  That you can't?
  - partycoder 9y ago
    Why not to copy and paste: 1) what you paste might not be exactly what you copied. i.e: http://thejh.net/misc/website-terminal-copy-paste http://thejh.net/misc/website-terminal-copy-paste 2) possible licensing issues 3) it enables cargo cult programming
    - jraph 9y ago
      For 1, my configuration of zsh solves the problem and avoids surprises by marking pasted shell code and letting me review it before running it, even if there are several lines. This is great for just pasting stuff from the internet and adapt as I wish without having to retype the entire thing or use an editor. I think this is a default behavior in oh-my-zsh. 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)
      - jraph 9y ago
        Okay, bracketed paste does not help against attacks.

LukeShu 9y ago

Why do people care about "COMPATIBILITY" so much w.r.t. C compilers? It's so easy to use other compilers to build your program. > 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.

aspaceman 9y ago
I'm very confused by your analogy. In the same way that I can hold onto a binary for /bin/bash, I can do the same for gcc-4.7 or whatever. If your software depends on a very specific version to remain compatible, you just keep that thing around which is precisely what the CC env variable is for. Eventually, you'll want to add / change / or update that software, and that's where it's nice that updated versions remain compatible so you don't have to rewrite everything in your codebase. 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.
- LukeShu 9y ago
  > I'm very confused by your analogy. In the same way that I can hold onto a binary for /bin/bash, I can do the same for gcc-4.7 or whatever. If your software depends on a very specific version to remain compatible, you just keep that thing around which is precisely what the CC env variable is for. Eventually, you'll want to add / change / or update that software, and that's where it's nice that updated versions remain compatible so you don't have to rewrite everything in your codebase. 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.

hrktb 9y ago

One of the werid cases with fish as default shell is scripts and programs that expect bash when executing “system” commands. For instance a php or Java program running shell commands. Having bash compatibility is a quality of life feature, no need to debug all the werid cases where it breaks for purely syntax reasons.

djsumdog 9y ago
That's just lazy programming, and if anything, we should have more incompatible shells so that developers will start to write their programs to stop shelling out and run individual programs, or if they do shell out, actually declare the shell you're using at that point and don't assume it will be sh compatible.
- deleted 9y ago
  [deleted]
Symmetry 9y ago
Personally I leave bash as my login shell and just set my terminal emulator to launch fish on startup.
chubot 9y ago
Right, the system() function in C, which PHP probably uses, and is os.system() in Python, is DEFINED to run /bin/sh. You never know when a program might call it (although I agree it is almost always bad practice to use it -- use fork/exec instead.) So basically you should never make /bin/sh fish, because then you will no longer have a Unix system (according to POSIX).
- hrktb 9y ago
  PHP somewhat takes the user’s login shell, so I guess it’s yet a different system. If it was taking /bin/sh it would have been fine actually.
  - TylerE 9y ago

mtkd 9y ago

... and if you're going to disrupt existing shells - why would you not use JS? (I don't care for JS, but it is the lingua franca du jour)