Live data from Hacker News

The Renaissance of the Shell?

effective-shell.com

31–40 of 69 posts

Re: The Renaissance of the Shell?

#31
post #23
post #9

Earlier quoted context omitted.

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)

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…

I get the point about moving code around, I guess it can be problematic with some tools. In my experience PyCharm gets it right, and when moving around code in vim I can just change the indent level on the whole block at once, but it is dangerous to miss a line at the end and move it by mistake one level up.

Also I feel like changing the indent of the cursor (manually) when exiting a block is more or less the same work as typing }, and I got used to it to the point it becomes automatic.

But I guess at the end of the day it's a matter of priority. Is that more important than having special syntax for dicts? I really like the fact that we have the tuple/list/dict distinction, and would be great if we had a different paren type for sets (which would have eliminated the {} vs set() issue). On the other hand, going with begin..end or if..fi blocks would be even more antagonizing than using whitespace.

Re: The Renaissance of the Shell?

#32
post #18

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

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.

Re: The Renaissance of the Shell?

#33

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

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…

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.

Re: The Renaissance of the Shell?

#34

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…

> 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 p…

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

Re: The Renaissance of the Shell?

#35
post #28

Earlier quoted context omitted.

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 worl…

I disagree. While what you're saying is true there's other side to the issue. The command line tools are simply more versatile and configurable. We can try to take git clone command as an example and try to design a GUI dialogue which would allow to use all the options it has. I think it is very hard and you will end up with something looking scarier than space shuttle cockpit. I believe it'll take roughly the same t…

I think that's more because the standard git client was designed with command line usage in mind and UI usage had been ignored at that step. Had the goal been a hybrid GUI/CLI from the start than the entire git workflow might look different (which wouldn't be a bad thing IMHO, because the git command line UX isn't all that great either).

Re: The Renaissance of the Shell?

#36
post #12

Earlier quoted context omitted.

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…

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

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.

Re: The Renaissance of the Shell?

#37
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".

Re: The Renaissance of the Shell?

#39
post #38

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?

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

Re: The Renaissance of the Shell?

#40

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

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

Post reply on HN