3 ms·

Good and well-thought shell language syntax (compared to ad-hoc hodgepodge of syntactic peculiarities of bash/zsh); reasonable defaults for the interactive shel

Good and well-thought shell language syntax (compared to ad-hoc hodgepodge of syntactic peculiarities of bash/zsh); reasonable defaults for the interactive shell. No other shell gives you this, for some reason.

hnlmorg 7y ago
> No other shell gives you this, for some reason. That's not true. There are a few other shells out there that do. The issue is the popular shells tend to be the ones that go for POSIX (or Bash) compatibility and those that do go for a syntax redesign (for example) often get criticised for not being POSIX compatible. There is comment further down in this discussion describing those syntax differences as "bugs" rather than "features"; which just goes to demonstrate how ingrained Bash et al are to Linux/UNIX command line users. Personally I see Fish and other non-POSIX shells like another programming language (arguably that's literally what they are). So switching from Bash to Fish - or whatever else - should be like switching from C++ to C#, Java, Rust, whatever. Sure there will be a lot of commonalities but it is the differences what makes the shift worthwhile. That all said, I can't blame people for preferring a POSIX or Bash compatible shell because that's what you'd expect to find on any Linux or UNIX system. Or at the very least a Bourne Shell (sh). Plus most documentation online will be tailored for compliant shells. However it does become a self-fulling prophecy where compliant shells are more widely used because they're already more widely used. I'm fine with this though. People who want to make the shift and learn something new can still do so under the knowledge that they're breaking from the norms and all the potential complications that might bring; and people who just want something that's universal and works - irrespective of it's warts - can continue to do so.
- atemerev 7y ago
  Yes, you are right. I believe that we software engineers should not dwell in such conservative states of mind and innovate and even break from standards when necessary. Bash and POSIX were good enough 30 years ago when they first appeared. Now they feel really dated.
  - yoloClin 7y ago
    I would _kill_ for a shell that returns bash-like data to stdout, but a JSON blob to pipes, or whatever the not-1970 concept of a pipe would be.
    - umanwizard 7y ago
      The shell isn’t in charge of what data commands print out.
      - yoloClin 7y ago
        True, but it's driven the method for output for a long time. If sh/bash exposed functions for objective output I'm sure a lot more utilities commonly in use would output in a similar methodology.
        umanwizard 7y ago
        No it hasn’t. The shell isn’t involved at all in program output. When a program writes to stdout it’s talking directly to the kernel, and the shell is suspended and not running.
        yoloClin 7y ago
        I don't really care what outputs the data I see. I care about how it's formatted and whether that format is easily readable + usable by consuming utilities. I don't understand why your being standoffish over a technicality.
        umanwizard 7y ago
        Okay, that’s fine. I think it would be nice for an OS to have a set of utilities that communicate with each other with objects instead of text. So I agree with you. I’m just pointing out that this has literally zero whatsoever to do with the shell. You posted it as a comment in an article involving a choice of shells. How am I being standoffish?
einpoklum 7y ago
Can you give a couple of examples (and I mean - things I might actually type in an interactive shell)?
- duckerude 7y ago
  As much as possible, syntax looks like shell commands, and blocks uniformly end with `end`. You don't get the messy inconsistency of sh where functions use braces and conditionals use ALGOL-style `fi` and `esac` and loops use `done`. Beyond that, some control structures even support flags: if you want to read up on function definition you can run `function --help`, and if you want to define a function `foo` that completes like `git` you define it with `function foo --wraps=git; ...; end`. That means you have to keep less in your head. A lot of things are even defined as ordinary fish functions. In sh, aliases are a dark and evil feature that hooks into the parser and can be used to create rudimentary macros. They have some really surprising behavior. But in fish, `alias` is a shell function and you can get the complete source code on your screen by running `type alias`. It doesn't do any evil things because it can only do things you could do yourself. Fish has sensible variables and arrays. All variables can be arrays. When unquoted, variables expand like "$@" in sh, so packing multiple arguments inside a variable is trivial and there's no need to worry about whitespace. Command output splits on newlines, which means that things like `for file in (find . -iname 'foo')` just work, assuming you don't have newlines in your filenames. Writing one-liners in fish makes me much less anxious then doing so in sh.

hnlmorg 7y ago

> No other shell gives you this, for some reason. That's not true. There are a few other shells out there that do. The issue is the popular shells tend to be the ones that go for POSIX (or Bash) compatibility and those that do go for a syntax redesign (for example) often get criticised for not being POSIX compatible. There is comment further down in this discussion describing those syntax differences as "bugs" rather than "features"; which just goes to demonstrate how ingrained Bash et al are to Linux/UNIX command line users. Personally I see Fish and other non-POSIX shells like another programming language (arguably that's literally what they are). So switching from Bash to Fish - or whatever else - should be like switching from C++ to C#, Java, Rust, whatever. Sure there will be a lot of commonalities but it is the differences what makes the shift worthwhile. That all said, I can't blame people for preferring a POSIX or Bash compatible shell because that's what you'd expect to find on any Linux or UNIX system. Or at the very least a Bourne Shell (sh). Plus most documentation online will be tailored for compliant shells. However it does become a self-fulling prophecy where compliant shells are more widely used because they're already more widely used. I'm fine with this though. People who want to make the shift and learn something new can still do so under the knowledge that they're breaking from the norms and all the potential complications that might bring; and people who just want something that's universal and works - irrespective of it's warts - can continue to do so.

atemerev 7y ago
Yes, you are right. I believe that we software engineers should not dwell in such conservative states of mind and innovate and even break from standards when necessary. Bash and POSIX were good enough 30 years ago when they first appeared. Now they feel really dated.
- yoloClin 7y ago
  I would _kill_ for a shell that returns bash-like data to stdout, but a JSON blob to pipes, or whatever the not-1970 concept of a pipe would be.
  - umanwizard 7y ago
    The shell isn’t in charge of what data commands print out.
    - yoloClin 7y ago
      True, but it's driven the method for output for a long time. If sh/bash exposed functions for objective output I'm sure a lot more utilities commonly in use would output in a similar methodology.
      - umanwizard 7y ago
        No it hasn’t. The shell isn’t involved at all in program output. When a program writes to stdout it’s talking directly to the kernel, and the shell is suspended and not running.
        yoloClin 7y ago
        I don't really care what outputs the data I see. I care about how it's formatted and whether that format is easily readable + usable by consuming utilities. I don't understand why your being standoffish over a technicality.
        umanwizard 7y ago
        Okay, that’s fine. I think it would be nice for an OS to have a set of utilities that communicate with each other with objects instead of text. So I agree with you. I’m just pointing out that this has literally zero whatsoever to do with the shell. You posted it as a comment in an article involving a choice of shells. How am I being standoffish?

einpoklum 7y ago

Can you give a couple of examples (and I mean - things I might actually type in an interactive shell)?

duckerude 7y ago
As much as possible, syntax looks like shell commands, and blocks uniformly end with `end`. You don't get the messy inconsistency of sh where functions use braces and conditionals use ALGOL-style `fi` and `esac` and loops use `done`. Beyond that, some control structures even support flags: if you want to read up on function definition you can run `function --help`, and if you want to define a function `foo` that completes like `git` you define it with `function foo --wraps=git; ...; end`. That means you have to keep less in your head. A lot of things are even defined as ordinary fish functions. In sh, aliases are a dark and evil feature that hooks into the parser and can be used to create rudimentary macros. They have some really surprising behavior. But in fish, `alias` is a shell function and you can get the complete source code on your screen by running `type alias`. It doesn't do any evil things because it can only do things you could do yourself. Fish has sensible variables and arrays. All variables can be arrays. When unquoted, variables expand like "$@" in sh, so packing multiple arguments inside a variable is trivial and there's no need to worry about whitespace. Command output splits on newlines, which means that things like `for file in (find . -iname 'foo')` just work, assuming you don't have newlines in your filenames. Writing one-liners in fish makes me much less anxious then doing so in sh.