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

271–280 of 298 posts

Re: Why Create a New Unix Shell?

#271

Post by JdeBP »

aplorbust wrote: post #143

This keeps showing up on the front page. No doubt it will have users. Lets say there are two uses of a shell: 1. interactive and 2. non-interactive (scripting). Lets imagine the commandline user is learning about her OS. She learns it is heavily reliant on shell scripts to build and (if desired) to automate starting services. She realises that to understand the OS she will have to learn the shell that the OS develope…

It was submitted once.

* https://news.ycombinator.com/item?id=12600807

Laurent Bercot no longer has xyr page about the compilation process. I have since picked up some of the slack there. Although I don't go into things like the way that M. Bernstein avoided autotools.

* http://skarnet.org/software/compile.html

* http://jdebp.eu./FGA/slashpackage.html

Re: Why Create a New Unix Shell?

#272

Post by JdeBP »

zapita wrote: post #10

Finally a modern shell that understands the importance of COMPATIBILITY! This gives it a realistic chance of getting real adoption. Shells like zsh and fish will never get mainstream adoption because they are not compatible with bash.

If the questions asked on Unix and Linux Stack Exchange are anything to go by, the Z shell already has mainstream adoption.

But of course your argument has the fundamental flaw that the Bourne Again, Korn, and even Bourne shells were not compatible with their various predecessors, but that turned out to be not as problematic in practice as you paint it to be. And we've had all sorts of things gaining "real adoption" over the years, from Norton Commander clones to Perl. The world is nowhere near as narrow as you think.

Re: Why Create a New Unix Shell?

#273

Post by JdeBP »

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.

Actually, far from all, most program UI is not so limited.

Learn from history. In the 1980s the world improved on the terminal paradigms, with TUIs that included things like directly addressable output buffers and unified and standardized keyboard/mouse input event streams. In parallel, GUIs took hold, and there are nowadays a lot of GUI programs in the world.

* https://news.ycombinator.com/item?id=16014573

Re: Why Create a New Unix Shell?

#274

Post by rollcat »

jsmthrowaway wrote: post #155
rollcat wrote: post #145

Earlier quoted context omitted.

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

While I appreciate your perspective, I think it’s more from the “occasional SSH to a foreign server” mindset. Scaling “the way I work in a shell” to huge fleets is a nonstarter, and as a working SRE, has been the biggest thing holding me back from zsh, fish, and other alternatives. OTOH, I’m also against, for example, installing zsh fleetwide in production fleets to accommodate choosy folks. So I’m on both ends of th…

- As soon as you have more than 5 boxes, you need different tools for your everyday tasks, interactive SSH sessions just don't work. But you know that already.

- So you've found yourself SSH'ing into a particular box, because that's just the best way to work on a problem. Either it's a pet box (in which case it makes total sense to drop your dotfiles there), or it's a cattle box and you don't care about the trash you left behind, because autoscaling will clean it up for you.

Re: Why Create a New Unix Shell?

#275

Post by rollcat »

_0w8t wrote: post #220
rollcat wrote: post #137

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

At some point I realized that I wasted months in those rabbit holes customizing and tweaking shell configs, window managers and Emacs. Any gain in productivity (which may not even be there as it is rather subjective) was not able to offset it. So I stopped it. These days I just use Gnome Shell with a single extension to fix something that I cannot get used at all, simple bash config to setup environment for developme…

https://news.ycombinator.com/item?id=16152639 :)

Re: Why Create a New Unix Shell?

#276

Post by rollcat »

Goopplesoft wrote: post #195
rocqua wrote: post #37

Earlier 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.

A while back I wrote a little test snippet[1] to see how good such an interface can get in python. _("ls -la") | _(lambda x: x.split()[-1]) | _(lambda x: os.path.splitext(x)[1]) I wonder if there's a complete version of something like this out there. You can probably get pretty far staying in Python-land, plus, everything else is free (data types, standard library, adoption, etc). [1] https://gist.github.com/pnegahda…

Try playing with __getattr__, I'm sure "_.method" instead of "_(lambda x: x.method())" could be a thing.

Re: Why Create a New Unix Shell?

#277

Post by throwaway7645 »

scroot wrote: post #253
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 feel you. This guy is working on an interesting project called the Reform laptop [1]. You might have seen this already. He will eventually have it run his own lisp (called "Interim") all the way down. [1] http://mntmn.com/reform/

Sounds neat, I'll check this out.

Re: Why Create a New Unix Shell?

#278

Post by sedachv »

lorenzhs wrote: post #252
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…

My favourite Emacs goodie to highlight is magit because it really changed the way I use git. All of a sudden, it's incredibly simple to (un-)stage individual hunks, etc. And of course it works over TRAMP, too :) org-mode is a good one, too, but I feel like I've barely scratched the surface there.

The hunk feature of magit is great; you can easily stage/unstage not only at the hunk granularity but also arbitrary lines using the selection. Being able to easily do that was something I really missed when I moved from darcs to git.

When it comes to magit and TRAMP, definitely the best part is with-editor[1]. This is one of those ingenious "why didn't I think of this?" hacks to let you use your local Emacs as EDITOR on remote machines without having to do SSH port forwarding for emacsclient.

[1] https://github.com/magit/with-editor

Re: Why Create a New Unix Shell?

#279

Post by racer-v »

deadbunny wrote: post #255
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…

> "don't make your own custom aliases / shell functions, because they won't be available when you SSH to another machine." If you're logging into a machine to the point you're editing files or require your customizations in this day and age you're doing it wrong IMHO.

Doing what wrong?

Re: Why Create a New Unix Shell?

#280

Post by dfox »

kevin_thibedeau wrote: post #115
dfox wrote: post #11

Earlier quoted context omitted.

One reason I can see is that while Python 3's unicode handling is saner for most of usecases it does not work the way one would expect in unix shell.

Python isn't going to reconfigure an ASCII shell on your behalf. It's up to you to enable a Unicode locale and then PY3 just works.

The problem is bigger than misconfugured locale, namely: what is the encoding used for notionaly text zero-terminated strings that pass through the unix kernel (eg. filenames and program arguments)? There is no way to reliably and portably deduce that from locales.
Post reply on HN