6 ms·

I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. I'm a huge fan of the f

I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. I'm a huge fan of the fish shell, but in the real world, it never seems to be installed across the farm, and convincing the older SysAdmins to install it is more trouble than it's worth. We should be focusing on saner bash defaults, since it's the most common shell in use. We shouldn't have to remember these large list of gotchas, and pitfalls that shouldn't be there in the first place. A few people out there are trying to recreate common utilities such as ls or cp, and while I welcome the change, I feel it should be part of the actual gnu coreutils package, and not a new project: https://bsago.me/exa/ https://bsago.me/exa/

txutxu 10y ago
If it's hard to try to convince them about fish... try to convince them to enter commands in a browser over a web stack, as a "shell". If they are conscious about the parts involved and the security repercussion, maybe they will say the same: "no". On the other side, technology is not advanced only by older SysAdmins, and it's nice to see new projects, experiments and developments.
- jandrese 10y ago
  > try to convince them to enter commands in a browser over a web stack, as a "shell". What? I had never heard of fish before and this is making me nop out pretty quickly.
  - mastax 10y ago
    Fish is not web based. I think he's referring to the browser ui in the OP.
nailer 10y ago
That's because fish is a better version of existing shells. It's not significantly different to throw away what we have. Sane syntax and proper colors and better autocomplete make it better than bash, but not enough to throw away the network effects of bash. Think of hg trying to compete with git - it might be better, but it's not better enough. As a shell person (I'm the maintainer of https://certsimple.com/rosetta-stone https://certsimple.com/rosetta-stone) NGS offers: 1. non blocking 2. structured results Doing both of those - if NGS can do it - is a MASSIVE shift over existing Unix shells. Think git replacing svn. The POC for #1 looks really good: https://www.youtube.com/watch?v=T5Bpu4thVNo https://www.youtube.com/watch?v=T5Bpu4thVNo
- lfowles 10y ago
  Personally, I use fish as my interactive shell. Bash still exists in the background for purposes of _the whole world runs on it_.
  - zyxley 10y ago
    Same here.
    - qorrect 10y ago
      Same here too. Fish on all local machines, bash on AWS instances, and all scripts written in bash, simply for compatibility.
oblio 10y ago
We should be focusing on saner bash defaults, since it's the most common shell in use. That kind of work is not glamorous and highly controversial. Ideally there should be some sort of cross distro/OS working group (Debian/Ubuntu, Red Hat, SUSE, FreeBSD, NetBSD, OpenBSD, Mac OS X, etc.), similar to the working groups that standardize the web, where such proposals can be made, voted on and adopted. For example there should be no reason in 2016 why a sane solution can't be found for having almost every bash installation recognize all keys on the keyboard (i.e. arrow keys wouldn't produce ^A sequences or similar). Another thing that would be sorely needed but would involve a much higher volume of work would be a template, at least for all GNU utils, which they use to define they options, parameters, arguments, whatever. And by "template" I mean library, actual working code they could include and configure. Instead of each shell (bash, zsh) having to come with a million small scripts that configure auto completion, these shells could just query the standard-compliant tool for its usage and would receive a standardized reply with everything. Powershell has something like this and it is a great idea.
- gioele 10y ago
  > That kind of work is not glamorous and highly controversial. Ideally there should be some sort of cross distro/OS working group (Debian/Ubuntu, Red Hat, SUSE, FreeBSD, NetBSD, OpenBSD, Mac OS X, etc.), similar to the working groups that standardize the web, where such proposals can be made, voted on and adopted. Like the Austin group, the technical committee that constantly releases updates to POSIX and the Single Unix Specification? http://www.opengroup.org/austin/ http://www.opengroup.org/austin/ http://pubs.opengroup.org/onlinepubs/9699919799/ http://pubs.opengroup.org/onlinepubs/9699919799/
  - oblio 10y ago
    Aren't those folks more "enterprise" oriented than "quality of life" oriented?
- iheartmemcache 10y ago
  I've been using -nix for almost 20 years. I've used everything from ksh on SunOS 2.6 (Solaris?? what's that) to oh-my-zsh (for 3 years, before happily graduating to oh-my-fish). I grew up on Slackware 6 waiting hours and hours for a 2.2 kernel build to finish. In high school, FreeBSD 4.3 kernel mods took up more time than booze and women. My 3 year puppy love for oh-my-zsh dimmed as I transitioned to a more sane, less emotional woman - oh-my-fish. I hate to admit it, but Microsoft just got it right with Powershell. Standardizing the convention with an intuitive Verb-Noun, the out of the box documentation with -examples, -full, etc goes into so much detail that if everyone used it, there wouldn't be any dumb "How does I move directory??" questions on Stackoverflow (well, there'd be less at least). Don't know a command? Show-Commands and type in 'network' to see what's available. Don't see it there? Go get a Powershell script (often offered by vendors like VMware and Citrix, making devop lives easier). I remember spending _weeks_ trying to get my dual-boot machine (FBSD / Win2k) Cygwin/msys setup to work well on my P3 600 at 12 or 13. Now I can just Feature install Bash and get a native binary. Let me say that again -- now, I can Feature install Bash on Windows jeeebus. QT is LGPL. CLR is open source. Visual Studio Community (basically Professional) is free (unless you need historical debugging then Ultimate's going to cost a lot). Satya + Meijers + Hanselman et al have made favor Microsoft so hard, despite being an active donor of the FSF. That GNUutils-with-autocomplete is real trivial to write, but since it's already in fish, I see no need to right it. :smug: [In all seriousness, I agree with you re: standards. Plan 9's interface standards semi-addressed that. But le sigh such is life.]
StreakyCobra 10y ago
Side note: https://github.com/supercrabtree/k https://github.com/supercrabtree/k is a ZSH plugin in the same register that `exa`.
xomateix 10y ago
Relevant xkcd: https://xkcd.com/927/ https://xkcd.com/927/
js2 10y ago
older SysAdmins I hope you aren't referring to their age, in which case consider using a different adjective: experienced, seasoned, wiser, etc. Your colleagues probably don't want to install fish shell for reasons besides how old they are.
- gervase 10y ago
  Or, if you disagree with their opinion: hidebound, closeminded, timorous, etc. I think the parent was going for something indicating disagreement, so it seems unlikely that your "positive" adjectives are what they were looking for.
  - js2 10y ago
    I've been on both sides of the equation, having disagreed with sysadmins about their enforcing of a particular login shell, and having been a sysadmin myself. Not installing fish shell on production systems ("across the farm") is something I'd chalk up to wisdom, not a lack of open-mindedness. I was subtly suggesting that in my choice of positive adjectives.
    - mixmastamyk 10y ago
      Really, you shouldn't be logging in interactively into production machines, so no need to install extra tools by default.
- kkirsche 10y ago
  This to me makes too many assumptions. I'm sorry but experience doesn't mean wise. And in many cases experience can mean complacent or scared of change.
  - kbenson 10y ago
    Neither experience not wise was used. Older was used. You are comparing two possible substitutions with each other, not the original term. There's not much point to that.
chriswarbo 10y ago
> We should be focusing on saner bash defaults, since it's the most common shell in use. Bash already provides two "modes": when called as `sh` it is more POSIX-compliant, when called as `bash` it allows more bash-specific features and syntax. Maybe `bash` invocation can remain for backwards compatibility, and a new mode be added (e.g. `sash` for "sane shell") which can be used for breaking changes in the name of safety and sanity. This opt-in usage would avoid breaking existing scripts; whilst being bundled as part of bash would mitigate some of the chicken-and-egg and paradox of choice. Over time, `/usr/bin/env sash` will appear in more and more guides/tutorials/etc. whilst those using `/usr/bin/env bash` will continue to work, but look a little clunky. Of course, making such a "sane mode" as part of Bash would make it more high-profile and cause much more NIMBY, politics and bike-shedding than as a standalone project; but if it has a clear, consistent "mission statement" (e.g. "safety over convenience", "consistency over edge-cases", etc.), then maybe it could avoid too much scope creep and benefit from input by lots of very knowledgable experts.
- stephenmm 10y ago
  The new name has to be dcbash or maybe dcsh but dcbash is more fun.
donatj 10y ago
I find ZSH a much more reasonable alternative than Fish. Comes preinstalled on many Linux distributions as well as OS X, and can be configured with plugins to do most everything Fish does.
naasking 10y ago
> I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. Disagree. A shell is a domain-specific programming language, and all the existing such languages are terrible. We'd be better off with a properly designed language, like a shell language based on OCaml: Caml-shcaml [1]. [1] http://users.eecs.northwestern.edu/~jesse/pubs/caml-shcaml/ http://users.eecs.northwestern.edu/~jesse/pubs/caml-shcaml/
lomnakkus 10y ago
> We should be focusing on saner bash defaults Yes! A huge part of the fragility of shell scripting is the fact that there are a billion options which change crucial semantics of how the language works. Just pick some goddamned sane option values and disallow changing them! There's a reason you don't see this kind of nonsense in "real" programming languages: It plays absolute havoc with reasoning about what will happen when you run a script. (You could easily miss the fact that the shebang line does/doesn't contain "-e" or that option to error-on-unset-variables is/isn't set, etc.)

txutxu 10y ago

If it's hard to try to convince them about fish... try to convince them to enter commands in a browser over a web stack, as a "shell". If they are conscious about the parts involved and the security repercussion, maybe they will say the same: "no". On the other side, technology is not advanced only by older SysAdmins, and it's nice to see new projects, experiments and developments.

jandrese 10y ago
> try to convince them to enter commands in a browser over a web stack, as a "shell". What? I had never heard of fish before and this is making me nop out pretty quickly.
- mastax 10y ago
  Fish is not web based. I think he's referring to the browser ui in the OP.

nailer 10y ago

That's because fish is a better version of existing shells. It's not significantly different to throw away what we have. Sane syntax and proper colors and better autocomplete make it better than bash, but not enough to throw away the network effects of bash. Think of hg trying to compete with git - it might be better, but it's not better enough. As a shell person (I'm the maintainer of https://certsimple.com/rosetta-stone https://certsimple.com/rosetta-stone) NGS offers: 1. non blocking 2. structured results Doing both of those - if NGS can do it - is a MASSIVE shift over existing Unix shells. Think git replacing svn. The POC for #1 looks really good: https://www.youtube.com/watch?v=T5Bpu4thVNo https://www.youtube.com/watch?v=T5Bpu4thVNo

lfowles 10y ago
Personally, I use fish as my interactive shell. Bash still exists in the background for purposes of _the whole world runs on it_.
- zyxley 10y ago
  Same here.
  - qorrect 10y ago
    Same here too. Fish on all local machines, bash on AWS instances, and all scripts written in bash, simply for compatibility.

oblio 10y ago

We should be focusing on saner bash defaults, since it's the most common shell in use. That kind of work is not glamorous and highly controversial. Ideally there should be some sort of cross distro/OS working group (Debian/Ubuntu, Red Hat, SUSE, FreeBSD, NetBSD, OpenBSD, Mac OS X, etc.), similar to the working groups that standardize the web, where such proposals can be made, voted on and adopted. For example there should be no reason in 2016 why a sane solution can't be found for having almost every bash installation recognize all keys on the keyboard (i.e. arrow keys wouldn't produce ^A sequences or similar). Another thing that would be sorely needed but would involve a much higher volume of work would be a template, at least for all GNU utils, which they use to define they options, parameters, arguments, whatever. And by "template" I mean library, actual working code they could include and configure. Instead of each shell (bash, zsh) having to come with a million small scripts that configure auto completion, these shells could just query the standard-compliant tool for its usage and would receive a standardized reply with everything. Powershell has something like this and it is a great idea.

gioele 10y ago
> That kind of work is not glamorous and highly controversial. Ideally there should be some sort of cross distro/OS working group (Debian/Ubuntu, Red Hat, SUSE, FreeBSD, NetBSD, OpenBSD, Mac OS X, etc.), similar to the working groups that standardize the web, where such proposals can be made, voted on and adopted. Like the Austin group, the technical committee that constantly releases updates to POSIX and the Single Unix Specification? http://www.opengroup.org/austin/ http://www.opengroup.org/austin/ http://pubs.opengroup.org/onlinepubs/9699919799/ http://pubs.opengroup.org/onlinepubs/9699919799/
- oblio 10y ago
  Aren't those folks more "enterprise" oriented than "quality of life" oriented?
iheartmemcache 10y ago
I've been using -nix for almost 20 years. I've used everything from ksh on SunOS 2.6 (Solaris?? what's that) to oh-my-zsh (for 3 years, before happily graduating to oh-my-fish). I grew up on Slackware 6 waiting hours and hours for a 2.2 kernel build to finish. In high school, FreeBSD 4.3 kernel mods took up more time than booze and women. My 3 year puppy love for oh-my-zsh dimmed as I transitioned to a more sane, less emotional woman - oh-my-fish. I hate to admit it, but Microsoft just got it right with Powershell. Standardizing the convention with an intuitive Verb-Noun, the out of the box documentation with -examples, -full, etc goes into so much detail that if everyone used it, there wouldn't be any dumb "How does I move directory??" questions on Stackoverflow (well, there'd be less at least). Don't know a command? Show-Commands and type in 'network' to see what's available. Don't see it there? Go get a Powershell script (often offered by vendors like VMware and Citrix, making devop lives easier). I remember spending _weeks_ trying to get my dual-boot machine (FBSD / Win2k) Cygwin/msys setup to work well on my P3 600 at 12 or 13. Now I can just Feature install Bash and get a native binary. Let me say that again -- now, I can Feature install Bash on Windows jeeebus. QT is LGPL. CLR is open source. Visual Studio Community (basically Professional) is free (unless you need historical debugging then Ultimate's going to cost a lot). Satya + Meijers + Hanselman et al have made favor Microsoft so hard, despite being an active donor of the FSF. That GNUutils-with-autocomplete is real trivial to write, but since it's already in fish, I see no need to right it. :smug: [In all seriousness, I agree with you re: standards. Plan 9's interface standards semi-addressed that. But le sigh such is life.]

StreakyCobra 10y ago

Side note: https://github.com/supercrabtree/k https://github.com/supercrabtree/k is a ZSH plugin in the same register that `exa`.

xomateix 10y ago

Relevant xkcd: https://xkcd.com/927/ https://xkcd.com/927/

js2 10y ago

older SysAdmins I hope you aren't referring to their age, in which case consider using a different adjective: experienced, seasoned, wiser, etc. Your colleagues probably don't want to install fish shell for reasons besides how old they are.

gervase 10y ago
Or, if you disagree with their opinion: hidebound, closeminded, timorous, etc. I think the parent was going for something indicating disagreement, so it seems unlikely that your "positive" adjectives are what they were looking for.
- js2 10y ago
  I've been on both sides of the equation, having disagreed with sysadmins about their enforcing of a particular login shell, and having been a sysadmin myself. Not installing fish shell on production systems ("across the farm") is something I'd chalk up to wisdom, not a lack of open-mindedness. I was subtly suggesting that in my choice of positive adjectives.
  - mixmastamyk 10y ago
    Really, you shouldn't be logging in interactively into production machines, so no need to install extra tools by default.
kkirsche 10y ago
This to me makes too many assumptions. I'm sorry but experience doesn't mean wise. And in many cases experience can mean complacent or scared of change.
- kbenson 10y ago
  Neither experience not wise was used. Older was used. You are comparing two possible substitutions with each other, not the original term. There's not much point to that.

chriswarbo 10y ago

> We should be focusing on saner bash defaults, since it's the most common shell in use. Bash already provides two "modes": when called as `sh` it is more POSIX-compliant, when called as `bash` it allows more bash-specific features and syntax. Maybe `bash` invocation can remain for backwards compatibility, and a new mode be added (e.g. `sash` for "sane shell") which can be used for breaking changes in the name of safety and sanity. This opt-in usage would avoid breaking existing scripts; whilst being bundled as part of bash would mitigate some of the chicken-and-egg and paradox of choice. Over time, `/usr/bin/env sash` will appear in more and more guides/tutorials/etc. whilst those using `/usr/bin/env bash` will continue to work, but look a little clunky. Of course, making such a "sane mode" as part of Bash would make it more high-profile and cause much more NIMBY, politics and bike-shedding than as a standalone project; but if it has a clear, consistent "mission statement" (e.g. "safety over convenience", "consistency over edge-cases", etc.), then maybe it could avoid too much scope creep and benefit from input by lots of very knowledgable experts.

stephenmm 10y ago
The new name has to be dcbash or maybe dcsh but dcbash is more fun.

donatj 10y ago

I find ZSH a much more reasonable alternative than Fish. Comes preinstalled on many Linux distributions as well as OS X, and can be configured with plugins to do most everything Fish does.

naasking 10y ago

> I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. Disagree. A shell is a domain-specific programming language, and all the existing such languages are terrible. We'd be better off with a properly designed language, like a shell language based on OCaml: Caml-shcaml [1]. [1] http://users.eecs.northwestern.edu/~jesse/pubs/caml-shcaml/ http://users.eecs.northwestern.edu/~jesse/pubs/caml-shcaml/

lomnakkus 10y ago

> We should be focusing on saner bash defaults Yes! A huge part of the fragility of shell scripting is the fact that there are a billion options which change crucial semantics of how the language works. Just pick some goddamned sane option values and disallow changing them! There's a reason you don't see this kind of nonsense in "real" programming languages: It plays absolute havoc with reasoning about what will happen when you run a script. (You could easily miss the fact that the shebang line does/doesn't contain "-e" or that option to error-on-unset-variables is/isn't set, etc.)