Hacker News Reader

Comment by j1elo | Hacker News Reader

Thinking this is so cool! I was wondering if seriously buying into an alternate shell like this would be worth it in the long run.

Would really love to read from people who use(d) an alternative shell, both success and failure stories.

I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work because you'd then be introducing an implicit dependency on your special snowflake non-standard runtime. Which is something we came to accept and assume for interpreted languages (Python, Ruby, Node, etc.) but I'm not yet ready to assume for shell scripts.

So right when I was going to test Nushell, I discover there are also other shells like Elvish [0] and Oil which supports structured data [1]. Now on top of my hesitations I'm adding decision paralysis :-]

[0]: https://elv.sh/

[1]: https://www.oilshell.org/

Lots more shells: https://github.com/oilshell/oil/wiki/Alternative-Shells

View on HN

I wouldn’t use a custom shell in company work, but I’d use it for company work. I treat custom shells like a custom keyboard or shortcuts in the OS. Shells can help a lot in your day to day command line ergonomics, like presentation (always know which branch and directory I’m on, time and time taken for commands) and ease of use (autocomplete, aliases, shortcuts). But I wouldn’t script into them for professional work. Just plain bash in that case. We really don’t want devs fighting over which shell to install on the servers, but everyone can go crazy on their own laptops.

I agree... and any well written script will have a shebang that specifies the shell that shluld run it, anyway.

For me, personally, I love having homogeneus systems put in place. In this case it means not having to switch my mind between in and for modes. Helps me avoid mistakes, having to keep less context up here. But it's always interesting to read about other people's way of working.

If you want to make the systems homogeneous, then you need homogeneous teams, too. Maybe some team members prefer fish, others prefer zsh, still others prefer bash. Your suggestion means that everyone has to use the same shell for their command line.

I find that it is better to allow each team member to have their own working environment: different (command line) shell, different editors/IDEs, different keyboard shortcuts. But everyone uses the same programming languages (counting shell as a programming language for scripts here) and the same build tools and the same linters.

no no no, I meant that I prefer using Bash everywhere, including my own machine, because anyway I'll need to end up translating most stuff I write to a Bash or even POSIX compatible script so... as someone said in other comment, why not cut the intermediary step. It makes it easier for me, the less context switches the better production code I'll produce.

But of course, I believe others should be free to make their own choices! As long as their choices don't end up affecting the quality of the code that ends up shared with the rest of the team...

Which brings an interesting point: I don't have a problem at all with you using whatever shell you want. But I do have a problem if because you don't use Bash in your day to day, you are less used to its ins and outs, you don't put in the extra work that is being as proficient with Bash than you are with your personal shell, and your scripts end up with bugs in how Bash arrays are treated (just a quickly made up example)

I understand your point about being able to write proper bash scripts. On the one hand, I never use Java as my shell, but I am able to write proper Java programs just fine; why should bash be different?

On the other hand, I've been using Bourne-ish shells (mostly bash with short bouts of zsh) for twenty-plus years and I have no clue about arrays. (I know the difference between "$@" and "$*" (including the quotes), but that's it.) Now I have been using fish for a year or so, and I also have no clue about arrays in fish... :-)

Yup. There are more shells than there are IDEs, keyboard switch types, keyboard layouts, and operating systems. Shell ideological wars get just as bad as emacs/vim and linux/Mac. Use whatever you want, but company IP is shbang'd to bash.

> shbang'd to bash.

Good.

Better: #!/bin/sh

Best: #!/bin/sh and also not assuming bash anyway!

I wouldn't say putting a sh shebang and assuming bash is better. With a bash shebang at least you're honest about it.

Well yes, absolutely. I phrased that poorly, what I meant was like '/bin/sh is better... Especially if it actually works' or something.

It's easily done though, I've often thought I've written something POSIX compatible and then had shellcheck say nope.

Best would actually be

#!/usr/bin/env sh

Since this binary is required by the POSIX standard to exist at that location.

Oh and how /bin/bash is bash3 on macOS instead of the contemporary bash5 by default. And how sh is dash on Debian, or Ubuntu, I forgot. Some of the reasons why I would prefer python3 scripts (or perl) over sh or bash

Pretty annoying to reliably #! to python3 as well. Is it /usr/bin/python or python3?

That's my worst. I think generally python3 is safe (if unnecessary) today? But for how long do we have to keep that around?

Can we now say Well python2 is EOL so python should certainly be v3+?

It is of course a more general issue with shebangs that it's a very loose 'dynamically linked' coupling, not necessarily judt affecting language version but environment/libraries too, it just seems particularly problematic or prevalent with python.

/usr/bin/env python3

That's not the point - 'or /usr/bin/env python?'

"It's complicated": https://www.python.org/dev/peps/pep-0394/#for-python-script-...

If we're distributing software, maybe? Personally we control the hardware, so we know what we're running, but yeah, for libraries or packages this makes sense.

I'm generally supportive of the effort to replace the archaic shells that dominate the unix landscape, but unfortunately none have yet met my personal desires.

It seems like a lot of the developers of these shells create them to supplement the common unix toolset, but I really want a complete replacement. Ideally, the shell itself would be a completely dependency-free static executable, with a built-in command set that includes functions to interface with all the kernel's user space accessible features, acts as a repl, with sensibly named commands, and a simple method for interfacing to and from any other program. In short, I guess I'm looking for something to act as the basis of a completely new environment on top of Linux. As it is, most of these do not even meet the first of the criteria.

FWIW, nushell is much more of this than it appears. While many commands share names with Unix commands, that is the only similarity for quite a few, since they are rewritten to return structured data instead of text.

From what I recall about nushell, it only scores 2/5 of my criteria.

Right, it’s still very early and something needing to be contributed to. However I have spoken to the creator (regretfully I haven’t had as much time to contribute as I would’ve liked); he is very open to improvements and the direction of the project is pretty open.

So I take it you're waiting for the systemd shell then? lol

I tried fish for a while. The differing syntax between fish and bash for fundamental things mean I was running all my scripts through bash anyway, and if I wanted to share them/use them elsewhere in the company it had to be bash, so I swapped back to bash.

If you're running scripts, what difference does it make that you use fish? You're not really supposed to write scripts for fish, unless it is meant to be used be the fish shell itself. A shebang on the top of your script will invoke the script with the right executable, and whether you called it from bash, zsh or fish would make no difference.

So, instead of just typing shell commands, you type something else, but as soon as you need a shell script, you have to go back to shell commands.... Why not just cut out the middleman?

Answer to the first question: yes. Answer to the second question: because bash is a rather poor terminal shell.

In my experience, the middleman you mention doesn't exist. Or, if anything, it is a very tiny man that hardly gets in the way. It's either a one-liner with a syntax change you can pick up in 5 minutes, or it falls under any combination of these:

- might as well belong in a script

- the complicated stuff is in awk or the likes

- you can just enter bash for any copy-pasted bashisms

- you can execute it explicitly with bash -c

In any case, none enough of a hassle that it could demerit the immense productivity benefit I've gotten from fish. The only regret I have on that matter is not having ditched it sooner. Use bash to run scripts, or even better, sh. Use a different shell to make your life on the terminal better. Doesn't need to be fish, zsh is pretty good too.

If I can offer any advice: if you still want to stick with bash, at the very least take a look at fzf, https://github.com/junegunn/fzf , aside from fish/zsh it's the best and most lowest hanging fruit.

I personally use zsh, bash is too primitive with regards to its user interface (line editing, searching, vi keys, etc.) The syntax however is my key point here, I often take my commands and smack them into Makefiles for example.

> You're not really supposed to write scripts for fish

Given that 95% of my time in a shell is running a script, a shell that doesn't do that well isn't a great fit for me.

> A shebang on the top of your script will invoke the script with the right executable,

Assuming the person who wrote it had the foresight to do so. That person isn't always me, and if I have to manually check if each script I run has a shebang, I should just default to running them in bash.

I haven’t seen a shell script in ages that was missing the shebang. Is this common in some places?

I’ve started to write dash scripts because that seems to be reasonably posix and bash on macOS is ancient.

I don’t think I’ve ever seen a script written without the shebang.

Btw, you can get around the ancient bash in macOS by installing a more modern bash and invoking with /usr/bin/env bash as your shebang. Not sure if that’s a great idea, mind you, but if you’re already writing scripts in something non-portable, it’s an option.

There are hundreds of sh files on github that don't have a shebang. Just because you don't write them and your colleagues don't doesn't mean they don't exist in the wild.

I didn’t mean to imply that they didn’t exist nor that it might not be important to account for them in some contexts. I meant only to convey my own personal experience: that it had never occurred to me that I might need to account for a missing shebang, since providing an interpreter for a script via shebang is all I have ever personally encountered.

wait how does the OS even invoke an interpreter without a shebang? If you have to explicitly call an interpreter when you invoke it, then it's no extra work to call

    bash some_script.sh

anyway

As I’ve learned in response to this thread, apparently some (but not all) Unixy OSes will run a file marked as executable using /bin/sh if no shebang is supplied.

Oh right, I think that's part of how APE[1] works. But I thought the Thompson shell was old and weird, and that it might not support what people use when they write ‘POSIX’ shell scripts nowadays.

Anyway it sounds like in that case the OS _doesn't_ know how to run the script, it just assumes `/bin/sh` will do.

I always assumed that scripts without an interpreter line were like snippets to be invoked via `source`, from some shell script with knowledge of the context in which it should be used.

Anyway, if that's the way it works, the behavior actually isn't a problem for users of Nushell or Elvish or Fish or anything else, since their executables are never installed to `/bin/sh` anyway. Nushell probably gets installed to `/usr/bin/nu`, Fish to `/usr/bin/fish`, and `elvish` can be installed anywhere. So it's still not clear that there's a real problem with un-shebanged scripts when it comes to using a boutique shell for login.

—

1: https://justine.lol/ape.html

Yeah thing $T _might_ (but probably won’t) happen, so the idea is automatically terrible.

Any random blog post that you find with instructions to run something in a shell that uses a variable just won't work copy and pasted, you now need to either modify them for your esoteric shell, or wrap them in a script to be ran through bash

I would consider a person who doesn't use a shebang to be bad at their jobs.

Even the most basic of tutorials will include it even if it means nothing to the user.

That's not entirely weird to me.

For the longest time bash was in various states of disrepair on different Unixes. I could make it segfault pretty easily.

I wrote scripts that had to run across Linux, BSD, HP-UX, Solaris, and AIX at the time. So we relied on a ksh88 implementation on each. Whether it was AT&T, mksh, or pdksh, it was fine. Couldn't rely on 93isms, but basically anything POSIX was cool.

I used ksh93 interactively for the longest time. But then Linuxes stopped testing interactive use w/ their packages and it became unusable (looking at you RedHat). So I used bash interactively but still wrote those ksh scripts.

These days, I use zsh locally on MacOS and BSD, but mostly write bash scripts for those and Linux. I still stick to the POSIX habits I have for portability. But the variances are so less. The only one that annoys me is the "does sed -i do in-place" game.

I don't think my interactive shell and target scripting shell have ever matched 1:1 in feature set. And what I slap together interactively or for 1-off script, I would never do for a "real" script. And that's a thing that bugs me with a lot of shell scripts I see in the wild.

A "real" script should make very little assumptions, fail safely, be low on resource utilization to not risk impacting a business workload, and be maintainable. I write everything real like it might be run thousands of times accross thousands of hosts. Even when I didn't intend for it to be, I've caught it in the wild because someone borrowed what I did.

I do love shellcheck, because it teaches our newer folks good habits and they're used to that kind of feedback in other languages. It catches so many things that make me cringe. It's not perfect, of course, but pretty great.

When I started out, I worked 9-6 and the Unix sages in my group worked later hours. So they'd walk through my work on the RCS host and I'd come into the morning with a critique in my email. If I didn't understand, I could hit their desk after lunch and they would patiently explain to me. I love them for it, but it is nice to have tools without a 24-hour feedback loop.

Shellcheck is nowadays a must for writing decent shell scripts. it is like a centralized knowledge base of all those brilliant minds that did the sanity checking for you in the old days :)

It boggles my mind that people use a language where

x = 0 doesn't work and x=$y is a security flaw

Sometimes it's easier to use tools you know will be available than to ensure your tool of choice will be available everywhere you need it to be. JavaScript, esp. pre v6, is another example that makes almost no sense when you ignore its ubiquity

> x = 0 doesn't work

Maybe it's just me, but I love how the assignment syntax can be used just for a single command: 'MANPAGER=cat man' is a lot nicer than '(MANPAGER = cat; man)'.

> and x=$y is a security flaw

When is variable assignment a security flaw?

if $y is untrusted input then you need to quote it or you've introduced shell injection attack to the script.

You don't need to quote variables on the right hand side of an assignment.

I used fishshell for years, and the bottom line ended up being that it created enough mental overhead to be a burden because it diverged from the UNIX norm too much. Sort of like the colemak keyboard layout, sounds great in theory, in practice, not so much.

Fish user here. I've accepted having to drop down to bash here and there. No big deal for me.

I tried fish for a short while too and quickly realized everything depends on bash/dash. I then switched to zsh which is mostly compatible. I installed Oh My Zsh and a fish-inspired theme with line autocompletion and coloring and never looked back. But I still use zsh for the interactive prompt only, still writiiing #!/bin/sh scripts for maximum compatibility between platforms.

I went through the same thing.

It also got on my nerves that scripts which did not identify themselves correctly as bash would run in [ whatever hot new shell im running ], often with bizarre results.

I don't know if fish counts as an alternative shell since it is still pretty close to bash and zsh, just with better defaults requiring less configuration (similar to i3wm with respect to "better defaults").

I just use it as interactive shell and for scripts I use `/bin/sh`. So I don't really run into a lot of problems, only sometimes with scripts that do not have a proper `#!/path/to/shell` declaration at the top.

("better defaults" is of course entirely subjective but for fish, i3 and Doom Emacs they mostly align with my preferences)

I’ve been poking around with Sway, coming from Gnome (which I mostly love). What got you into i3 vs a normal desktop, and how long did it take you to realize it was a good fit?

Phew, I've been using tiling window managers for 15+ years now so I don't really know. I've always been interested in trying out different window managers and UI/UX concepts.

When I started with Linux in the 90's it had FVWM by default as graphical interface which was pretty different when being used to Amiga, Atari ST and Windows 3.1. (They were all pretty different from each other.)

Of course I had to run Enlightenment with some rusty graphics when I discovered it, but I think WM2/WMX[1] was the first window manager where I realized I preferred the more minimalistic ones.

After trying out more WMs I ended up at awesome[2] which I ran for years. It had the best support for both floating and tiling windows. (I do like some floating windows now and then but never liked the "normal" desktop concept which is, paraphrasing Fred Brooks, more of a flight seat concept.)

Then WMs like xmonad started appearing and I tried those out but they're pretty much "tiling only" and I did not like xmonad's tiling windows approach. It's been too long since I used it and I'm not sure it is still applicable but it forced you to use specific layouts and the current window was always maximized.

So at some point i3 appeared (like fish shell and Doom Emacs) and when trying it out it by default already did most of the things that I liked and that I had to configure in other window managers, so that was nice. It was a pretty good fit right away.

I have used some other WMs like EXWM and StumpWM over the years because I'm both an Emacs and Lisp weeny but they're like less mature i3 clones so I've been back at i3 for a while now.

[1] http://www.xwinman.org/wm2.php

[2] https://awesomewm.org/

I've been using Xonsh[0] for a couple years as my daily driver and I swear by it. I'm also a Python dev so that's part of the appeal. It's billed as the "unholy union" of Bash and Python.

[0] https://xon.sh

Xonsh is also my daily driver for years and years. Combined with direnv I have really not missed much of anything from other shells. So much stuff either works out of the box or has some little hacky wrapper to handle it.

Yup. I'm a huge fan of the vox plugin approach to python and venv management. No more virtualenv hacking the shell... it's a first-class citizen. Plays nice with pyenv too

This sounds nice enough that I'm considering installing xonsh just for python development

use it as an interactive shell first, not for shell scripts.

also, why would any dependency of your projects at work be implicit? all dependencies should be captured somehow, the very least in some documentation.

at our company, we use shell.nix files to declare all of our dependencies, so everyone has the exact same software available on their development workstations.

it's not a completely trivial thing to do, but worth investing into it, to lower the chance of surprises, which will happen when you can afford them the least...

here is an example to get started:

``` with import (builtins.fetchTarball { name = "nixos-unstable-on-2021-05-16"; url = "https://releases.nixos.org/nixos/unstable/nixos-21.05pre2893... sha256 = "1kilrk0ipvldf4rrn6aq6v2bj2jfhbz33cjb9w9ngqmbmr2f94wd"; }) { };

let project-jdk = jdk11; clojure = callPackage ./deps/clojure { jdk11 = project-jdk; };

in mkShell rec { buildInputs = [ coreutils cacert direnv nixfmt curl jwt-cli fd python3 nodejs (yarn.override { nodejs = nodejs; }) project-jdk clojure yaml2json

    modd
    devd
    overmind
  ];

  shellHook = ''
    export LC_CTYPE="UTF-8" # so tar and rlwrap won't complain
  '';

} ```

it shows how u would use your custom package (for clojure in our case) and how would u pin there state of the whole package repository to a specific point in time.

in the past I've used es, the extensible shell (https://wryun.github.io/es-shell/), this way, without bothering my colleagues with teaching them about it. they just git pull, press enter in a shell within the hour repo and direnv will pull down any new dependencies.

> also, why would any dependency of your projects at work be implicit? all dependencies should be captured somehow, the very least in some documentation. .... Nix.

Because distributing software is hard, especially if things change. That's one big reason why Docker images will sometimes get used for development environments (like what VSCode supports).

Nix is nice, and is a pretty good way of capturing those dependencies. But it's also difficult to customise, often lacking in documentation, and not used very widely.

If you're not using something like Nix (i.e. most people), it's natural for dependencies to be quite implicit.

I understand that the industry largely does not acknowledge how big of a problem implicit dependencies are, but since the OP is clearly aware of some issues with implicit dependencies, I was just surprised why so content with these issues. It clearly hinders the adoption of upcoming technologies at least in the mind of the OP.

I'm not really an expert in the Nix expression language. Hasn't even finished reading the Nix pills, which is a very practical documentation, yet I could manage to extract a lot of benefit from that shell.nix template I've shared. I'm using Nix for 3+ years now. Because of this experience I do encourage others not to be afraid trying Nix. It gets better with every release.

Docker is a halfway solution and because of its memory and storage requirements it often strains the average development workstations and internet connections.

Perhaps someone already mentioned this elsewhere, but nothing forces you to use only a single shell. A shell, after all, is just a running process. Yoh can even launch it from another shell.

As a GNU screen user already, I can imaginr having one of my default windows that load when I launch screen be nushell if I was so inclined. I can keep the rest as my default (e.g., bash or htop or whatever else I wany running there).

There is something very important that forces me to use a single shell: Habit.

I tried and returned to Bash. There is something about using defaults.

> I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work because you'd then be introducing an implicit dependency on your special snowflake non-standard runtime. Which is something we came to accept and assume for interpreted languages (Python, Ruby, Node, etc.) but I'm not yet ready to assume for shell scripts.

Is it so bad? I run arch at home, I would never do that for a production server. I use rust at home, but it's unlikely to get introduced at my work any time soon. I use elm for solo projects, and I've never once convinced my managers to even try it (and believe me, I tried).

Context switching is pretty normal, I wouldn't let that get in the way of trying something new and interesting. Personally I find elv.sh the sanest scripting language I've tried so far, and I wouldn't trade it back in for bash, even if I'm still forced to use it at work.

A case for trying Elvish:

I really like Elvish's emphasis on interactivity, its somewhat maximalist approach to interactivity-oriented builtins (like fuzzy filtering, its directory browser, etc.), and the fact that it's distributed as a single static executable.

I also like the developers, who are smart and kind people and generally pretty pleasant to interact with on GitHub or their Telegram chat (bridged to various other things).

None of this is a case against trying Oil, however, so perhaps it will not help your paralysis too much. ;)

NGS' readme also has a good comparison section listing alternative shells: https://github.com/ngs-lang/ngs#have-you-heard-of-project-x-...

You might be interested in chubots comments as he regularly responds to questions related to oilshell:

https://news.ycombinator.com/threads?id=chubot

> Which is something we came to accept and assume for interpreted languages (Python, Ruby, Node, etc.)

Tangential, but:

- "Node" isn't a language, it's a JS runtime

- There's no such thing as an "interpreted language", whether something is interpreted or not is a property of the execution environment, not of the language itself

- The commonly-used runtimes for JS at least are JIT compilers, not "interpreters", and this can be true for some Python/Ruby runtimes too

I didn't downvote your comment. But I guess some people did, possibly because you did the thing about stating several facts where all were true but none were relevant. I'd swear I read that this phenomenon even has a proper name but cannot recall it right now.

(And for the record I know very well about the internals and technicalities about the words and names that I used: Node.js is the de-facto Javascript runtime for the backend, popular to the point that people commonly refer to it as "programming in Node"; Python and Ruby are just languages but their majority of users run their program with the default official interpreter, so through a metonymy we can refer to either even when actually talking of the other; and etc. For economy of the language and avoiding the pedantry, I grounded my comment on the most generally perceived notion about those technologies. You see, just to avoid unnecessarily long explanations like this one)

I use the fish shell and have for several years now.

A few years back I did a startup with a friend -- a cross platform mobile product but with a mess of complex open-source c++ dependencies (which we forked and customized often) -- and we made the decision as we hired developers to over-specify some aspects of the machine environment to make it as easy as possible to share our development workflows. Note that "development workflow" is much more than just "i can run the app in docker" -- but rightfully includes -- I can efficiently run things in debugger, I can run the performance profiling tools in realistic ways, I can quickly execute and test a change someone else is trying to make, I can quickly share a change I'm making with someone else and be confident they can make realistic observations about it, i can setup a fast repro loop for some specific bug or feature ... etc.

We did a pretty good job of getting the know now needed for all those workflows distributed across the team reliably with low effort despite some complicated and weird build system requirements associated with our dependencies.

One of the big bang for buck tricks that helped more than I would've expected was to mandate that everyone had to use fish shell. This really reduces the number of weird effects from random things that people copy/paste into their bash initialization -- with the developer never imagining the strange knock off effects that will one day cause a tool they don't understand to behave in a flaky way for a reason they will never figure out ...

The amount of terrible things that developers randomly accumulate in their bash initialization probably can't be underestimated ... there's probably more risk of "weird problems" associated with advice on stack overflow related to bash initialization than maybe any other topic ...

So I personally think standardizing a team or startup on an alt shell can be a potentially good idea ...

As another point of evidence -- I later headed devops at another startup that took opposite perspective -- "use your own machine and your machine can be configured however you want and you just have to figure out dev workflows on your own" and it was extremely difficult to share knowledge about how to accomplish a lot of these basic workflows ... doing anything beyond the most basic ways of interacting with the codebase often involved a rather large amount of hands on dev machine troubleshooting (can you send me your .bashrc and .profile and .bash_profile? ok type these commands ... ok now you can grab my branch and try this to have a look at the thing i'm trying to change ...)

fish is reliable and stable though -- I'm not sure about using a shell that's not been around for awhile in this way ... but I'd support it I think if I already had personal experience that the shell was "reliable enough" ...

Reply on news.ycombinator.com