Live data from Hacker News

Stronger Shell

m.odul.us

41–50 of 80 posts

Re: Stronger Shell

#41
post #13

Earlier quoted context omitted.

Is there a better shell? By which I mean more flexible, more consistent, and simpler. (Anyone who says 'zsh' is disqualified.) I've briefly looked at rc, but while it's significantly simpler and more orthogonal than sh it's got it's own weirdnesses; but the 'Design Principles' section here is worth reading: http://plan9.bell-labs.com/sys/doc/rc.html Surely there must be a usable shell wrapped around an actual modern…

> Is there a better shell? By which I mean more flexible, more consistent, and simpler. Yes, PowerShell. And it may actually arrive at Linux/Unix soon, due to CoreCLR. The specification is already open, but until now not much progress has been made towards bringing it uncrippled to Linux/Unix PowerShell is extremely consistent. Examples: All commands are strictly on the verb-noun form where there are only 40 or so "a…

That's true. I left MS-land years ago, and PowerShell is one of the few things I miss.

The only problem with PowerShell is that you need to write C# (or any other .NET language of course) if you want to create a real cmdlet (if I remember the name correctly). Other than that it's a quite nice shell and a sane procedural scripting language (again, with access to most of .NET).

The other, general problem with cmdlines/shells under Windows is the fact that they all work very differently than terminals that worked with type-writers 40 years ago. Which is what most console apps expect, for one reason or another, under Linux.

Re: Stronger Shell

#42

I've found that as soon as bash script goes to more than a couple lines, or as soon as it needs anything modestly complex, like "if" statements or functions, then it is almost always more efficient to write it in ipython. If you know python, then ipython is really superior way to do any ops and administration tasks. I've also found it easier to use for server setup than alternatives like ansible or puppet. I can just…

Perhaps it's just me, but flow control statements and functions in Bash have yet to scare me off. It's still faster, and readable, to write even moderately complex scripts in bash.

This is doubly true if you have to chain together external scripts - the "easy" ways to do it in Python can have some very major limitations.

I liken Bash scripting to Perl scripting. You can write safe, beautiful, and readable code in both. However, you can also create a summoning circle to the 5th circle of hell if you don't spend the effort to make it safe, beautiful and readable.

Re: Stronger Shell

#43
post #13

Earlier quoted context omitted.

Is there a better shell? By which I mean more flexible, more consistent, and simpler. (Anyone who says 'zsh' is disqualified.) I've briefly looked at rc, but while it's significantly simpler and more orthogonal than sh it's got it's own weirdnesses; but the 'Design Principles' section here is worth reading: http://plan9.bell-labs.com/sys/doc/rc.html Surely there must be a usable shell wrapped around an actual modern…

> Is there a better shell? By which I mean more flexible, more consistent, and simpler. Yes, PowerShell. And it may actually arrive at Linux/Unix soon, due to CoreCLR. The specification is already open, but until now not much progress has been made towards bringing it uncrippled to Linux/Unix PowerShell is extremely consistent. Examples: All commands are strictly on the verb-noun form where there are only 40 or so "a…

PowerShell is more like a worse Python and its core functionality is not the same as that of Unix shells.

PowerShell's commands ("cmdlets") are .NET classes within PowerShell, not arbitrary executables as in Unix shells. PowerShell's "object pipeline" is function chaining like in Ruby, not using OS-level pipelines as in Unix shells.

PowerShell is really just a .NET CLI, analogous to the Ruby's irb or Python's CLI, but dressed up to look like a Unix shell.

Re: Stronger Shell

#45

Just about everything I've learned about bash has been from the #bash IRC channel on Freenode. You'll see the same repeated warnings of not learning from the public web, due to the fact that misinformation spreads like a wild fire, and some articles out there are just flat out wrong (sort of like w3schools in the #css circle). There is just one thing I will never understand. The tired argument of "...but it isn't por…

> upon deployment, I'll be using bash

Unless you're on Ubuntu, in which case you will be using /bin/dash at occasionally entirely unexpected moments.

Re: Stronger Shell

#46
post #34

What suprises me is how often Bash is being used as 'the shell' and software projects use it, even when they could simply call /bin/sh instead. This is particularly bad for people who port software to other platforms (where BSD systems dont come with Bash, for example) and have to deal with pure shell scripts calling Bash. One recent example is CoreOS/etcd that's currently dropping Bash in favor of Sh, because they s…

It may be better for those people to call /bin/bash, and fail early and obviously for anyone who doesn't have that; than to call /bin/sh, attempt to write portably without really knowing the quirks of this variant of the language, and possibly fail subtly in obscure situations.

Re: Stronger Shell

#47

Just about everything I've learned about bash has been from the #bash IRC channel on Freenode. You'll see the same repeated warnings of not learning from the public web, due to the fact that misinformation spreads like a wild fire, and some articles out there are just flat out wrong (sort of like w3schools in the #css circle). There is just one thing I will never understand. The tired argument of "...but it isn't por…

Seconded. I can't live without fish, and I hear this "but what about my bash scripts?!" argument a lot. Unless you're actually sourcing the script, it has a magic "#!/bin/bash" line on top that makes it work correctly!

Re: Stronger Shell

#49
post #13

Earlier quoted context omitted.

> Is there a better shell? By which I mean more flexible, more consistent, and simpler. Yes, PowerShell. And it may actually arrive at Linux/Unix soon, due to CoreCLR. The specification is already open, but until now not much progress has been made towards bringing it uncrippled to Linux/Unix PowerShell is extremely consistent. Examples: All commands are strictly on the verb-noun form where there are only 40 or so "a…

That's true. I left MS-land years ago, and PowerShell is one of the few things I miss. The only problem with PowerShell is that you need to write C# (or any other .NET language of course) if you want to create a real cmdlet (if I remember the name correctly). Other than that it's a quite nice shell and a sane procedural scripting language (again, with access to most of .NET). The other, general problem with cmdlines/…

> The only problem with PowerShell is that you need to write C# (or any other .NET language of course) if you want to create a real cmdlet

What you say was true for PowerShell 1.0. Since 2.0 you have been able to create cmdlets and modules through scripting. An "advanced function" with [CmdletBinding] attribute is a full-featured cmdlet.

Now at version 5.0, PowerShell even has native syntax for creating classes and enums.

> The other, general problem with cmdlines/shells under Windows is the fact that they all work very differently than terminals that worked with type-writers 40 years ago

Not sure I'm following. The straight PowerShell engine is the most basic (typewriter-like) shell. But if you think in terms of support for terminal control characters - like VT220 - you'd be right. However, that is per specification not part of PowerShell but rather part of the console/shell process hosting the engine. The engine does indeed feature a number of hooks to make rich interaction possible. That is why the same engine can be used in the (admittedly) rather basic console "command prompt" of Windows pre-10 as well as with the ISE and Windows 10's not wuite so embarrassing "command prompt".

Re: Stronger Shell

#50
post #45

Just about everything I've learned about bash has been from the #bash IRC channel on Freenode. You'll see the same repeated warnings of not learning from the public web, due to the fact that misinformation spreads like a wild fire, and some articles out there are just flat out wrong (sort of like w3schools in the #css circle). There is just one thing I will never understand. The tired argument of "...but it isn't por…

> upon deployment, I'll be using bash Unless you're on Ubuntu, in which case you will be using /bin/dash at occasionally entirely unexpected moments.

For the want of a shebang, the core was dumped.
Post reply on HN