17 ms·

The Renaissance of the Shell?

45 points by dwmkerr 6y ago

fit2rule 6y ago
I firmly believe that a lot of really productive work can be done with shell-based applications, and that this environment represents the true power of productive computing. With the web taking front and centre priority, we've lost something very important in terms of human/computer interaction - many would say things are 'easier', but I have to laugh at this claim whenever I see someone clicking something in a list a hundred times when it could have been something they'd solved with a little script, had they known how. Too many times I've saved someones ass by a bit of script fu, only to be granted god-like status at how quickly it was done - but if people took a month of study on, say, bash scripting or something similar, it wouldn't seem so obtuse. Same goes for google-fu. What is happening that the arcane science of proper search semantics is not being taught kids in school? It seems to me the devolutionary effect of "ease of use computing" has wrought its anti-pattern woes over a few generations .. Anyway, my kids learned bash before they learned how to find the Settings panel, and there is something to be said for the teenager who knows how to wrangle his OS because his Dad taught him the basics of shell-based package management, something still not quite done well in certain environments...
- stinos 6y ago
  You're not really wrong on many of your points, but you look at everything from a power user/developer mindset and that's too narrow of an approach, sorry. I.e. you should realize programming is not for everybody, not even close, so the claim that things are easier now is very much true for a lot of people out there. As such there's not much to laugh at, in fact that sounds borderline disrespectful to me.
  - mercer 6y ago
    > You're not really wrong on many of your points, but you look at everything from a power user/developer mindset and that's too narrow of an approach, sorry. I sometimes wonder if how people talked about 'this whole writing and reading thing' way back when. Perhaps there's a future where the average person will be what we now consider a 'power user'? Much as there's the criticize about current-day computer use, as someone who was considered a 'nerd' for chatting online in my teens, it's still amazing to see extremely non-typical 'nerds' sit at their laptops or phones chatting with others. Or to have conversation about gaming with people who fit the 'jock' stereotype. I'd love to hear from historians how the 'common people' thought about writing back in the day when most people were illiterate.
  - smichel17 6y ago
    > programming is not for everybody I guess we (although I am not the person you replied to) have a fundamental disagreement here. I think absolutely, everyone is able to code, a little. Not to be a career programmer, mind you, and I have no expectation that they should be able to produce readable or maintainable code. I have a weakly-held opinion that people shouldn't have to code if they choose not to. However, I think a little coding knowledge is essential for digital autonomy, which is more and more synonymous with regular autonomy, and that everyone ought to have that.
ktpsns 6y ago
I also observe a renaissance of command line interfaces. I guess it's a trend in a similar way how the graphical user interface (in the MS Windows/OS X/X11 way) has been trendy in the 1990s/early 2000s. Remember that Apple banned the terminal from classic Mac OS. This was a declaration of war against complicated CLIs. Nowadays we experience the opposite: Microsoft is building the most modern Terminal emulator as well as many productivity tools such as Powershell but also the Linux subsystem. Of course this is driven by commercial interests. Microsoft tries to close the gap to the rich Mac OS X development environment, which is rich because it is compatible to the Unix/Linux ecosystem. As the author noted, many jobs are primarily terminal-based in a way like probably nobody would have believed 20 years ago. DevOps or data scientist, they both enjoy powerful CLI applications, REPL interfaces, scripting as if the "GUI movement" did not even take place.
- Cthulhu_ 6y ago
  Question, because I wasn't a developer 20 years ago yet; were the GUI tools of "back when" wrappers around CLI tools? I get that impression with most IDE's I've worked with.
  - yuribro 6y ago
    I don't think they were the same way they are now. Visual Studio 6, which was an amazing environment for its time, was all implemented as a GUI application, including the build system, IIRC you could do some automations with VBA or a complex "macro" system baked inside the UI. You could run the compiler/linker as cli apps, but everything else was built in. VisualAssist was a very popular plugin for it (don't know if it's still relevant) which added functionality inside the GUI.
  - flohofwoe 6y ago
    I think this depends heavily on the platform. Towards the end of the Amiga it was common that applications were accessible through a GUI, through the command line and through scripting, as well as extending operating system features for other applications via system-wide installable plugins/extensions which are recognized by other applications. It was common to use a mix of UI and command line workflows and both worlds were well integrated with each other. For instance: A typical 2D drawing program which would primarily be used through the UI to draw images could also register new image format plugins with the operating system, so that all applications that deal with image files suddenly can load and save those new formats. The same application might be started on the command line in a 'headless' mode to offer image manipulation tasks like ImageMagick, and finally the application can offer an AREXX scripting port for more complex automation tasks, and "orchestrating" several applications. All of this was standardized through "best practices" guidelines by the Amiga team. I miss the Amiga :) PS: My pet theory for the reason why there's a "shell renaissance" is that UI usability (in the sense of making complex application features "usable") has dramatically regressed in the last 10..20 years because the target audience for most apps has changed from active users to passive consumers. People who don't fit the "average user" have no other choice than to move to the command line because UIs are no longer designed for them. This "average user" targeted by UI designers is no longer a creative person who uses the computer to solve tasks or create art, but a passive media consumer. The computer has been degraded from the "bicycle for the mind" to a dumb TV set basically.
29athrowaway 6y ago
It's hard to automate something with a GUI. It is also hard to make programs interoperate if they use a GUI.
- MayeulC 6y ago
  It doesn't necessarily have to, though : look at plan9. IIRC GUIs respected UNIX's " everything is a file" philosophy, and thus were introspectible, modifiable and scriptable from other programs. Looking at modern desktop Linux, I wish it had retained more of this. Unfortunately, d-bus, GObject and Wayland aren't really file-based.
- yuribro 6y ago
  I think that we just don't have a standard for it. I know people use AutoHotkey to automate a lot of workflows involving GUI applications. Recently there was a thread about Factorio (the game), which is all about automating. And once you have standard-ish inputs & outputs, you can achieve a lot of automations, in a different way. It also highlights that the shell has limitations: it's hard to give multiple inputs, and handle outputs and create a complex pipeline. (I guess that's why we have things like Airflow)
- jabirali 6y ago
  It doesn't have to be though, there's just a high correlation between hard-to-automate apps and non-command-line apps. You can e.g. make a GUI app where every button or keybinding is bound to a named function (GUI Emacs comes to mind), and where those named functions can be used in scripts. Another option is to have a scriptable backend; LibreOffice has a terminal interface that lets you e.g. convert between document formats from a shell script, and Astroid Mail is built on Notmuch as its backend which is scriptable.
  - foxdev 6y ago
    Reaper has a billion actions you can assign to key combinations, and you can build your own toolbars from them. I think it's as close to a console application as I've seen a GUI get. It also has a scripting language you can use to make just about anything. GUI Emacs sounds like it probably influenced the Reaper people.
marmada 6y ago
I certainly hope the shell doesn't have a renaissance. Just today I was updating my dotfiles/customizing my OS, and I had to swap out several shell scripts for Python scripts because I couldn't edit shell. The scripts looked like arcane rituals, not editable code.
- stephenr 6y ago
  Shell scripts have some idiosyncrasies sure, but at least they don't rely on significant white space.
  - yuribro 6y ago
    Not a pure shell, but Makefiles do rely on whitespace. I never understood why so many people care about that (not to mention that python uses the curly braces as a useful syntax element for dicts & sets)
    - stephenr 6y ago
      Makefiles don't gernally have anything more than one level of indentation that is significant. People care about significant whitespace because it's inferring heavy semantic meaning from something that's by default invisible, and even when shown visibly, may not actually be particularly obvious.
    - simias 6y ago
      I use Python a lot so it's not a deal breaker to me, but even after years of use significant whitespace is still firmly in the "bad ideas" category for me. It's form over function. When I code in C and move some code around I can just tell my editor "reindent this code" and it looks fine immediately. With Python I always have to double-check to make sure everything is in the right place. Similarly I almost never have to reindent anything manually in C. The editor always knows where I should be based on the number of open braces. In python I often have to readjust. A common situation where that's annoying is if I want to add code after and outside a block, in C I just tell vim to open a line after the closing bracket and I'm immediately at the right location, in Python doing this will have the cursor at the wrong level of indentation. It's not the end of the world and it's bikeshed territory but for me significant whitespace is in the same category as automatic semicolon insertion in JavaScript, I sorta get why somebody thought it was a good idea at some point but it's just more trouble than it's worth in practice. Python wanted to be the anti-perl and it went too far in some places. Pseudo-code is only "pseudo" for a reason.
majkinetor 6y ago
Most of ones work should be in the shell all the time, because automation tasks are every day phenomena (or should be). Otherwise, if its GUI oriented, you will still have to learn CLI variant sooner or later and not only its harder or almost impossible to automate, but such automation is usually flaky as well. Shell should be considered basic and most important interaction with computer with anything else deemed as optional. The big problem is that almost all of the shell's are stuck in the previous century, except PowerShell.
- jabirali 6y ago
  > The big problem is that almost all of the shell's are stuck in the previous century, except PowerShell. Another exception is Nushell, which seems to be partly inspired by PowerShell, and has some very appealing ideas. However, given the time Fish needed to steal even a small market share from Bash and Zsh, it will likely take a long time before something even more radical goes mainstream. Unless of course a major player were to back this new shell, like when Microsoft pushed PowerShell and Apple pushed Zsh.
  - majkinetor 6y ago
    > Another exception is Nushell I was talking about production ready systems. Nushell is far from it ATM, and will certainly be so in the next half decade.
- oblio 6y ago
  The bad news is shell adoption. The biggest selling point of a shell is ubiquity. Zsh for many, many years was basically Bash with more features but not endorsed by GNU. Bash was released in June 1989. Zsh was released in December 1990. Yet Zsh has replaced Bash only on MacOS, only about 1 year ago and only because of Bash licensing issues (new Bash versions are under GPL3 instead of 2 and Apple hates GPL3 because it's against their locked down devices). 29 years to replace the default shell on just 1 platform... despite almost bug-for-bug compatibility, POSIX support, extra features. I wish new shells good luck!
- cuddlybacon 6y ago
chubot 6y ago
The three points about the renaissance of the shell are spot on. (1) Systems being written in more languages means the shell becomes more important I wrote about that here: https://news.ycombinator.com/item?id=24083764 https://news.ycombinator.com/item?id=24083764 The idea is that I write programs in Python, JavaScript, R, and C++ regularly, and about 10 different DSLs (SQL, HTML, etc.) And I work on systems written by others, consisting of even more languages. in regards to http://www.oilshell.org/ http://www.oilshell.org/ (2) Convergence around Unix and Linux for the server side. Unix won. In 2017 or so, Windows Subsystem for Linux was marketed as "Bash on Windows" !!! That is, being able to run a 30 year old shell and other programs was a new feature of Windows. (3) DevOps I forget where I read this, but someone quipped that "old school sys admins didn't disappear". (That is, the experts at Unix shell.) "What happened is that they went to work for AWS and Google and then sold their skills back to you at a higher and recurring price" I find that to be pretty spot on... The cloud companies are making a lot of stuff point and click, and cut and paste YAML, so you don't have to use shell, but I think programmers are better off learning and using shell. Reaosns: For autonomy, to avoid being locked in, to exercise the ability to create simple, sharp, one-offs ... not drag in a 200 MB cloud SDK to solve a simple problem.
- danieldk 6y ago
  I find that to be pretty spot on... The cloud companies are making a lot of stuff point and click, and cut and paste YAML, so you don't have to use shell, but I think programmers are better off learning and using shell. I have been using Nix for most system-level stuff the last two years (development environments, building container images, declaratively managing systems). It is far more powerful than YAML configuration (it's a turing-complete functional language after all), but the functional aspect brings many benefits (no side-effects, etc.). Of course, nix(pkgs) stdenv makes liberal use of Bourne shell in its build phases, so a bit of shell chops is very useful there as well.
axilmar 6y ago
The shell is the tool that allows us to talk to our computers, and for our computers to talk to us. Until a better way comes out to tell the computer what to do, the command line will prevail.
- WJW 6y ago
  I alsways explain it to new students as the shell being the equivalent of "under the hood" but for computers instead of cars. If you go to a car mechanic with engine problems and they won't even inspect under the hood, it's probably not a very good mechanic. (The last few years have not been too kind to this metaphor because of computer-based analytics, but still)
justforfunhere 6y ago
Learning Vi at an early stage in career has been a life saver for me. Having to do a lot of my work on remote shells over many years could have been more difficult had I not had some degree of command over a text editor like Vi. And then there are other advantages too. Editing code in Vi/Vim is akin to touch typing if you are really good. Programming becomes so much easier and so much fun. And last but not the least, there are still loads of things to learn about Vi.
- danieldk 6y ago
  Plus most modern shells have a vi editing mode. Add something like vimium to your browser and you can use the same muscle memory across environments. I did switch from vim to Emacs + Evil though (Evil adds a decent text editor to Emacs), with my own set of spacemacs-like keybindings.
anonymfus 6y ago
Because of the capitalisation combined with the domain name that tittle ("The Renaissance of the Shell") made me expect to read a piece of propaganda from the oil company. Considering that generally the term shell means any software with purpose to manipulate files and run other programs, it would be better to call it "The renaissance of the command line shell".
- kwhitefoot 6y ago
  If it had meant the oil company it would have omitted the definite article: "The Renaissance of Shell". Or perhaps even included the full name: "The Renaissance of Royal Dutch Shell".
  - anonymfus 6y ago
    Thank you, my native language lacks articles.
    - kwhitefoot 6y ago
      Ah, in that case yours is a perfectly understandable interpretation. May I ask which language?
      - anonymfus 6y ago
        Russian
        kwhitefoot 6y ago
        Thank you. Now another question: how would you make the same distinction in Russian? I mean an explanation of it not just the actual words, I had three weeks of Russian in high school nearly fifty years ago but none of it has stuck.
bregma 6y ago
GUIs are using pictures to convey meaning and action. A picture is worth 1000 words. Why use 1000 words to do something when one or two will do?
- thesuperbigfrog 6y ago
  = Master Foo Discourses on the Graphical User Interface = One evening, Master Foo and Nubi attended a gathering of programmers who had met to learn from each other. One of the programmers asked Nubi to what school he and his master belonged. Upon being told they were followers of the Great Way of Unix, the programmer grew scornful. “The command-line tools of Unix are crude and backward,” he scoffed. “Modern, properly designed operating systems do everything through a graphical user interface.” Master Foo said nothing, but pointed at the moon. A nearby dog began to bark at the master's hand. “I don't understand you!” said the programmer. Master Foo remained silent, and pointed at an image of the Buddha. Then he pointed at a window. “What are you trying to tell me?” asked the programmer. Master Foo pointed at the programmer's head. Then he pointed at a rock. “Why can't you make yourself clear?” demanded the programmer. Master Foo frowned thoughtfully, tapped the programmer twice on the nose, and dropped him in a nearby trashcan. As the programmer was attempting to extricate himself from the garbage, the dog wandered over and piddled on him. At that moment, the programmer achieved enlightenment. Source: http://www.catb.org/~esr/writings/unix-koans/gui-programmer.html http://www.catb.org/~esr/writings/unix-koans/gui-programmer....
  - lostmsu 6y ago
    ls -al rm -r. /* git checkout -b thisIsFine Couldn't give you a sed or awk example, because, fortunately, did not have to learn either yet.
    - NateEag 6y ago
      The fact that some CLIs have terrible UX does not invalidate the idea of CLIs.
      - 6y ago
tsimionescu 6y ago
I think this shell Renaissance is going to be short-lived. Scripting is a very brittle way to do automation, and that is recognized across the spectrum, especially when handling distributed systems. The world seems to be moving much more towards APIs and declarative configuration formats, with actual scripts acting as a sort of last resort only. The author even mentions Kubernetes, which is very much designed to replace scripting based control of your systems with an API. Even kubectl is just an utility build over the API, not a core part of the system. And even outside the cloud-ish world, you have systemd taking over the Linux world one distro at a time, and it's focus is firmly towards replacing shell scripts with configuration files.

45 points by dwmkerr 6y ago

I firmly believe that a lot of really productive work can be done with shell-based applications, and that this environment represents the true power of productive computing. With the web taking front and centre priority, we've lost something very important in terms of human/computer interaction - many would say things are 'easier', but I have to laugh at this claim whenever I see someone clicking something in a list a hundred times when it could have been something they'd solved with a little script, had they known how. Too many times I've saved someones ass by a bit of script fu, only to be granted god-like status at how quickly it was done - but if people took a month of study on, say, bash scripting or something similar, it wouldn't seem so obtuse. Same goes for google-fu. What is happening that the arcane science of proper search semantics is not being taught kids in school? It seems to me the devolutionary effect of "ease of use computing" has wrought its anti-pattern woes over a few generations .. Anyway, my kids learned bash before they learned how to find the Settings panel, and there is something to be said for the teenager who knows how to wrangle his OS because his Dad taught him the basics of shell-based package management, something still not quite done well in certain environments...

stinos 6y ago
You're not really wrong on many of your points, but you look at everything from a power user/developer mindset and that's too narrow of an approach, sorry. I.e. you should realize programming is not for everybody, not even close, so the claim that things are easier now is very much true for a lot of people out there. As such there's not much to laugh at, in fact that sounds borderline disrespectful to me.
- mercer 6y ago
  > You're not really wrong on many of your points, but you look at everything from a power user/developer mindset and that's too narrow of an approach, sorry. I sometimes wonder if how people talked about 'this whole writing and reading thing' way back when. Perhaps there's a future where the average person will be what we now consider a 'power user'? Much as there's the criticize about current-day computer use, as someone who was considered a 'nerd' for chatting online in my teens, it's still amazing to see extremely non-typical 'nerds' sit at their laptops or phones chatting with others. Or to have conversation about gaming with people who fit the 'jock' stereotype. I'd love to hear from historians how the 'common people' thought about writing back in the day when most people were illiterate.
- smichel17 6y ago
  > programming is not for everybody I guess we (although I am not the person you replied to) have a fundamental disagreement here. I think absolutely, everyone is able to code, a little. Not to be a career programmer, mind you, and I have no expectation that they should be able to produce readable or maintainable code. I have a weakly-held opinion that people shouldn't have to code if they choose not to. However, I think a little coding knowledge is essential for digital autonomy, which is more and more synonymous with regular autonomy, and that everyone ought to have that.

ktpsns 6y ago

I also observe a renaissance of command line interfaces. I guess it's a trend in a similar way how the graphical user interface (in the MS Windows/OS X/X11 way) has been trendy in the 1990s/early 2000s. Remember that Apple banned the terminal from classic Mac OS. This was a declaration of war against complicated CLIs. Nowadays we experience the opposite: Microsoft is building the most modern Terminal emulator as well as many productivity tools such as Powershell but also the Linux subsystem. Of course this is driven by commercial interests. Microsoft tries to close the gap to the rich Mac OS X development environment, which is rich because it is compatible to the Unix/Linux ecosystem. As the author noted, many jobs are primarily terminal-based in a way like probably nobody would have believed 20 years ago. DevOps or data scientist, they both enjoy powerful CLI applications, REPL interfaces, scripting as if the "GUI movement" did not even take place.

Cthulhu_ 6y ago
Question, because I wasn't a developer 20 years ago yet; were the GUI tools of "back when" wrappers around CLI tools? I get that impression with most IDE's I've worked with.
- yuribro 6y ago
  I don't think they were the same way they are now. Visual Studio 6, which was an amazing environment for its time, was all implemented as a GUI application, including the build system, IIRC you could do some automations with VBA or a complex "macro" system baked inside the UI. You could run the compiler/linker as cli apps, but everything else was built in. VisualAssist was a very popular plugin for it (don't know if it's still relevant) which added functionality inside the GUI.
- flohofwoe 6y ago
  I think this depends heavily on the platform. Towards the end of the Amiga it was common that applications were accessible through a GUI, through the command line and through scripting, as well as extending operating system features for other applications via system-wide installable plugins/extensions which are recognized by other applications. It was common to use a mix of UI and command line workflows and both worlds were well integrated with each other. For instance: A typical 2D drawing program which would primarily be used through the UI to draw images could also register new image format plugins with the operating system, so that all applications that deal with image files suddenly can load and save those new formats. The same application might be started on the command line in a 'headless' mode to offer image manipulation tasks like ImageMagick, and finally the application can offer an AREXX scripting port for more complex automation tasks, and "orchestrating" several applications. All of this was standardized through "best practices" guidelines by the Amiga team. I miss the Amiga :) PS: My pet theory for the reason why there's a "shell renaissance" is that UI usability (in the sense of making complex application features "usable") has dramatically regressed in the last 10..20 years because the target audience for most apps has changed from active users to passive consumers. People who don't fit the "average user" have no other choice than to move to the command line because UIs are no longer designed for them. This "average user" targeted by UI designers is no longer a creative person who uses the computer to solve tasks or create art, but a passive media consumer. The computer has been degraded from the "bicycle for the mind" to a dumb TV set basically.

29athrowaway 6y ago

It's hard to automate something with a GUI. It is also hard to make programs interoperate if they use a GUI.

MayeulC 6y ago
It doesn't necessarily have to, though : look at plan9. IIRC GUIs respected UNIX's " everything is a file" philosophy, and thus were introspectible, modifiable and scriptable from other programs. Looking at modern desktop Linux, I wish it had retained more of this. Unfortunately, d-bus, GObject and Wayland aren't really file-based.
yuribro 6y ago
I think that we just don't have a standard for it. I know people use AutoHotkey to automate a lot of workflows involving GUI applications. Recently there was a thread about Factorio (the game), which is all about automating. And once you have standard-ish inputs & outputs, you can achieve a lot of automations, in a different way. It also highlights that the shell has limitations: it's hard to give multiple inputs, and handle outputs and create a complex pipeline. (I guess that's why we have things like Airflow)
jabirali 6y ago
It doesn't have to be though, there's just a high correlation between hard-to-automate apps and non-command-line apps. You can e.g. make a GUI app where every button or keybinding is bound to a named function (GUI Emacs comes to mind), and where those named functions can be used in scripts. Another option is to have a scriptable backend; LibreOffice has a terminal interface that lets you e.g. convert between document formats from a shell script, and Astroid Mail is built on Notmuch as its backend which is scriptable.
- foxdev 6y ago
  Reaper has a billion actions you can assign to key combinations, and you can build your own toolbars from them. I think it's as close to a console application as I've seen a GUI get. It also has a scripting language you can use to make just about anything. GUI Emacs sounds like it probably influenced the Reaper people.

marmada 6y ago

I certainly hope the shell doesn't have a renaissance. Just today I was updating my dotfiles/customizing my OS, and I had to swap out several shell scripts for Python scripts because I couldn't edit shell. The scripts looked like arcane rituals, not editable code.

stephenr 6y ago
Shell scripts have some idiosyncrasies sure, but at least they don't rely on significant white space.
- yuribro 6y ago
  Not a pure shell, but Makefiles do rely on whitespace. I never understood why so many people care about that (not to mention that python uses the curly braces as a useful syntax element for dicts & sets)
  - stephenr 6y ago
    Makefiles don't gernally have anything more than one level of indentation that is significant. People care about significant whitespace because it's inferring heavy semantic meaning from something that's by default invisible, and even when shown visibly, may not actually be particularly obvious.
  - simias 6y ago
    I use Python a lot so it's not a deal breaker to me, but even after years of use significant whitespace is still firmly in the "bad ideas" category for me. It's form over function. When I code in C and move some code around I can just tell my editor "reindent this code" and it looks fine immediately. With Python I always have to double-check to make sure everything is in the right place. Similarly I almost never have to reindent anything manually in C. The editor always knows where I should be based on the number of open braces. In python I often have to readjust. A common situation where that's annoying is if I want to add code after and outside a block, in C I just tell vim to open a line after the closing bracket and I'm immediately at the right location, in Python doing this will have the cursor at the wrong level of indentation. It's not the end of the world and it's bikeshed territory but for me significant whitespace is in the same category as automatic semicolon insertion in JavaScript, I sorta get why somebody thought it was a good idea at some point but it's just more trouble than it's worth in practice. Python wanted to be the anti-perl and it went too far in some places. Pseudo-code is only "pseudo" for a reason.

majkinetor 6y ago

Most of ones work should be in the shell all the time, because automation tasks are every day phenomena (or should be). Otherwise, if its GUI oriented, you will still have to learn CLI variant sooner or later and not only its harder or almost impossible to automate, but such automation is usually flaky as well. Shell should be considered basic and most important interaction with computer with anything else deemed as optional. The big problem is that almost all of the shell's are stuck in the previous century, except PowerShell.

jabirali 6y ago
> The big problem is that almost all of the shell's are stuck in the previous century, except PowerShell. Another exception is Nushell, which seems to be partly inspired by PowerShell, and has some very appealing ideas. However, given the time Fish needed to steal even a small market share from Bash and Zsh, it will likely take a long time before something even more radical goes mainstream. Unless of course a major player were to back this new shell, like when Microsoft pushed PowerShell and Apple pushed Zsh.
- majkinetor 6y ago
  > Another exception is Nushell I was talking about production ready systems. Nushell is far from it ATM, and will certainly be so in the next half decade.
oblio 6y ago
The bad news is shell adoption. The biggest selling point of a shell is ubiquity. Zsh for many, many years was basically Bash with more features but not endorsed by GNU. Bash was released in June 1989. Zsh was released in December 1990. Yet Zsh has replaced Bash only on MacOS, only about 1 year ago and only because of Bash licensing issues (new Bash versions are under GPL3 instead of 2 and Apple hates GPL3 because it's against their locked down devices). 29 years to replace the default shell on just 1 platform... despite almost bug-for-bug compatibility, POSIX support, extra features. I wish new shells good luck!
cuddlybacon 6y ago

chubot 6y ago

The three points about the renaissance of the shell are spot on. (1) Systems being written in more languages means the shell becomes more important I wrote about that here: https://news.ycombinator.com/item?id=24083764 https://news.ycombinator.com/item?id=24083764 The idea is that I write programs in Python, JavaScript, R, and C++ regularly, and about 10 different DSLs (SQL, HTML, etc.) And I work on systems written by others, consisting of even more languages. in regards to http://www.oilshell.org/ http://www.oilshell.org/ (2) Convergence around Unix and Linux for the server side. Unix won. In 2017 or so, Windows Subsystem for Linux was marketed as "Bash on Windows" !!! That is, being able to run a 30 year old shell and other programs was a new feature of Windows. (3) DevOps I forget where I read this, but someone quipped that "old school sys admins didn't disappear". (That is, the experts at Unix shell.) "What happened is that they went to work for AWS and Google and then sold their skills back to you at a higher and recurring price" I find that to be pretty spot on... The cloud companies are making a lot of stuff point and click, and cut and paste YAML, so you don't have to use shell, but I think programmers are better off learning and using shell. Reaosns: For autonomy, to avoid being locked in, to exercise the ability to create simple, sharp, one-offs ... not drag in a 200 MB cloud SDK to solve a simple problem.

danieldk 6y ago
I find that to be pretty spot on... The cloud companies are making a lot of stuff point and click, and cut and paste YAML, so you don't have to use shell, but I think programmers are better off learning and using shell. I have been using Nix for most system-level stuff the last two years (development environments, building container images, declaratively managing systems). It is far more powerful than YAML configuration (it's a turing-complete functional language after all), but the functional aspect brings many benefits (no side-effects, etc.). Of course, nix(pkgs) stdenv makes liberal use of Bourne shell in its build phases, so a bit of shell chops is very useful there as well.

axilmar 6y ago

The shell is the tool that allows us to talk to our computers, and for our computers to talk to us. Until a better way comes out to tell the computer what to do, the command line will prevail.

WJW 6y ago
I alsways explain it to new students as the shell being the equivalent of "under the hood" but for computers instead of cars. If you go to a car mechanic with engine problems and they won't even inspect under the hood, it's probably not a very good mechanic. (The last few years have not been too kind to this metaphor because of computer-based analytics, but still)

justforfunhere 6y ago

Learning Vi at an early stage in career has been a life saver for me. Having to do a lot of my work on remote shells over many years could have been more difficult had I not had some degree of command over a text editor like Vi. And then there are other advantages too. Editing code in Vi/Vim is akin to touch typing if you are really good. Programming becomes so much easier and so much fun. And last but not the least, there are still loads of things to learn about Vi.

danieldk 6y ago
Plus most modern shells have a vi editing mode. Add something like vimium to your browser and you can use the same muscle memory across environments. I did switch from vim to Emacs + Evil though (Evil adds a decent text editor to Emacs), with my own set of spacemacs-like keybindings.

anonymfus 6y ago

Because of the capitalisation combined with the domain name that tittle ("The Renaissance of the Shell") made me expect to read a piece of propaganda from the oil company. Considering that generally the term shell means any software with purpose to manipulate files and run other programs, it would be better to call it "The renaissance of the command line shell".

kwhitefoot 6y ago
If it had meant the oil company it would have omitted the definite article: "The Renaissance of Shell". Or perhaps even included the full name: "The Renaissance of Royal Dutch Shell".
- anonymfus 6y ago
  Thank you, my native language lacks articles.
  - kwhitefoot 6y ago
    Ah, in that case yours is a perfectly understandable interpretation. May I ask which language?
    - anonymfus 6y ago
      Russian
      - kwhitefoot 6y ago
        Thank you. Now another question: how would you make the same distinction in Russian? I mean an explanation of it not just the actual words, I had three weeks of Russian in high school nearly fifty years ago but none of it has stuck.

bregma 6y ago

GUIs are using pictures to convey meaning and action. A picture is worth 1000 words. Why use 1000 words to do something when one or two will do?

thesuperbigfrog 6y ago
= Master Foo Discourses on the Graphical User Interface = One evening, Master Foo and Nubi attended a gathering of programmers who had met to learn from each other. One of the programmers asked Nubi to what school he and his master belonged. Upon being told they were followers of the Great Way of Unix, the programmer grew scornful. “The command-line tools of Unix are crude and backward,” he scoffed. “Modern, properly designed operating systems do everything through a graphical user interface.” Master Foo said nothing, but pointed at the moon. A nearby dog began to bark at the master's hand. “I don't understand you!” said the programmer. Master Foo remained silent, and pointed at an image of the Buddha. Then he pointed at a window. “What are you trying to tell me?” asked the programmer. Master Foo pointed at the programmer's head. Then he pointed at a rock. “Why can't you make yourself clear?” demanded the programmer. Master Foo frowned thoughtfully, tapped the programmer twice on the nose, and dropped him in a nearby trashcan. As the programmer was attempting to extricate himself from the garbage, the dog wandered over and piddled on him. At that moment, the programmer achieved enlightenment. Source: http://www.catb.org/~esr/writings/unix-koans/gui-programmer.html http://www.catb.org/~esr/writings/unix-koans/gui-programmer....
- lostmsu 6y ago
  ls -al rm -r. /* git checkout -b thisIsFine Couldn't give you a sed or awk example, because, fortunately, did not have to learn either yet.
  - NateEag 6y ago
    The fact that some CLIs have terrible UX does not invalidate the idea of CLIs.
    - 6y ago

tsimionescu 6y ago

I think this shell Renaissance is going to be short-lived. Scripting is a very brittle way to do automation, and that is recognized across the spectrum, especially when handling distributed systems. The world seems to be moving much more towards APIs and declarative configuration formats, with actual scripts acting as a sort of last resort only. The author even mentions Kubernetes, which is very much designed to replace scripting based control of your systems with an API. Even kubectl is just an utility build over the API, not a core part of the system. And even outside the cloud-ish world, you have systemd taking over the Linux world one distro at a time, and it's focus is firmly towards replacing shell scripts with configuration files.