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

Four features that justify a new Unix shell

oilshell.org

Post reply on HN
Print view View original

61–70 of 185 posts

Re: Four features that justify a new Unix shell

#61

Post by coldtea »

boogies wrote: post #40
solarkraft wrote: post #16

OSH is probably a good incremental improvement over bash, but I also enjoy using the significantly more tradition-breaking Powershell with its object oriented nature. It feels a lot more like programming and actually gives you useful suggestions right inside the terminal! On Linux the auto completion behavior is luckily less obnoxious than on Windows and it doesn't have the multi second startup delay either.

> feels a lot more like programming When I want to program a script, I can use a scripting programming language like Python with its object oriented nature. When I want to interactively command my computer I can use a shell like bash or zsh. Do one thing and do it well.

>Do one thing and do it well.

That's how we got in today's mess.

Do the things people want in a coherent, cohesive, well thought out way - don't combine N independent programs that can barely took to each other with stringly typing and ad-hoc parsing...

Re: Four features that justify a new Unix shell

#62

Post by paleogizmo »

ilaksh wrote: post #33

Just in case people are looking for something really new in a shell: besides Oil, check out fish shell. The killer feature for me is its autocompletion -- its basically psychic.

Fish is amazing as an interactive shell. I've had it as my default for a couple years now. Oil isn't the only game in town for object shells, there is also NuShell and Elvish which follow the fish model of abandoning POSIX compatibility for ease of use. I think OP had mentioned it elsewhere on this thread, but I've found object shells mostly useful for scripting that involves a lot of calling and processing the output of programs that produce structured data. I mostly use PowerShell for this, though Nushell/Elvish/Oil seem to be actually usable now. I'm pretty excited that the Unix community seems to finally be moving on from defending the old unstructured text model of program interaction to embracing the benefits of object shells. Whatever you think of its implementation, PowerShell is a great idea.

Re: Four features that justify a new Unix shell

#63

Post by teyc »

wvenable wrote: post #37
solarkraft wrote: post #16

OSH is probably a good incremental improvement over bash, but I also enjoy using the significantly more tradition-breaking Powershell with its object oriented nature. It feels a lot more like programming and actually gives you useful suggestions right inside the terminal! On Linux the auto completion behavior is luckily less obnoxious than on Windows and it doesn't have the multi second startup delay either.

As a software developer, not a sysadmin, I have real trouble with Powershell. They didn't tradition-break enough and it's like some bastard child of .NET and Bash. I think most people have an easier time understanding https://www.cs-script.net . It's powerful but the syntax and semantics are maddening. It's going to be entrenched in the Windows world for the next 20 years and prevent anything better from coming along…

I've been using Powershell for a few years now, there are some minor warts, but those can fit in a single page. I found it rather nice for shell scripting.

Re: Four features that justify a new Unix shell

#64

Post by kbenson »

pierrebai wrote: post #60

I'm sorry to say to for me, shell scripting has lost. All my scripts are written in Python, which a thin shell script wrapper to launch it. Look at Oil. It tries hard to be bash compatible with optional buy-in to extension. Just use a superior language and give up on shell scripts, that's my advice.

I agree. Generally I find the approach to have a few tools that work well in their specific niches to be superior to having one tool for all jobs.

I use a shell for shell stuff, I use a scripting language for most other stuff, and I might use a systems level compiled language (or a scripting language that calls into a compiled library) for more performance specific needs. If you're already within a specific area and only need to venture into the other for a minimal aspect of the current project, it can be useful to stick with what you're in, but you quickly reach the point where it's better to choose a better tool because of diminishing returns from using a tool for something it's not good for.

Maybe the hammer in the hand is fine for prying the single board off fence or wall, but if you're going to be doing it to ten or twenty boards, maybe walking over to the shed to get the crowbar will save a lot of time and effort in the end.

Re: Four features that justify a new Unix shell

#65

Post by folmar »

e12e wrote: post #49
Splognosticus wrote: post #23

Earlier quoted context omitted.

> - splitting pipes to separate flows (e.g one flow for stderr, one for stdout). Think of it as a graph. Could you elaborate a little on what you mean by this? bash already has the ability to redirect STDERR and STDOUT independently, and when you introduce named pipes into the mix things can get really fancy (probably too fancy, this is about where your script stops being a script and starts being a program written i…

I imagine an easy/intuitive way to set up FIFOs for stdout/stderr with redirection, maybe? A way to say: for this following section, I want stderr to go trough "|sort -n|logger -t DEBUG -f -" and standard out to go through (... Other pipeline)?

command 2> >(sort -n|logger -t DEBUG -f -) | other pipeline

Re: Four features that justify a new Unix shell

#66

Post by R0b0t1 »

pierrebai wrote: post #60

I'm sorry to say to for me, shell scripting has lost. All my scripts are written in Python, which a thin shell script wrapper to launch it. Look at Oil. It tries hard to be bash compatible with optional buy-in to extension. Just use a superior language and give up on shell scripts, that's my advice.

There is a better option and its name is Perl. Perl mixes the ins of shell scripts like easy argument and output passing with complex and easy to use control structures.

You could use Python, but having been forced to use Perl extensively Perl is the superior choice for a complex shellscript-like workload. There's less boilerplate in Perl. There's a couple Python projects that come close like Fabric, but Perl was literally made for this type of workload.

Re: Four features that justify a new Unix shell

#67

Post by jonahx »

pierrebai wrote: post #60

I'm sorry to say to for me, shell scripting has lost. All my scripts are written in Python, which a thin shell script wrapper to launch it. Look at Oil. It tries hard to be bash compatible with optional buy-in to extension. Just use a superior language and give up on shell scripts, that's my advice.

The author addresses this argument:

> However, Python and Ruby aren't good shell replacements in general. Shell is a domain-specific language for dealing with concurrent processes and the file system. But Python and Ruby have too much abstraction over these concepts, sometimes in the name of portability (e.g. to Windows). They hide what's really going on.

From: http://www.oilshell.org/blog/2018/01/28.html#i-dont-understa...

Re: Four features that justify a new Unix shell

#68

Post by R0b0t1 »

teyc wrote: post #63
wvenable wrote: post #37

Earlier quoted context omitted.

As a software developer, not a sysadmin, I have real trouble with Powershell. They didn't tradition-break enough and it's like some bastard child of .NET and Bash. I think most people have an easier time understanding https://www.cs-script.net . It's powerful but the syntax and semantics are maddening. It's going to be entrenched in the Windows world for the next 20 years and prevent anything better from coming along…

I've been using Powershell for a few years now, there are some minor warts, but those can fit in a single page. I found it rather nice for shell scripting.

I use and recommend powershell as well but only because it is best in class at interacting with Windows components. I think there are better general solutions.

Re: Four features that justify a new Unix shell

#69

Post by mypalmike »

quotemstr wrote: post #36

These things might justify making a non-Bourne shell, but they don't justify making a greenfield shell: the fish shell already has all these features, and since we all benefit by reducing shell fragmentation, I think the author ought to work on hacking on fish more before making yet another shell.

Shall I declare what you "ought to work on" in your free time too?

Re: Four features that justify a new Unix shell

#70

Post by [deleted] »

chubot wrote: post #24
solarkraft wrote: post #16

OSH is probably a good incremental improvement over bash, but I also enjoy using the significantly more tradition-breaking Powershell with its object oriented nature. It feels a lot more like programming and actually gives you useful suggestions right inside the terminal! On Linux the auto completion behavior is luckily less obnoxious than on Windows and it doesn't have the multi second startup delay either.

I should turn this into a FAQ, but PowerShell is natural on Windows, where the OS provides objects (either via the .NET VM, or COM and .DLLs, etc.) A Unix shell like bash or Oil is natural on Unix, where the OS uses text files. And in distributed systems where data is JSON, YAML, XML, protobuf, msgpack, etc. not objects. So basically shell is a "situated" language, and the easy of accomplishing any given task depends…

[deleted]
Post reply on HN