181–190 of 298 posts
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)
Lots 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…
> Another interesting shell to check out is elvish, lots of new ideas there (even if awkward to use). Elvish is pretty nifty, but the biggest failing point to me is that the fancy rich pipelines really work just for in-process stuff, which for me kinda loses the point of being a shell. Of course I do realize that rich (polyglot) interprocess pipelines is a difficult problem; some might say a pipe dream.
... | to-json | your-command | from-json | ...
fn f { to-json | your-command | from-json }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 agree that the age of 1000+ lines of shell script code should be over; just replace the shebang and use whatever other language you like instead. Unless you need something dependency-free, compilation-free, and portable, then God help you because sh it is. It's funny though, after decades of shying away from them I've now gone full circle and embraced Makefiles once more. Perhaps it's the cleanness of the bmake/pma…
Lots 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…
So many shells, but how come the virtual terminal hasn't got a revamp or popular alternative? I'd like to see more control over keybinding (e.g. on my machine pressing ctrl+del sends the same character as pressing ctrl+backspace). I understand this would be more a kernel change than a userland one. Screen tiling and visual 'tabs' would also be welcome additions. Not everyone needs a graphic environment, and I refuse…
Since dvtm also works as a terminal emulator, it seems to me that you could use loadkeys to setup various keycodes to send the proper vt100 escape codes. I've not tried it, but see no reason why it shouldn't work.
If you just want "No X install" you can use a frame buffer terminal (fbterm was one I used to use, but it doesn't appear to have been updated in a while, perhaps there is a spiritual successor, or maybe it already does what you want)
[edit] YAFT https://github.com/uobikiemukot/yaft looks like it's more up to date than fbterm.
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.
Earlier quoted context omitted.
What you are describing has been around since the late 1980s, IEEE POSIX: https://en.wikipedia.org/wiki/POSIX
Well, POSIX is pretty similar to what I mean, but it has a lot of low level stuff and I doubt that Microsoft has any ambitions to transform Windows into a POSIX compatible OS. I thought more about a higher level standard like adding Python, Lua or Qt to every installation by default. As some of those things are pretty heavy I doubt that it would be a wise choice to include them in POSIX. Just imagine a world were you…
erm, there's a big difference between a command scripting language and a programming language. These should be treated as different things.
I have years of experience using both, and I really don't want to be doing shell tasks in a programming language and I don't want to write programs in a shell language. Those sorts of hybrids are almost always mediocre. Horses for courses and all that.
There's a reason bash keeps being used - it's mature, it's simple, it's easy and people are productive with it.
Lots 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…
That is, Fish intends to be a useful interactive shell and if it also scriptable, that because you need scripting for it to be useful. Fish doesn't make a serious attempt being the language in which system scripts are programmed in.
Oil on the other hand is a concerted effort to formalise and rigorously implement the language which existing system scripts are written in. The author believes that is a starting point for a good interactive shell -- but programming comes first.
As for new language, I feel like if you want to script things, you can use ruby or python, hell, perl will do and you could be fine. I don't want to be unfair to this effort, I just feel that it is not for me and I am tinkerer.