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

191–200 of 204 posts

Re: NGS: Next Generation Unix Shell

#191

Post by lomnakkus »

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…

> We should be focusing on saner bash defaults

Yes! A huge part of the fragility of shell scripting is the fact that there are a billion options which change crucial semantics of how the language works.

Just pick some goddamned sane option values and disallow changing them!

There's a reason you don't see this kind of nonsense in "real" programming languages: It plays absolute havoc with reasoning about what will happen when you run a script. (You could easily miss the fact that the shebang line does/doesn't contain "-e" or that option to error-on-unset-variables is/isn't set, etc.)

Re: NGS: Next Generation Unix Shell

#192

Post by leephillips »

codygman wrote: post #175
leephillips wrote: post #145

Earlier quoted context omitted.

Git started in 2005. I'm sure Torvalds knew all about buffer overflows then, but decided to use C. You seem to think this is a crazy decision.

> Git started in 2005. I'm sure Torvalds knew all about buffer overflows then, but decided to use C. You seem to think this is a crazy decision. Well is it? Will it be if Linus isn't maintaining it?

Linus Torvalds has not been the git maintainer for years.

Re: NGS: Next Generation Unix Shell

#193

Post by botw »

ParrotyError wrote: post #152
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…

Back in the 90s (IIRC) someone wrote a kernel module for linux that provided the equivalent of a GUI "trash can/recycling bin" but at the filesystem level, where a specific directory (folder for you young 'uns) was set aside for the deleted files. Because it was a kernel module (filesystem driver) it was transparent to applications, including the shell.

lost+found? it's still there in each file system but i never see a real usage for it.

Re: NGS: Next Generation Unix Shell

#194

Post by hibbelig »

txutxu wrote: post #185
hibbelig wrote: post #146

Earlier quoted context omitted.

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…

Thank you for all these great ideas. Yes, I totally forgot about settings to merge history.

Re: NGS: Next Generation Unix Shell

#195

Post by Crespyl »

botw wrote: post #193
ParrotyError wrote: post #152

Earlier quoted context omitted.

Back in the 90s (IIRC) someone wrote a kernel module for linux that provided the equivalent of a GUI "trash can/recycling bin" but at the filesystem level, where a specific directory (folder for you young 'uns) was set aside for the deleted files. Because it was a kernel module (filesystem driver) it was transparent to applications, including the shell.

lost+found? it's still there in each file system but i never see a real usage for it.

I believe that's less an everyday-use "trashcan" and more of an ext* feature for recovering from filesystem corruption; "Something broke and I think I've recovered all the files, but I've forgotten where some of them were supposed to go".

Re: NGS: Next Generation Unix Shell

#196

Post by superobserver »

MichaelGG wrote: post #127
iheartmemcache wrote: post #118

Earlier quoted context omitted.

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

Your complaint about clunkiness isn't wrong. But consider the contrast of (1) stating a full phrase that preserves the symmetry between syntactical constructs with their semantic counterparts or (2) the acronymic representation thereof. Whilst (1) is always clunky, it tends to be easier to use for non-experts, whereas (2) is minimal but requires an expert-level familiarity. In essence, it is little different from the contrast between written English and written Chinese.

Re: NGS: Next Generation Unix Shell

#197

Post by spc476 »

dmytrish wrote: post #178
spc476 wrote: post #165

Earlier quoted context omitted.

The QNX shell could easily do remote execution. I worked at a company in the mid-90s (porting Unix software to QNX). My machine had a modem on it, and my boss (the owner of the company) would use it from his computer to dial out---all he had to do was reference the modem device on my computer at his command line. In fact, you could run a program on a local machine referencing a file on a second machine, pipe the outp…

This is a quite neat example, but it looks like the QNX shell mixed several concerns about how do you connect to these machines, how do you secure the communication, etc. $ ssh @2 "cat /path/to/large/file" | ssh @3 "/bin/grep 'foo'" | ssh @4 "cat >/tmp/output" is rather clunky, but separates those concerns well.

Sorry about not getting back sooner (returning from vacation) but the QNX network message passing ran over Ethernet, not IP, so it only worked (to my knowledge) over a local segment. Given that it was transparent to user processes, it could be argued that security could be added at that layer (two of the seven layer OSI model).

Re: NGS: Next Generation Unix Shell

#198

Post by mpweiher »

iheartmemcache wrote: post #134
MichaelGG wrote: post #127

Earlier quoted context omitted.

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

Yeah, for things like that, I have a wrapper function and/or aliases which get loaded with PowerShell. The over-verbosity I'd imagine really helps the "click next-get cheques" guys who are a little intimidated by the command-line. (I on the otherhand bleed Hayes 9600 baud and VT220 green cold cathode.). 'ps aux' wouldn't really cut it. Just like one customizes their bash, fish, zsh or whatever shell, you customize yo…

Hayes 9600 baud? VT220? Geez, kids these days...setting your (directly attached) ADM-3s to 1200 bps in order to smooth over the task-switching jerkiness of your PDP-11 ;-)

Back to PowersShell. When I first looked at it, it seemed like just the right answer, but on closer inspection...not so much. Being able to customise: yes. Having to customise right out of the gate to get an even barely usable experience: not so much.

It is obvious that the task is difficult, but PowerShell shows many interesting direction and some ways to not solve it.

Re: NGS: Next Generation Unix Shell

#199

Post by friendzis »

iheartmemcache wrote: post #118
oblio wrote: 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 on itself does have really nice design decisions, but does not interact well with the whole system, leading to interoperability, portability issues and being clunky to use, in my view. It looks like PS is designed more towards DevOpsing (let developers do some administrative tasks in a familiar environment) than systems administration. Some of the rough edges I have encountered in the past:

The whole point about piping objects (.NET class instances, sort of) around is really awesome, except that even on 8.1 (did not check on 10) standard utilities like ipconfig output wall of text, which has to be string-parsed.

To be fair, there are cmdlets for most if not all subsystems, except that wrappers are sometimes too shallow, e.g. System.ServiceProcess.ServiceController returned by Get-Service does not expose delete(), so you have to resort to WMI. I have not used PS extensively enough, but would not be surprised if some tasks would require one to resort to wmic, netsh or similar tools.

Powershell is not automatically updated, so you can find anything between 1 to 5 and anything portable has to be written for 1. e.g. Get-Service, which is in global namespace, is available since 3. IIRC W7 ships with 2.

Powershell allows to use .NET directly, e.g. spawn process with [System.Diagnostics.Process]::Start, except as with above, you have no idea which version of .NET is available on target system.

I found no other way to gain administrative privileges except for relaunching itself in administrative context.

PS ISE could be used to incrementally write and debug scripts by directly fine tuning each command, except that it is non-interactive, so utilities asking for password are kind of painful.

Re: NGS: Next Generation Unix Shell

#200

Post by JdeBP »

maho wrote: post #190
Arnavion wrote: post #119

Earlier quoted context omitted.

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

> But why are classic shells shipped without even the simplest "undo" features?

This question is assuming an untrue premise. There are Windows command interpreters that integrate DEL and RD with the Recycle Bin.

* https://jpsoft.com./help/del.htm#r

* https://jpsoft.com./help/del.htm#k

* https://jpsoft.com./help/rd.htm#r

* https://jpsoft.com./help/rd.htm#k

Post reply on HN