
The Renaissance of the Shell? - dwmkerr
https://effective-shell.com/docs/part-1-transitioning-to-the-shell/6-the-renaissance-of-the-shell/
======
ktpsns
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.

~~~
cheph
> Microsoft is building the most modern Terminal emulator

If it is anything like Powershell, which is more "modern" than bash, then I
don't think it will make much of an impact. Powershell seems like it was
designed by a comittee which did not quite understand the point of what they
were doing.

It seems that if at least someone on that committee used a Unix terminal maybe
once in their lives they would realize that what they were building would
deliver a really bad user experience.

~~~
cringepirate
I read "Bad user experience" but I suspect what you mean is "It not what I am
used to".

They (Microsoft) say that their inspiration was Korn Shell and Languages like
TCL. Microsoft when they still offered Windows services for Unix, they did
provide a Korn shell. If you look at some PowerShell examples and some Korn
Shell example there are quite a few similarities between the two.

So they obviously were quite aware of the options in the *nix world. I really
wish people wouldn't make these sorts of claims when spending like less than a
few minutes looking up the development history would dispel these ideas
immediately.

Personally I really like PowerShell and I find it fun to program in whereas
with bash I seem to have to always relearn it whenever I attempt to do
something non-trivial. However I come from a background of programming in OOP
languages like Java and C# so many it just suits my mental model better than
bash.

~~~
koffiezet
In my (limited) powershell experience, it's a "scripting first" shell, while
bash is more of a a cli-first shell.

Using a powershell cli is very verbose (although pretty consistent), but using
it without some sort of GUI helper if you're not familiar with it is pretty
daunting.

~~~
cringepirate
I would agree with that. I think the verbosity arguments do have some merit. I
normally write scripts with the ISE or VSCode with a plugin.

Also there are lots of extensions that you are kinda just supposed to know
about e.g. dba-tools extensions.

------
justforfunhere
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
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.

------
chubot
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
_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.

------
bregma
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
= 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....](http://www.catb.org/~esr/writings/unix-koans/gui-
programmer.html)

~~~
lostmsu

      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
The fact that some CLIs have terrible UX does not invalidate the idea of CLIs.

~~~
lostmsu
It does invalidate the parable though.

~~~
NateEag
How so?

I read the parable as being about the infinite number of ways icons and GUIs
can be interpreted, thus making their inherent discoverability and clarity
low.

I don't see how listing CLI commands with terrible UX invalidates that point.

~~~
lostmsu
Because there's really no difference between terrible command line argument
names and terrible icons for the same commands.

~~~
NateEag
That may be true, but I think the parable is about well-chosen cases, not the
bad ones.

Icons don't have an intrinsic meaning the way words do, so some percentage of
people will find brand-new interpretations for icons, to a larger extent than
will happen with words.

That was my interpretation, at least.

~~~
lostmsu
> Icons don't have an intrinsic meaning the way words do

This is completely backwards. Icons can have intrinsic meanings - they can
literally depict an object or an action from the real world. Words are pure
abstracts humans made up, and can not exist outside of the context.

------
fit2rule
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
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
> 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.

------
tsimionescu
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.

------
majkinetor
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.

~~~
cuddlybacon
> 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.

Is it? Or is it that us compsci and computer engineering folks aren't used to
it and don't know much about it?

A Japanese instructional YouTuber I watch did a tour of his setup, and in it
he shows off a lot of automation he uses to make his work faster, more
consistent, and less error prone. The relevant part starts around here and
lasts throughout the rest of the video (its in english):
[https://youtu.be/TGgbSmCoZFA?t=390](https://youtu.be/TGgbSmCoZFA?t=390)

I think part of it is there is already a buttload of CLI driven tools for us,
so there isn't a need for us to rise above the skill floor for GUI automation.
But to just assume it is hard or impossible because we don't know is just the
same as people new to CLIs saying they are hard or impossible.

~~~
majkinetor
I don't assume. You assume stuff about me. :)

The GUI is heterogeneous world. Linux doesn't have tools AFAIK work mentioning
because it didn't need them due to CLI. Tools like xdotool are very limited.

Windows had much better tools, such as AutoIt, AHK etc. This was because they
all were created prior to PowerShell when there was no other option that
encompasses all apps. And PowerShell doesn't deal with GUI too, although you
could force it.

However, big part of those scripts depend on current theme, window sizing,
even positions. To create good script is not easy.

------
axilmar
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
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)

------
marmada
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.

~~~
jedevc
As I read it, the article is more about the concept of scripting in general -
and not about any specific language bash/zsh/powershell/etc.

I definitely agree, I think that POSIX-shell scripts can often be completely
unreadable and difficult to maintain. But I think the concept of scripting in
itself is fine, even though the implementations we might use today are
slightly outdated.

At the moment there's a huge number of interactive shells like nushell and
xonsh being built, but they don't really focus on scripting; I'd really love
to see more competitors attempting to take on the mess of bash scripts.

~~~
stephenr
> I think that POSIX-shell scripts can often be completely unreadable and
> difficult to maintain.

The same could be said for any language, if you're not familiar with it.

~~~
lhoursquentin
The thing is when you restrict yourself to only what POSIX specifies you don't
even have basic data structures, no array, no hash map not even local
variables, and that often leads to code that relies on multiple hacks.

For instance: you can't even slice "$@" which is the only array like construct
specified by POSIX (excluding unsafe splitting), so you end up shifting and
re-enqueuing with set -- "$@" "$1", which is unreadable.

Want to read a single character? Impossible with the POSIX read, but you can
workaround with dd

etc.

All those workarounds to POSIX limitations are fascinating, but it forces a
lot of arcane constructs, that's for sure.

And of course this is usually the point where you ask yourself if you've
chosen the correct language for the task, but that's another debate.

~~~
stephenr
> so you end up shifting and re-enqueuing with set -- "$@" "$1", which is
> unreadable.

How is that unreadable? Set all the positional arguments as is, then set the
first one again, into new positional arguments. I'm not sure why you want the
first arg twice, but thats your call.

Either way, it's hardly unreadable.

> And of course this is usually the point where you ask yourself if you've
> chosen the correct language for the task, but that's another debate.

It isn't another debate though. It's all the same debate: do you know the
language you're reading and/or writing? Do you know what it can do, what it
can be pushed to do, and what it really shouldn't do?

Those are all related to the same basic point: if you think Shell is
unreadable, I'd suggest it's because you don't know shell.

Remember readable means that you can read and understand it. Not that it's
written out in words that someone with on page 1 of "how to program for
dummies" can understand.

~~~
lhoursquentin
> Remember readable means that you can read and understand it

Yes you are right, my usage of "readable" was probably wrong there.

Maybe the point I was trying to make was less about the individual constructs
but more about how the lack of "common" features makes the whole program less
"understandable", or maybe less easy to get familiar with, simply due to the
amount of code needed to achieve a specific task.

The same way assembly is considered less "readable" than C. Not because
assembly is less readable on a line by line basis, it's even simpler, but
because of the number of lines and operations needed to achieve a simple task.

Basically it's easier to understand 10 lines than a 1000.

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

~~~
jabirali
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
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.

------
anonymfus
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
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
Thank you, my native language lacks articles.

~~~
kwhitefoot
Ah, in that case yours is a perfectly understandable interpretation. May I ask
which language?

~~~
anonymfus
Russian

~~~
kwhitefoot
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.

