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

181–190 of 204 posts

Re: NGS: Next Generation Unix Shell

#181

Post by txutxu »

joosters wrote: post #107
txutxu wrote: post #76

Earlier quoted context omitted.

If I could need to combine a find|grep right now (this is, if the directory recursion and filters of grep by itself, weren't enough, which maybe a corner case too...) I could do it like this: while IFS= read -rd '' file; do echo "do whatever with: $file" grep whatever -- "$file" done It's like natural language if you do it daily. Will handle not only spaces, but also new lines on file names. Have a nice day.

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.

For me, the code I did give, is not a workaround.

It's the canonical way of do it.

Other ways, even if they are "expected to work by inexperienced occasional users"... are simply flawed a first eye view.

A workaround is to ditch shell script, as soon as you face a problem, and blame shell script, and turn to do it in a "more advanced language" that has the same or more caveats. That could be a workaround.

Delimiting file names with null bytes, in case they could be split by any of the $IFS values, is NOT a workaround, is pure logic.

Re: NGS: Next Generation Unix Shell

#182

Post by txutxu »

NoGravitas wrote: post #143
CaptSpify wrote: post #75

Earlier quoted context omitted.

I'm guessing it was down-voted because you keep missing the point. Yes, there are work-arounds for this scenario, but the overhead in remembering the work-arounds is the problem. He's not saying you can't do it, he's saying the problem is that you have to change your setup for edge-cases, which are actually fairly common.

It's not even so much the overhead in remembering the work-arounds, as remembering when exactly you need the work-arounds.

Shell script split on spaces (or the values of $IFS) by design.

For example, use null delimited values, because a variable (like IFS) cannot contain null bytes. Is this a workaround? I see it as pure logic.

Even understanding howto handle them, helps to understand the internal design of the shell and common external utilities.

Remembering is hard? not a "shell" specific issue... I use it daily and maybe that's why I don't face the same problems that other see so clear.

Re: NGS: Next Generation Unix Shell

#183

Post by [deleted] »

GunboatDiplomat wrote: post #172
oblio wrote: post #170

Earlier quoted context omitted.

If you want shipping, you want standards. They should be creative in the UI and system administration tools (maybe not even for those tooks), otherwise we can't build anything on top of them. There's no real use for 3000 distributions anyway. Most of them can't even support the software they include properly. And most of them duplicate so much effort it's not even funny anymore (rpm vs deb, yum vs apt, etc.). Standar…

There should be a standard withing the organization (we use CentOS for everything internally), and for systems which need to inter-operate, for example, the internet. There does not need to be a standard for shells, for network script syntax, etc. You say they duplicate effort, which is true, but you assume the effort being expended would simply be redirected where you think it's needed. If you kill off half of distr…

[deleted]

Re: NGS: Next Generation Unix Shell

#185

Post by txutxu »

hibbelig wrote: post #146
txutxu wrote: post #100

Earlier quoted context omitted.

Well, if you work always in tmux/screen (a recommended practice for operations, that I did import to my daily shell activity) you don't need job control. When there is a "surprisingly slow" command, then just press the shortcut for a new screen session. Will get alerted in the status bar when the slow command finishes. Output of each command will be in it's own screen session (not mixed). That Ctrl + z response was n…

I meant to include the part of capturing the output -- the part that Ctrl+Z does not do. Opening a new screen/tmux session is a cool idea, but the new session doesn't inherit the state from the already running one, I guess. (At least in screen, not sure about tmux.) By "state" I mean the shell history, the current working directory, the (environment) variables. Also, say that long running command runs five minutes, a…

My screen respects the current working directory for new sessions.

My history is configured to write at every prompt redraw and to don't miss commands.

With vanilla history and prompt command settings, history will be separated.

But as this is a common problem, and not only with screen, also with multiple xterms and IDE's shells, and... also is a problem that history may miss lines by default...

And as it's a common problem, there are settings to fix that, configure the history merge strategy to your taste and do not miss history lines, because you did close a xterm, or you did open a new screen sessions.

Curiously, those settings are even documented upstream.

Session variables? I expect the ones that could be loaded by login executing bash -l...

If I did export something after that, then maybe I simply need to export it again in a new session, but really in 20 years never was in this situation I think... (do not wait to a command, continue with other commands, and need a environment variable not initialized by default between both sessions....). If I was in that situation... was so easy to fix that I don't even remember.

Which one to close? the one I prefer randomly, probably by focus, or probably the highest screen id. As history is merged, I can close any or even both.

Re: NGS: Next Generation Unix Shell

#186

Post by ilyash »

vox_mollis wrote: post #98

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

See the full answer here: https://github.com/ilyash/ngs/issues/3

Re: NGS: Next Generation Unix Shell

#187

Post by ilyash »

skywhopper wrote: post #94

There are lots of mixed-up goals here that I think might be better served broken out into multiple projects: 1) Terminal UI improvements 2) Interactive shell UI improvements 3) Shell scripting language improvements 4) Userspace utility improvements Tackling all of these together may well be possible, but it will likely limit the potential impact of any improvements you are able to make. IMO, it's easier to move the s…

> The strongly-typed Python-lite described in the linked man pages

It's not strongly typed and types annotations can be left out in many places:

mylist.map(F(elt) "my $elt")

elt type is not specified.

The command syntax $(...) will cover some of the simple scripting needs. Please provide specific code examples (probably in bash) that you think will look bad.

> `jq` is an amazing

It is but in my opinion much less convenient than built-in support for data structures.

Re: NGS: Next Generation Unix Shell

#188

Post by ilyash »

gcr wrote: post #7

Looks quite interesting! Some feedback: Yes, a new paradigm for interacting with text commands would be wonderful. But what would that look like? One strong advantage of the current system is that the input matches the interface. Everything is text, so it all can be typed with the keyboard. But if this shell "displays structured results as real f ing structures (YAML, JSON, ...)", that may not be true. If the shell s…

> Manage multiple servers at once

IMHO will be much better if integrated into the shell. For example it will allow easy access to a shell variables with lists of hosts on which the command succeeded or failed.

Re: NGS: Next Generation Unix Shell

#189

Post by oblio »

GunboatDiplomat wrote: post #172
oblio wrote: post #170

Earlier quoted context omitted.

If you want shipping, you want standards. They should be creative in the UI and system administration tools (maybe not even for those tooks), otherwise we can't build anything on top of them. There's no real use for 3000 distributions anyway. Most of them can't even support the software they include properly. And most of them duplicate so much effort it's not even funny anymore (rpm vs deb, yum vs apt, etc.). Standar…

There should be a standard withing the organization (we use CentOS for everything internally), and for systems which need to inter-operate, for example, the internet. There does not need to be a standard for shells, for network script syntax, etc. You say they duplicate effort, which is true, but you assume the effort being expended would simply be redirected where you think it's needed. If you kill off half of distr…

I've been using Linux for a long time and I've been involved in discussions about this for as long. A while ago I wouldn't have had a good argument, but now I do:

> If you kill off half of distros, you probably just cause the people working on them to go away, not switch to one of the remaining distros.

That would actually be good. Except for their personal benefit: they're having fun, together with their friends or random people on the internet, they're learning, etc., for the rest of us, they don't help that much, they just serve to increase the confusion. They also help drive away commercial software developers since Linux users in general are very active and vocal. And then we get stuff like "why isn't software X ported to distribution Y".

Not much real value would be lost if half of today's distributions would be lost. Specialized ones, like system recovery, penetration testing, firewall ones, file system layout experiments (Gobo) would still be useful. But the myriad distributions in existence are an exercise in anarchy. They're not even an exercise in democracy since democracy involves also caring about your fellow men and exercising self control and discipline, which many of those distributions don't. As I said, the vast majority of distributions can't even support their software, see the recent security fiasco with Linux Mint. Which is a very popular distro!

Re: NGS: Next Generation Unix Shell

#190

Post by maho »

Arnavion wrote: post #119
maho wrote: 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.

You are right, I forgot about Gnome and KDE. I tend to use classic shells on Linux, and the graphical shell on Windows, so I made a wrong generalization. It's probably more accurate to say that "undo" of simple operations (rm, mv) is something graphical shells get right.

But why are classic shells shipped without even the simplest "undo" features? We can probably all tell stories-from-the-trenches of how we accidentally did something aweful by typing the wrong command. Sometimes, it's hosing the network configuration of a remote machine, which is not something where "undo" would help you. However, in my experience, most cases involve doing something foolish with rm or mv, where "undo" would be tremendously helpful. I guess the main reason why I don't use the text shells of Windows is that Windows explorer gives me Ctrl+Z, which is saving my behind approximately once per year.

As a final thought, all shells (graphical or not) should expand the undo-features beyond rm and mv. For example, if I change system settings (or even Application settings?) and am not happy, I would love to be able to simply "undo" them, without trying to remember what the previous setting was. I realize that this is an incredibly hard problem, and that it is unlikely to be solved in an evolutionary step of the existing shells. That's why hearing about NGS got me so excited.

Post reply on HN