[HN Gopher] Nsh: A fish/bash-like Posix shell in Rust
       ___________________________________________________________________
        
       Nsh: A fish/bash-like Posix shell in Rust
        
       Author : Klasiaster
       Score  : 153 points
       Date   : 2021-10-23 10:49 UTC (12 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | bscphil wrote:
       | > I don't need customizability
       | 
       | Configuration isn't for you. It's for other people. Configuration
       | is the part of a program that performs the function of making it
       | useful for more than one person. It is the necessary glue that
       | brings together many developers and many users into one project.
        
         | preseinger wrote:
         | Software that requires configuration to be useful to more than
         | one person has failed it's mandate in proportion to that
         | configurability. It's precisely the opposite of necessary glue,
         | it's duct tape: often the pragmatic choice, but almost always a
         | sign of a design failure.
        
           | laumars wrote:
           | What utter tosh. People have different preferences because
           | people are different. If your point was apt then this
           | submission wouldn't exist because $SHELL wouldn't be a
           | configurable option in the first place.
        
       | ridiculous_fish wrote:
       | Nice! I see nsh uses threads internally. Any plans on how to
       | handle the fork-thread interaction?
        
       | cogburnd02 wrote:
       | Just a heads up: name collision with the default shell on (now
       | Apache) Nuttx.
       | 
       | http://nuttx.incubator.apache.org/docs/latest/applications/n...
        
       | Klasiaster wrote:
       | There is also https://github.com/nixpulvis/oursh which wants to
       | be POSIX compatible with its own extensions. Actually I would
       | prefer if a new shell focuses on bash compatibility.
       | 
       | If features are integrated, then I would probably want to have
       | something about error handling because it is difficult to get
       | right in bash even with shellcheck1 plus shellharden2, and gets
       | just worse when things run in parallel.
       | 
       | 1 https://www.shellcheck.net/
       | 
       | 2 https://github.com/anordal/shellharden
        
       | socialdemocrat wrote:
       | I have used fish for years, it is just painful to watch how other
       | people work with old fashion shells.
       | 
       | I applaud this project for bringing fish goodness to more people,
       | although I don't quite get why people cannot just learn fish.
       | Fish is very simple. There is not that much to learn.
       | 
       | Maybe it matters if your write a lot of shell scripts but for
       | anything complicated I use Julia, Python, Go or some other more
       | proper language.
       | 
       | To me shells are mainly for interactive work and really simple
       | scripts without control flow, beyond perhaps a for loop.
        
         | jokethrowaway wrote:
         | I've used fish in the last few years and zsh before that.
         | 
         | The experience out of the box (coupled with something like
         | starship) is pretty good but I don't like the incompatibility
         | with basic things, like $() vs ().
         | 
         | I also find fish to be a bit on the slow side in some
         | instances, so I think I'll keep tabs on nsh
        
         | vmladenov wrote:
         | As someone who stopped using fish, I found fzf to be more
         | useful than fish's history completion so it became less
         | tolerable to have to type `env` in front of the bash oneliners
         | our test runner puts out.
        
           | ridiculous_fish wrote:
           | Just noting that fish supports the `var=val cmd` syntax
           | starting in 3.1, so `env` shouldn't be necessary.
        
             | pxc wrote:
             | how did I miss this??? I've been continuing to use the env
             | command for this for more than a year now
             | 
             | womp womp
        
       | mongol wrote:
       | > Fish is really neat but I prefer old-fashioned, traditional,
       | and ergonomic shell syntax.
       | 
       | What does this really mean? Especially the ergonomic part?
        
         | adrian_b wrote:
         | I do not know what was meant, but for example when I have
         | looked at fish, I have seen some features that appeared to be
         | nice, but also some gratuitous changes to the core shell syntax
         | that were not improvements.
         | 
         | For example, replacing "&&" and "||" with "and" and "or", is
         | not an improvement. There are many other such changes that make
         | the shell more verbose without bringing any advantage.
         | 
         | This also happened with the C shell, csh, which introduced some
         | convenient new features for interactive use, but it also
         | included a large number of gratuitous changes in the syntax
         | that were not improvements.
        
           | pxc wrote:
           | > some gratuitous changes to the core shell syntax that were
           | not improvements
           | 
           | > For example, replacing "&&" and "||" with "and" and "or",
           | is not an improvement. There are many other such changes that
           | make the shell more verbose without bringing any advantage.
           | 
           | In Fish, `and` was never a synonym for `&&`, and `or` was
           | never a synonym for `||`. Fish's use of `and` and `or` also
           | did not introduce any syntax that you won't find in Bash and
           | friends. `and` and `or` in Fish are _commands_, and they use
           | the _pre-existing syntax_ for _normal commands_.
           | 
           | This is absolutely an improvement, because it's _strictly
           | less syntax_ that allows you to do all of the same things
           | with virtually no increase in the number of characters. `;
           | or` is only a single character more than ` ||`, and `;or` is
           | the same number of characters as ` ||`. This is a very bad
           | example of 'increased verbosity'.
        
           | ChrisSD wrote:
           | I find typing `&&` to be annoyingly difficult. I have to hold
           | shift and hunt around for the `7` key (and probably hit `6`
           | or `8` first). Whereas I can type "and" without looking or
           | even really thinking about it.
        
           | ridiculous_fish wrote:
           | Note fish supports "&&" and "||" as of version 3.0
        
       | shomyo wrote:
       | Wow! Another piece of software written in Rust with hobby-level
       | of usability.
        
       | agluszak wrote:
       | The name sounds very similar to Nushell[1], also written in Rust,
       | but more mature and recognizable
       | 
       | 1: https://www.nushell.sh/
        
       | yewenjie wrote:
       | Very cool. I really love fish but sometimes find it very annoying
       | to translate random posix snippets from the web.
        
         | AYBABTME wrote:
         | The trick is to enter bash from fish, run your command, and
         | then call fish again.                   (fish)$ bash
         | (fish>bash)$ source ./random.sh         (fish>bash)$ fish
         | (fish>bash>fish)$
        
           | sjmulder wrote:
           | Would it be better to 'exec' the shells to avoid the nesting?
        
           | jpambrun wrote:
           | I think you should hit ctrl+d when you are done in bash to
           | avoid the nested fish>bash>fish.
        
             | AYBABTME wrote:
             | The idea is to return to a fish shell, but with all the
             | env-vars that bash might have loaded as a result of
             | executing the script.
        
           | R0flcopt3r wrote:
           | Or just simply:                   (fish)$ bash -c ./random.sh
        
             | AYBABTME wrote:
             | That doesn't give you the env vars that the script might
             | have set.
        
               | pxc wrote:
               | You can use fenv or bass for that. They run a snippet or
               | script of bash in bash, then import all the environment
               | changes for you
               | 
               | https://github.com/oh-my-fish/plugin-foreign-env
               | 
               | https://github.com/edc/bass
        
               | stjohnswarts wrote:
               | could you explain this? How could the script set env vars
               | before you run it??
        
             | gnubison wrote:
             | No need to use -c there:                   (fish)$ bash
             | random.sh
        
         | socialdemocrat wrote:
         | Unless it is really simple stuff why not just drop temporarily
         | into bash?
         | 
         | I mainly use fish for interactive work not for programming.
         | Then I use a real programming language.
        
         | rgoulter wrote:
         | Have you made use of tools like babelfish?
         | https://github.com/bouk/babelfish
        
       | implfuture wrote:
       | Will this support native windows? The main reason I have switched
       | to nushell is because it is cross platform
        
       | HMH wrote:
       | Looks like the goal of this project is to be a replacement for
       | bash with improved interactivity. That seems reasonable, compared
       | to what you can do with zsh or fish bash is far behind concerning
       | interactivity.
       | 
       | While I personally think shells that abandon POSIX/bash
       | compliance are much more interesting as those can implement a
       | sane scripting language, sticking with bash but improving
       | interactivity is probably going to make more users happy as bash
       | is so ubiquitous.
        
         | sprash wrote:
         | > bash is far behind concerning interactivity.
         | 
         | Is it really? Projects like ble.sh [1] seem to pull off
         | advanced features like syntax highlighting and enhanced
         | completion with pure bash without the need for reimplementing a
         | whole shell from the ground up.
         | 
         | 1.: https://github.com/akinomyoga/ble.sh
        
           | qqii wrote:
           | Wow, that looks amazing! Especially being implemented in pure
           | bash!
        
           | icarusmad wrote:
           | Bash and Fish aren't written in Rust, so they'll be behind
           | Nsh as long as they aren't written in Rust. /s
        
       | hnlmorg wrote:
       | This project looks very young. It might evolve into a contender
       | but even the document on Bash compatibility just says "TODO" and
       | frankly Bash compatibility is going to be a multi-year project on
       | its own.
       | 
       | For anyone after an upgrade path from Bash/Zsh then Oil shell is
       | a lot more mature: https://www.oilshell.org/
        
       ___________________________________________________________________
       (page generated 2021-10-23 23:01 UTC)