Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NGS: Next Generation Unix Shell

github.com

Post reply on HN
Print view View original

51–60 of 204 posts

Re: NGS: Next Generation Unix Shell

#51

Post by txutxu »

dfcowell wrote: post #42
txutxu wrote: post #32

Earlier quoted context omitted.

ls is not bash wc is not bash And that is a discouraged way to count files in shell script. Still, simply adding -l to ls, could handle spaces correctly (the files count) I insist, spaces are not your enemy, there are much more weird file names for a shell. Shell can handle spaces if used properly.

That there are worse things that exist is no reason not to pluck the low hanging fruit. I see this attitude on HN a lot. Spaces are probably the 80 in the 80/20 rule here. Why not address them?

Please give a single example in shell about spaces, that has not been already addressed.

From where do your get that rule?

Re: NGS: Next Generation Unix Shell

#52

Post by joosters »

txutxu wrote: post #32
joosters wrote: post #20

Earlier quoted context omitted.

When you pipe the output of one command into another, e.g 'ls | wc' (obviously a dumb example), the second command will split the filenames on spaces and so will not run properly. The workarounds for this all involve nasty extra parameters for different commands (e.g. the -print0 example)

ls is not bash wc is not bash And that is a discouraged way to count files in shell script. Still, simply adding -l to ls, could handle spaces correctly (the files count) I insist, spaces are not your enemy, there are much more weird file names for a shell. Shell can handle spaces if used properly.

You miss my point. Of course, for every example I give, it's possible to build a workaround to handle the spaces. My point is, it's the very fact that you need a workaround that makes it so irritating.

'command1 | command2' just works in most circumstances, so it's frustrating that it falls apart when a filename with a space appears.

And it technically is a shell issue, insomuch as the shell is dividing up the ARGV for each program. The shell is perhaps not to blame, because it can't tell the difference between a filename that has a space in it, and ordinary output that just so happens to correspond with a filename. In other words, it's hard to see what a shell could do to make things better. But the problem still exists.

Re: NGS: Next Generation Unix Shell

#53

Post by xomateix »

heydonovan wrote: post #9

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…

Relevant xkcd: https://xkcd.com/927/

Re: NGS: Next Generation Unix Shell

#54

Post by JadeNB »

yoodenvranx wrote: post #17

Something I would LOVE to see (not only in a shell but in all tools) is some kind of "project mode". - In Chrome/Firefox I'd like to have a mode for recreational browsing, one for research of webdesign and one for fitness/health stuff. This basically means that I want to click at a browser window and say "This is now my fitness window. Please remember all the open tabs". And then there is a list of open sesions/proje…

Firefox's Session Manager (http://sessionmanager.mozdev.org) does almost exactly what you want.

Re: NGS: Next Generation Unix Shell

#55

Post by tacos »

nailer wrote: post #46
anfroid555 wrote: post #23

But why nodejs?? There are a lots better languages to base this off of.

Probably because JavaScript is the worlds most popular programming language, it's portable, has the largest package manager, supports the shell's non blocking requirement, and the current version (ES6) has a better stdlib than previous versions.

You're wrong on about three of those statements, but note that the same hand wave could have been made for Perl ten years ago. That would've been a poor choice then for the same reason Javascript is a poor choice now.

Re: NGS: Next Generation Unix Shell

#56

Post by gravypod »

jordigh wrote: post #33
pjmlp wrote: 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…

Something like TempleOS, written in Holy C?

Terry really did something cool there with his JIT Holy C (or C+ before the TempleOS thing). I'd definitely like to see something like that ported to other platforms.

Re: NGS: Next Generation Unix Shell

#57

Post by yoodenvranx »

azdle wrote: post #48
yoodenvranx wrote: post #17

Something I would LOVE to see (not only in a shell but in all tools) is some kind of "project mode". - In Chrome/Firefox I'd like to have a mode for recreational browsing, one for research of webdesign and one for fitness/health stuff. This basically means that I want to click at a browser window and say "This is now my fitness window. Please remember all the open tabs". And then there is a list of open sesions/proje…

> - In Chrome/Firefox I'd like to have a mode for recreational browsing, one for research of webdesign and one for fitness/health stuff. This basically means that I want to click at a browser window and say "This is now my fitness window. Please remember all the open tabs". And then there is a list of open sesions/projects where I can switch between those views/instances. I'd like to be able to close my fitness-windo…

I used to love and use Tab Groups but it was always amazingly slow on my PC (old-ish Celeron 2.6 Ghz)

Re: NGS: Next Generation Unix Shell

#58

Post by maho »

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 moving it to trash, you can press SHIFT+DELETE, in which case Windows will also warn you that it can't be undone. (What is missing in Windows is a "nuke" option that overwrites the old bits with random data, for those rare cases where a file must be purged from the system completely.) But in most cases, after deleting a file, you can simply press CTRL+Z to get it back.

It is possible to make rm behave like that in Linux [2], but in a NGS, this should be the default behaviour (in my view), with "delete" for really deleting (unlinking) a file, and "nuke" for completely distroying a file, as seperate commands.

Undo is hard. Most programs are on their third, fourth, or even higher release before getting it right. (Mathematica 10 is stil trying to get there...) But I think we should try harder to solve the undo-problem with respect to file-system interactions, or with respect to system-settings, in Linux.

[1]: http://unix.stackexchange.com/questions/10883/where-do-files...

[2]: http://unix.stackexchange.com/questions/42757/make-rm-move-t...

Re: NGS: Next Generation Unix Shell

#59

Post by Gracana »

The first few bullet points (regarding job control / status / blocking) sound interesting and useful for anyone. I think it would be cool to have a shell with some sort of visual job control system and an easy way to background anything that was taking significant time. Maybe that wouldn't be as deeply integrated as the system the author is describing, but it would probably be easier to implement and less of a change from a standard shell. These days I hardly ever suspend a process and continue it in the background because it's easier to spawn a new shell, but if that workflow were streamlined... maybe I wouldn't need a dozen shells open all the time.

As for the rest, I dunno. Neat, but complex solutions like this make me pause. Maybe instead of trying to solve this problem, we should instead try to not have this problem. That is, if your tools require this much of your shell, maybe the tools are the problem and not the shell?

Re: NGS: Next Generation Unix Shell

#60

Post by ilyash »

akatechis wrote: post #8

Lots of assertions about how "bad" our current shells are, but no substantiation. I'm a developer, and I know just enough shell to write a simple deploy script or two, but reading this, I'm not convinced that what we really need is new shells and scripting languages.

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?
Post reply on HN