Live data from Hacker News

NGS: Next Generation Unix Shell

github.com

121–130 of 204 posts

Re: NGS: Next Generation Unix Shell

#121
post #58

My number-one wish for a NGS: Undo! Take, for example, rm. The hoops we have to jump through when accidentally rm'ing a file are ridiculous [1]. But in most cases (smallish, non-secret files), rm should be trivially undoable. Windows gets this right: By default, files are not deleted, but moved to trash. If there is not enough space in trash, Windows warns you. Or, if you really want to delete a file instead of movin…

Although I kind of agree with you, I'll play the devil's-advocate: If you actually care about the file, it should have a backup that you can restore from anyway. And, depending on the file, that backup should be source-control.

If the solution to the problem relies on human beings being fully-informed, entirely competent, and never making mistakes-- it's not a very good solution, IMO.

Yes, people should maintain backups. But if people don't, for whatever reason (maybe they've never heard the word "backup" before; maybe they typed the wrong command and thought they had backups all along, etc.) shouldn't be screwed if something goes wrong.

Re: NGS: Next Generation Unix Shell

#122
post #11

For me a next generation UNIX shell needs to catch up with what REPL environment in Lisp Machines, Interlisp-D, Mesa/Cedar, Smalltalk, Oberon(-2), AOS features and capabilities. For the young HNers, think having something like Swift Playgrounds or IPython as your shell, while having full access to the OS API without relying on external programming languages. Otherwise the next generation prefix isn't worth mentioning…

Smart comment.

The UNIX shell and core-util model of "everything is text", and line-by-line output and tools for line-by-line data manipulation, goes very far, much farther than you'd think, but is limited. Everyone has internalized those limitations.

It reminds me of MATLAB: everything is a matrix (another standard, versatile, tabular data structure), and many language constructs exist to manipulate this common data structure.

Re: NGS: Next Generation Unix Shell

#123
post #58

My number-one wish for a NGS: Undo! Take, for example, rm. The hoops we have to jump through when accidentally rm'ing a file are ridiculous [1]. But in most cases (smallish, non-secret files), rm should be trivially undoable. Windows gets this right: By default, files are not deleted, but moved to trash. If there is not enough space in trash, Windows warns you. Or, if you really want to delete a file instead of movin…

Although I kind of agree with you, I'll play the devil's-advocate: If you actually care about the file, it should have a backup that you can restore from anyway. And, depending on the file, that backup should be source-control.

I know you're playing devil's advocate, but that attitude is making the perfect the enemy of the good. Backups are non-trivial enough that many people don't set them up correctly if at all; and even if they do, a restore can take some work. I think it's perfectly reasonable to have relatively painless alternative (e.g. "undo_rm") as an extra layer of safety.

Re: NGS: Next Generation Unix Shell

#124
post #73

I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. I'm a huge fan of the fish shell, but in the real world, it never seems to be installed across the farm, and convincing the older SysAdmins to install it is more trouble than it's worth. We should be focusing on saner bash defaults, since it's the most common shell in use. We should…

older SysAdmins I hope you aren't referring to their age, in which case consider using a different adjective: experienced, seasoned, wiser, etc. Your colleagues probably don't want to install fish shell for reasons besides how old they are.

Or, if you disagree with their opinion: hidebound, closeminded, timorous, etc.

I think the parent was going for something indicating disagreement, so it seems unlikely that your "positive" adjectives are what they were looking for.

Re: NGS: Next Generation Unix Shell

#125

[WARNING, RANTY] This is a blue-sky project. Completely new, with no legacy dependencies. AND YET THE DEVELOPER CHOSE TO WRITE IT IN C. WHY FOR THE LOVE OF GOD, WHY? Could someone explain this to me? Is it developer hubris, believing in one's own infallibility that a single exploitable stack frame or buffer overflow couldn't possibly happen "on my watch"? If you need a native binary, your options are endless. Rust, G…

Do you think it's a bad idea that git and the Linux kernel are written in C? Is the possibility of a buffer overflow important in a program that's not processing input from random people on the internet?

Re: NGS: Next Generation Unix Shell

#126
post #58

My number-one wish for a NGS: Undo! Take, for example, rm. The hoops we have to jump through when accidentally rm'ing a file are ridiculous [1]. But in most cases (smallish, non-secret files), rm should be trivially undoable. Windows gets this right: By default, files are not deleted, but moved to trash. If there is not enough space in trash, Windows warns you. Or, if you really want to delete a file instead of movin…

>Windows gets this right: By default, files are not deleted, but moved to trash. The del or Remove-Item commands also permanently delete the file, just like rm. The "Windows" behavior you're talking about is the behavior of the graphical shell Explorer, which is also present in Gnome and KDE. There's nothing specific to Windows here.

That said, i'd like a "del to recycle bin" in Windows too.

Re: NGS: Next Generation Unix Shell

#127
post #39

Earlier quoted context omitted.

We should be focusing on saner bash defaults, since it's the most common shell in use. That kind of work is not glamorous and highly controversial. Ideally there should be some sort of cross distro/OS working group (Debian/Ubuntu, Red Hat, SUSE, FreeBSD, NetBSD, OpenBSD, Mac OS X, etc.), similar to the working groups that standardize the web, where such proposals can be made, voted on and adopted. For example there s…

I've been using -nix for almost 20 years. I've used everything from ksh on SunOS 2.6 (Solaris?? what's that) to oh-my-zsh (for 3 years, before happily graduating to oh-my-fish). I grew up on Slackware 6 waiting hours and hours for a 2.2 kernel build to finish. In high school, FreeBSD 4.3 kernel mods took up more time than booze and women. My 3 year puppy love for oh-my-zsh dimmed as I transitioned to a more sane, les…

Powershell's almost great. Things are way too verbose. No built-in stuff like curl or wget (yes, there's a simple webrequest thing and aliases, but they're clunky). In fact, it feels like everything in PS is clunky.

Just simple stuff like "time ./foo" becomes "Measure-Command {... }" and then it prints out 10 lines of the same measurement, in different units. And doesn't distinguish CPU time versus wall time.

All that adds up and makes PS crap for interactive work. As far as writing programs, PS is a much better programming language than bash.

And yes, I understand that using a bunch of 3 or 4-char names kills your global namespace. But judicious use really aids ergonomics.

Re: NGS: Next Generation Unix Shell

#129
post #111
post #60

Earlier quoted context omitted.

Simple example: using current shells it is not convenient to work with API call results which are structured data. Yes, there is jq but if the shell had data structures it would be much better, wouldn't it?

On UNIX, the "API" is basically that everything is a file and programs are written to handle text streams. After all these years, the shell is still perfect for this. It sounds like you want create a new language and shell in order to have something similar to Windows PowerShell which interacts .NET objects using its API. This does not fit into the Unix "API" described above. This isn't a "Next Generation UNIX Shell"…

That's great, but how much data do you work with, day-to-day, that is best represented as text streams? For me, the answer is "virtually none". Heck, most of the stuff I work with, day-to-day, can't even be represented meaningfully in a text stream. (Editing video, for example.)

Re: NGS: Next Generation Unix Shell

#130

[WARNING, RANTY] This is a blue-sky project. Completely new, with no legacy dependencies. AND YET THE DEVELOPER CHOSE TO WRITE IT IN C. WHY FOR THE LOVE OF GOD, WHY? Could someone explain this to me? Is it developer hubris, believing in one's own infallibility that a single exploitable stack frame or buffer overflow couldn't possibly happen "on my watch"? If you need a native binary, your options are endless. Rust, G…

Do you think it's a bad idea that git and the Linux kernel are written in C? Is the possibility of a buffer overflow important in a program that's not processing input from random people on the internet?

I wonder if git would be better served by a more modern language.
Post reply on HN