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

Why Create a New Unix Shell?

oilshell.org

Post reply on HN
Print view View original

201–210 of 298 posts

Re: Why Create a New Unix Shell?

#201

Post by sethrin »

jeremyjh wrote: post #153
Macha wrote: post #144

Earlier quoted context omitted.

My personal threshold for upgrading from shell to Python is about "I need an if statement".

Yeah I've seen that Python code. Every other line is a call to os.system('...').

You say that like it's a bad thing. Bash does not support niceties like typed variables, named parameters, or classes. Its conditional operator is an external program with a required last argument to make it look like sane syntax. Little things like interpolating variables, array access, or taking command line options are awkward and prone to failure. It doesn't have the insane syntactical issues that csh had, and POSIX is ubiquitous, but that's a pretty low bar and an inadequate justification for using a fundamentally limited language. Python could have a nicer syntax for invoking the system interpreter -- personally, I think that Ruby's backticks feel very Unixy -- but if there is a better interpreter on the system there is no reason not to use it. Even if half your code is calling out to the shell, you still have the benefits of typed variables, a nicer syntax, the ability to abstract code into classes, a variety of nice enumeration options, and all the other benefits of a "real" programming language.

Re: Why Create a New Unix Shell?

#202

Post by racer-v »

PuercoPop wrote: post #194
racer-v wrote: post #141

Earlier quoted context omitted.

Gentoo is basically this. I learned Python by writing .ebuilds (their package format is a short Python script that downloads and builds whatever software you're installing).

Although emerge is written in python, Afaik ebuilds are bash scripts.

Ah right you are, thanks - I remember learning Python and switching to Gentoo about the same time, but as David Hume warned us, it's hard to infer causality from proximity.

Re: Why Create a New Unix Shell?

#203

Post by dsnuh »

jeremyjh wrote: post #153
Macha wrote: post #144

Earlier quoted context omitted.

My personal threshold for upgrading from shell to Python is about "I need an if statement".

Yeah I've seen that Python code. Every other line is a call to os.system('...').

I've had good luck with this module. Much nicer than using os.system() imo.

https://amoffat.github.io/sh/

Re: Why Create a New Unix Shell?

#204

Post by bobbyi_settv »

rocqua wrote: post #37
castis wrote: post #4

I see that this person has opted not to use python 3 because it is 'less-suited to shell-like problems' than python 2. In an effort to understand the reasons for actively choosing against 3, does anyone know what problems those would be?

The few times I tried to de shell like things in Python, the absolute pain of actually running commands and getting to their output might be part of the reason. What is A=$(cmd) in bash is an absolute pain in python.

subprocess.check_output(cmd) runs a command and returns the output, raising an exception if the command fails.

Re: Why Create a New Unix Shell?

#205

Post by StreamBright »

chubot wrote: post #106
StreamBright wrote: post #79

Earlier quoted context omitted.

One question though: Do you really need 1000+ lines of shell scripts? I almost have 20 years with shell scripting and I still have the rule of not writing longer than 1-2 page shell scripts and use something else for longer projects or break it down to much smaller chunks and invoke the parts with a main.sh. Fish is a for making software engineering and system administration easier by having functionality like comman…

See https://news.ycombinator.com/item?id=16278141

This is not an answer just a problem statement.

Re: Why Create a New Unix Shell?

#207

Post by sjellis »

terminalcommand wrote: post #193
throwaway7645 wrote: post #148

Earlier quoted context omitted.

Early Smalltalk and Lisp systems were those langs all the way down. Using emacs with Common Lisp or using Pharo Smalltalk can give you a feel for this, but not exactly the same thing as a Symbolics lisp machine or the Xerox Alto. Alan Kay has a presentation where he shows the entire OS, word processor, networking stuff, IDE, paint programs...etc was an insanely small amount of code and everything was user configurabl…

I don't know if it's just me, but I don't feel like I'm using a computer when using Windows. After using OpenBSD exclusively for weeks (my laptop broke, so I had to repurpose an old netbook with OpenBSD), I felt bored and limited in Windows. I tried Powershell, but -mostly because I don't know much about it- it didn't give the same feeling. The thing that is working for me is to explore VB.net . It is really an inter…

"In VB.net I feel like I'm slowly reexperiencing the joy I've felt in my earlier days of programming."

Ruby was the first language that I experienced that got out of the way, so I felt like I could think about what I was trying to achieve, rather being distracted by house-keeping. Of the other languages that I've tried, I've only gotten close to the same feeling with JavaScript, Go and Python.

I suspect that a lot of it is to do with your own mind-set at the time: I first learned Python as an applications language, with all of the add-on tools and baggage, and didn't like it much, but recently I wrote a one-file, no-dependency thing to do exactly one job in Python, using just the standard library, and it was a joy.

The difference was, I think, that I did not feel the internal pressure to meet best practices, and could just write the code. For some languages, the stuff that you are supposed to do and the tools that you are supposed to use are a heavy burden.

Re: Why Create a New Unix Shell?

#208

Post by dilap »

jernfrost wrote: post #96
jhillyerd wrote: post #2

After using fish for 3 years, I'm finding there is very little reason to have my login shell maintain backwards compatibility with bash. The only time I run into issues is when a command expects manipulate environment variables via bash syntax. I think the fish documentation WRT to scripting could be much better, but the language is more elegant than bash or PowerShell IMHO.

Interesting seeing so many fish fans. I absolutely love fish. It makes my everyday shell usage so much nicer. But it seems like a totally unknown shell to most people. I never see anybody else use it at any job I've had. I did use fish a bit as a script language, but I decided for anything of any size I much prefer Julia. For typical file system navigation, fish is better, but Julia is actually pretty decent as a she…

I remember a few years ago poking at julia and thinking it would make a really good shell language. The thing that killed it for this use at the time was slow startup; is that better now?

Re: Why Create a New Unix Shell?

#209

Post by geewee »

ComputerGuru wrote: post #130
CGamesPlay wrote: post #20

Earlier quoted context omitted.

> The only time I run into issues is when a command expects manipulate environment variables via bash syntax. And in my experience 90% of those are in the form `FOO=bar command` which can be replaced with `env FOO=bar command` and works just fine in fish.

Both support for `&&` and `||` (instead of `and` and `or`) as well as supporting `FOO=bar command` are under consideration for fish 3.0 to ease the migration path. The former is pretty much going to happen, the latter if we get around to it, DV.

This would be much appreciated. I know there are a few people on my team that cam't use fish due to our npm scripts needing to be compatible with cmd

Re: Why Create a New Unix Shell?

#210

Post by chubot »

xiaq wrote: post #174
chubot wrote: post #131

Earlier quoted context omitted.

Ion looks great, but its goals are different -- most importantly, it doesn't provide an upgrade path from bash. (This is also the biggest difference between Oil and fish, Oil and Elvish, etc.) I talked with the authors of Ion on github almost a year ago. Ion was influenced by Oil, in particular this post: http://www.oilshell.org/blog/2016/11/06.html

FWIW, POSIX emulation is on my TODO list: https://github.com/elves/elvish/issues/205 Not sure whether I will actually get to it though. Parsing sounds like a lot of headache. Your work is very impressive, but I’m not sure I will want to go through that... :)

Yeah, running ~/.bashrc is tough, and I'm not sure even Oil will get to it. Not only do you need parsing and execution of the bash language, but you also need builtins like bind and set -o vi (i.e. see "help bind").

Maybe bind is easier than I think; maybe it's just a few readline calls. I haven't looked into it.

But also, I noticed almost no shell scripts use extended globs like @(foo|bar), whereas the bash-completions package uses them EVERYWHERE. Completion scripts are almost like a different dialect than other shell scripts.

If you want to source /etc/bashrc on most distros, you're going to end up with thousands and thousands of lines of plugins from the bash-completions project.

The parsing is a big headache, but I think it forced me to learn how people use shell, which will benefit Oil.

It's been a full year since our alternative shells thread... might be time to revive it and see what's changed! Congrats on the Elvish releases!

Post reply on HN