Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Renaissance of the Shell?

effective-shell.com

Post reply on HN
Print view View original

51–60 of 69 posts

Re: The Renaissance of the Shell?

#51

Post by stephenr »

lhoursquentin wrote: post #36
stephenr wrote: post #21

Earlier quoted context omitted.

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

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

Re: The Renaissance of the Shell?

#52

Post by dllthomas »

cringepirate wrote: post #44
cheph wrote: post #41

Earlier quoted context omitted.

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

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…

My assessment, from a history with a lot of bash and a little, not terribly recent PowerShell, is that PowerShell wound up in a pretty common position of having a better language but a worse UX. Picking out why (wrt UI in general, not powershell in particular) is an ongoing interest...

Re: The Renaissance of the Shell?

#53

Post by lhoursquentin »

stephenr wrote: post #51
lhoursquentin wrote: post #36

Earlier quoted context omitted.

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…

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

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

Re: The Renaissance of the Shell?

#54

Post by cuddlybacon »

majkinetor wrote: post #17

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…

> 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

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.

Re: The Renaissance of the Shell?

#55

Post by NateEag »

smichel17 wrote: post #45
flohofwoe wrote: post #35

Earlier quoted context omitted.

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

This is my criticism of most git GUIs. They try to provide 1:1 functionality with the command line. But this defeats the purpose -- instead of making it more obvious what every button will do, it adds an additional layer of complexity where now I have to guess which CLI operation that button maps to. But the point of the GUI is that it's more accessible than the CLI. If you have to learn the CLI interface anyway in o…

Magit actually solves this problem, to a certain extent. It makes Git more discoverable and easier to use, IMO.

Prior to trying it I was a hardcore git terminal user. I still drop to the terminal sometimes, but magit has won me over for the day-to-day normal workflows.

You have to use Emacs for Magit, as it's an Emacs Lisp package, but it really is worth trying in its own right.

https://magit.vc/

Re: The Renaissance of the Shell?

#56

Post by NateEag »

lostmsu wrote: post #48
thesuperbigfrog wrote: post #39

Earlier quoted context omitted.

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

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.

The fact that some CLIs have terrible UX does not invalidate the idea of CLIs.

Re: The Renaissance of the Shell?

#57

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

Re: The Renaissance of the Shell?

#58

Post by koffiezet »

cringepirate wrote: post #44
cheph wrote: post #41

Earlier quoted context omitted.

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

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…

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.

Re: The Renaissance of the Shell?

#59

Post by Riverheart »

cheph wrote: post #41
ktpsns wrote: post #3

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…

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

Not everything in Windows is a file so they created a shell based around pipeable objects and improved shell's logic handling. A bunch of terse commands for piping out text streams from files doesn't make a lot of sense here.

Re: The Renaissance of the Shell?

#60

Post by cringepirate »

koffiezet wrote: post #58
cringepirate wrote: post #44

Earlier quoted context omitted.

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…

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.

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.

Post reply on HN