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

221–230 of 298 posts

Re: Why Create a New Unix Shell?

#221

Post by chubot »

tambourine_man wrote: post #33

A little tangential, but I keep wondering if Apple is developing its own shell or will adopt one with a more liberal licence such as Oil or Fish. I mean, they can't keep using Bash 3 forever, right? (Hope)

I'm not a frequent Mac user, but I wonder about the bash 3 thing too.

Maybe they just expect you to install your own shell? I think a lot of people do that with homebrew?

I think Apple has largely expunged shell scripts from the startup process with launchd too? That is like their systemd.

Re: Why Create a New Unix Shell?

#222

Post by executesorder66 »

z3t4 wrote: post #50

I spent the day making a virtual terminal ... I think the terminal is an unnecessary layer. All program UI is limited by this 40+ year old technology that is the terminal. Instead of making a new shell, make a shell + new user-interface.

You might be interested in this: https://github.com/withoutboats/notty

Re: Why Create a New Unix Shell?

#223

Post by sedachv »

Scarbutt wrote: post #179
sedachv wrote: post #167

Earlier quoted context omitted.

> the defaults are crap As someone who has recently joined the 1k LOC Emacs configuration file club, I have to disagree. The default settings are a well thought out starting point that needs minimal tweaking to get to exactly where you want. I try out a lot of packages on ELPA, and many that purport to provide alternatives for defaults end up being inferior to using the defaults with some small tweaks. The convenient…

eshell over TRAMP? how does that work?

Any pathname in eshell can be a TRAMP pathname on a remote machine. So you just cd to a remote directory and eshell will run commands on the remote machine. You can redirect remote command output to a local file, local command output to a remote file, cp from remote pathname on machine A to remote pathname on machine B, etc.

Re: Why Create a New Unix Shell?

#224

Post by xiaq »

chubot wrote: post #210
xiaq wrote: post #174

Earlier quoted context omitted.

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

Good point about bindings and completion scripts. Binding commands themselves are not big problems, the problem is replicating readline commands, there are loads of those.

I'm not sure how much work one needs to do to implement things like extended globbing, but my gut feeling is that once you can parse them it's more than half done. The functionalities are quite simple, as my impression goes.

I was mainly thinking about environment variables, aliases and wrapper functions when I said sourcing bashrc; that's probably what most people's bashrc files are mostly made of.

We totally should revive our alternative shells thread! I'll try to summarize my progress in the last year. Congrats on your progress with Oil too! ^_^

Re: Why Create a New Unix Shell?

#225

Post by arghwhat »

sethrin wrote: post #122
arghwhat wrote: post #77

Earlier quoted context omitted.

Back when I started programming, I wrote 1000+ lines of shell scripts. Now, I quite seriously believe that a 1000 line shell script only exists out of error. I still occasionally end up doing 2-300 line dense shell scripts, but not without feeling very dirty along the way. Either split into small, simple shell scripts (which is fine), or a different language. In the cross platform build pipeline at work, I keep a str…

Bash is flat-out not a scripting language . It is a command language . It does not support typed variables, or named parameters, or any number of basic scripting language features. It technically does not even provide an 'if' construct. It's sufficient as a 'glue layer', and the Unix toolchain is nice, but it provides next to nothing in the way of abstraction, and that's liable to become a problem closer to the 1000…

This one gets it. What I want from an interactive shell is not what I want from a programming language.

Re: Why Create a New Unix Shell?

#226

Post by arghwhat »

racer-v wrote: post #110
arghwhat wrote: post #77

Earlier quoted context omitted.

Back when I started programming, I wrote 1000+ lines of shell scripts. Now, I quite seriously believe that a 1000 line shell script only exists out of error. I still occasionally end up doing 2-300 line dense shell scripts, but not without feeling very dirty along the way. Either split into small, simple shell scripts (which is fine), or a different language. In the cross platform build pipeline at work, I keep a str…

> I quite seriously believe that a 1000 line shell script only exists out of error. Perhaps the best use case for Oil is to provide a debugging environment where you can figure out what your legacy shell scripts are doing, and rewrite them in another language. > Unlearning bash-isms is not a liberty I can afford, as I need to be proficient when I SSH into a machine I do not own or control. This is a slippery slope. I…

> Perhaps the best use case for Oil is to provide a debugging environment where you can figure out what your legacy shell scripts are doing, and rewrite them in another language.

My approach to that problem is to just instrument scripts to write out the command line every time a tool is called, and infer the logic behind it. When I started here, build/package/test on Windows were controlled by 6000 lines of Perl... A printing version of system() and a few days later, it's 40 lines of batch and 150 lines of Python.

> Forcing yourself to always use the lowest common denominator of software is not a fun path.

Never said it was fun. Also, I need to be able to use the lowest common denominator, I don't necessarily have to be the lowest common denominator. I use a configured zsh and nvim instance myself, but I take care to ensure that if I'm stuck with vi and (ba|da|k|c)sh, I'm still productive. The core behavior of my VIM instance stays close to stock, but it has a bunch of extras like fuzzy search, linting, a nice theme, etc.

And, if I can make a choice without caring, my needs for a shell and a programming language are in direct opposition. I want my shell to put all of its energy into a useful interactive experience.

Re: Why Create a New Unix Shell?

#227

Post by arghwhat »

rollcat wrote: post #145
racer-v wrote: post #110

Earlier quoted context omitted.

> I quite seriously believe that a 1000 line shell script only exists out of error. Perhaps the best use case for Oil is to provide a debugging environment where you can figure out what your legacy shell scripts are doing, and rewrite them in another language. > Unlearning bash-isms is not a liberty I can afford, as I need to be proficient when I SSH into a machine I do not own or control. This is a slippery slope. I…

> Forcing yourself to always use the lowest common denominator of software is not a fun path. Second this. Been there, and back, and there again, and recently back again. Customize the hell out of your shell, make it your place, make it nice. You're spending your day there, every day. Treat it like you'd treat your work desk. If it's a stranger's machine, well, OK, suffer through the 10 minutes of troubleshooting, an…

My zsh/nvim/... dotfiles are portable and compatible with FreeBSD, macOS and a bunch of Linux distributions, but it's absolutely unacceptable to run those on a machine I don't control. You don't mess with configuration on another guy(ette)'s server.

My setup is customized, but the core experience is kept relatively untouched. If someone experiences a problem, I need to be able to debug it in place efficiently. I write drivers for the company's hardware for a living—troubleshooting takes more than 10 minutes.

Re: Why Create a New Unix Shell?

#228

Post by arghwhat »

dsnuh wrote: post #203
jeremyjh wrote: post #153

Earlier quoted context omitted.

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/

never use os.system. os.system is a hack.

Subprocess is a bit verbose to use, though... A wrapper would be nice.

Re: Why Create a New Unix Shell?

#229

Post by z3t4 »

jiggunjer wrote: post #186
z3t4 wrote: post #50

I spent the day making a virtual terminal ... I think the terminal is an unnecessary layer. All program UI is limited by this 40+ year old technology that is the terminal. Instead of making a new shell, make a shell + new user-interface.

A day? It would take me a month reading the kernel code just to know where to start and what to replace.

I half-hearted implemented the "vt100" ANSI Escape sequences in the most naive way possible into an existing GUI application. Did not touch any kernel code.

I think the modern "terminal" is the Browser. With URL's instead of file paths. But I think it's maybe time for something new. In the 70's we got the terminal. 20 years later we got the browser. Now another 20 years have passed. What's the next step ? Terminal -> Browser -> ?? -> AI ?

Re: Why Create a New Unix Shell?

#230

Post by rendaw »

kevlar1818 wrote: post #71

> 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. Excellently put. POSIX shell languages have fantastic capabilities you just can't get in most othe…

I disagreed with this strongly.

> concurrent processes

Job control is disabled in shell scripts, and your only other option is juggling process ids. Combined with nearly nonexistent exception handling using anything more than a single process at a time is like pulling teeth.

Things like ssh have super awkward workarounds using control pipes.

I'm not sure I've ever seen a shell script use concurrent processes in the wild.

Python's subprocess library is excellent and makes concurrent processes a breeze.

> file system

With some minor exceptions, I can't think of any FS ops I'd do in shell that isn't just a couple letters longer in Python and 10 times more flexible.

The only reason to use shell is that it has a simple syntax for pipelines.

I rewrite any script > 2 lines in Python and have no regrets.

Post reply on HN