Seems an interesting idea, but it's implemented in Python, which means it will never replace bash and probably not achieve any significant adoption unless they rewrite it in Rust first (which they should have written it in to begin with since they started in 2016). The reasons for that are that shells must start very quickly (due to subshells, local ssh, etc.), be fast, have no complex dependencies since they are use…
Why Create a New Unix Shell?
161–170 of 298 posts
Re: Why Create a New Unix Shell?
#162The idea to use a real programming language as a shell is a common one but I'm not sure it's really a problem that can be solved without reworking the kernel interface. Whatever you do pipes will still be byte streams, error handling will always be using integer return values, you'll always have stdin, stdout and stderr, job control and signal handling will always work pretty much the same way. The kernel interface e…
The whole point of these projects is to evolve the shell, go beyond the current bash standard to make the work with the shell more fun and more productive. Unix may seem to have limited default interfaces, but this was by design - the idea was, the programmer/user knows much better what he needs so let him build it. The system's role was shaped to provide robust universal mechanisms. Also, the current standard shell…
Finally? You don’t need a new shell. Write select(1). Job done.
Re: Why Create a New Unix Shell?
#163Earlier quoted context omitted.
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.
That was my main pain initially after I finally switched away from writing my scripts in Bash, but it actually turned out to be pretty easy. I wrote a quick helper function that does 99% of what I need: def _call(cmd_str): return subprocess.check_output(shlex.split(cmd_str)).decode("utf-8") Definitely a verbose monstrosity compared to doing it in bash, but more than worth avoiding the garbage fire that is Bash. And i…
Thank you for this.
Re: Why Create a New Unix Shell?
#164Lots of overlap in design goals with fish, except fish also places a premium on users interactively using the shell (which means friendlier in-repl experience but a balancing act when it comes to features). Fish’ auto completions are incredible, too. Best of luck to them. Another interesting shell to check out is elvish, lots of new ideas there (even if awkward to use). (Disclosure: I’m one of the core fish devs/main…
I totally love fish, it's the first shell that made me replace bash as my default shell (zsh was "just not enough" to justify losing compatibility, for me). But is this project really overlapping it? I see mostly fish as "UX" centered, while oilshell - as far as it's stated here - reminds me more of powershell (I found the idea of having a modern language behind it so cool when it was released, too bad it wasn't my e…
Why are you worries about losing compatibility? You can run bash within zsh.
Re: Why Create a New Unix Shell?
#165Earlier quoted context omitted.
> an IDE based on the language it was written in I recommend Emacs. Maybe not as a daily driver (it's a matter of preference), but for the experience. I recommend at least a month with it, make sure to write some original Lisp code for your customisations. (You WILL end up customizing it, the defaults are crap.) > or a window manager I recommend Awesome. The core is in C, but that's basically the low-level stuff, the…
Wait, what? You recommend Emacs but not StumpWM? I've used -- for longer periods of time, of course -- Awesome, Xmonad, i3, and dwm; while some of them are better at some things than StumpWM, StumpWM is the only one that provides an Emacs, live-hackable experience. So these days, I strongly prefer that.
I've been hearing about Emacs X Window Manager but haven't given it a shot yet https://github.com/ch11ng/exwm
Re: Why Create a New Unix Shell?
#166Earlier quoted context omitted.
Right, the system() function in C, which PHP probably uses, and is os.system() in Python, is DEFINED to run /bin/sh. You never know when a program might call it (although I agree it is almost always bad practice to use it -- use fork/exec instead.) So basically you should never make /bin/sh fish, because then you will no longer have a Unix system (according to POSIX).
PHP somewhat takes the user’s login shell, so I guess it’s yet a different system. If it was taking /bin/sh it would have been fine actually.
Don't blame the rest of the world for PHP's brain damage.
Re: Why Create a New Unix Shell?
#167Earlier quoted context omitted.
yeah I can actually imagine that. like using an IDE based on the language it was written in to extend and tweak it more easily, or a window manager etc.. actually now you mentioned it, barring possible performance issues I'd also like a Python distro
> an IDE based on the language it was written in I recommend Emacs. Maybe not as a daily driver (it's a matter of preference), but for the experience. I recommend at least a month with it, make sure to write some original Lisp code for your customisations. (You WILL end up customizing it, the defaults are crap.) > or a window manager I recommend Awesome. The core is in C, but that's basically the low-level stuff, the…
> 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 thing is that you can customize the third-party packages in the same way and just use the parts you like from them.
The other good thing about Emacs is that you don't need a separate window manager[1], and you don't need to use a separate command shell (Emacs comes with eshell), or to use a terminal emulator for SSHing into remote machines (eshell over TRAMP is absolutely amazing), or a file manager (Emacs comes with dired, which works over TRAMP which is amazing), or a...
Re: Why Create a New Unix Shell?
#168Earlier quoted context omitted.
The feature I use the most is automatic history search by typing part of a command and hitting UP to search the history. Doesn't bash have that same feature? Or is there some subtle difference between what you're describing and what bash does?
UP in bash swaps the commandline to your previous command, it does not search in your history. either way, please don't move your fingers all the way to your arrow keys for this.
I guess I'm still missing something here. In bash you can type the first couple of characters of a command and the PGUP (or whatever key you map for this) and it searches backwards through your history for matching commands. What does fish do differently?
Re: Why Create a New Unix Shell?
#169Earlier quoted context omitted.
It's an entrenched network effect. There's a lot of existing scripts written targeting POSIX shells, and there's an incentive to have all your distro maintenance scripts written in one language if possible. If you want to switch your existing distro scripts to fish, you need to rewrite a lot of stuff. If you want to start a new distro, "it's written in fish!" isn't a terribly compelling selling point, since I don't t…
> I don't think anyone is actively picking distros based on their tooling language. I would use the crap out of a Linux distribution built in python.
It could happen:
https://github.com/dcantrell/pycoreutils https://github.com/davidfischer/pycoreutils
http://u-root.tk/ does that for Go.
Re: Why Create a New Unix Shell?
#170Earlier quoted context omitted.
> consider these two groups of shell users: > 1. People who use shell to type a few commands here and there. > 2. People who write scripts, which may get into the hundreds or even thousands of lines. > Oil is aimed at group 2. If you're in group 1, there's admittedly no reason to use it right now. From my perspective, fish is basically the opposite of oil in that it mainly targets group 1 (admittedly I'm biased in th…
"to type a few commands here and there" Where's "my shell is my desktop environment"? :/
/pedantic
Everyone's desktop environment is a shell.
But any shell you like is suitable for that use case since it doesn't have to be compatible with anything other than your fingers.