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

141–150 of 204 posts

Re: NGS: Next Generation Unix Shell

#141

Post by GauntletWizard »

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…

Powershell seemed like a great advance upon cmd, until I realized it was a great step backwards from Python. It's an objectful interpreted scripting language, but suffers from poor namespacing, verbosity, and some fairly insane defaults.

Meanwhile, IPython as a shell[1] has been around for years. I do mostly python scripting, and spend much of my day at an ipython shell. I don't personally use it as a general purpose shell, but it is perfectly acceptable for many problems that I use if for.

[1]http://ipython.readthedocs.org/en/stable/interactive/shell.h...

Re: NGS: Next Generation Unix Shell

#142

Post by Tarean »

wicket wrote: post #111
ilyash wrote: 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"…

It is more that unix shells are built on piping and piping is systematically broken in unix shells. It just becomes extremely obvious after using for powershell for any time which doesn't require most of the work to scrap and rewrite ouput to make it compatible withan other program.

Doing piping well is extremely hard and basically requires that all commands give metadata about their arguments but doing it better wouldn't be all that hard.

You could do the same thing with text streams but structured piping would be a lot harder. If all programs would read and write something like json or msgpack and have a unified argument parser and dumper working with the shell would be a lot easier and faster.

Re: NGS: Next Generation Unix Shell

#143

Post by NoGravitas »

CaptSpify wrote: post #75
txutxu wrote: post #45

Earlier quoted context omitted.

Not sure on why this comment got down-voted. If it's because I did not explain how to do that, there is howto do it: http://mywiki.wooledge.org/BashFAQ/004 If it's because the comment on the given example... $ touch file1 $ ls -l | wc -l 1 $ touch "file 2" $ ls -l | wc -l 2 ... (?) If we were talking about "new lines in file names", or "dashes at the beginning of file names", or code injection through file names, the…

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.

Re: NGS: Next Generation Unix Shell

#145

Post by leephillips »

vox_mollis wrote: post #139
leephillips wrote: post #125

Earlier quoted context omitted.

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?

No, because they are both legacy software. I understand momentum in codebases - that's why I'm reserving my vitriol for fresh bluesky projects like this one. As for exploitability, privilege escalation and shellcode injection is still very much a thing, internet-facing or not.

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.

Re: NGS: Next Generation Unix Shell

#146

Post by hibbelig »

txutxu wrote: post #100
CJefferson wrote: post #92

Earlier quoted context omitted.

Except, now you are back to my original problem -- the output of the program will continue to spew all over my terminal.

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, and after one minute you create a new session. Then after four more minutes you now have two sessions, both ready to accept input. Which one do you use to continue working? How do you know which one to close?

Re: NGS: Next Generation Unix Shell

#147

Post by kbenson »

kkirsche wrote: post #132
js2 wrote: post #73

Earlier quoted context omitted.

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.

This to me makes too many assumptions. I'm sorry but experience doesn't mean wise. And in many cases experience can mean complacent or scared of change.

Neither experience not wise was used. Older was used. You are comparing two possible substitutions with each other, not the original term. There's not much point to that.

Re: NGS: Next Generation Unix Shell

#148

Post by CaptSpify »

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.

haha, yes, that's what I meant. Your phrasing is better

Re: NGS: Next Generation Unix Shell

#149

Post by tyingq »

Intermernet wrote: post #37
CJefferson wrote: post #5

Earlier quoted context omitted.

I'm suprised you can't think of problems you currently have with shells. Here is a few of mine: * Once I've started a program, and easy way of sending it to the background if it is taking a while, which sends it's output to some buffer I can refer to later, rather than continuing to spew it all over the screen. * While we are at it, stop spewing the output of multiple programs over the screen, under any circumstances…

I'd personally like a way to redirect the output of a running process (either `bg`d or `disown`ed) to a log file. The only way I've come across are horrible hacks using gdb[1] or strace. This should be easier. Anyone know of any better ways? I'd like to be able to do something like `proclog `. [1]: http://stackoverflow.com/questions/593724/redirect-stderr-st...

There's this: http://www.isi.edu/~yuri/dupx/dupx_man.html

Still uses gdb under the covers, but presents a front end close to what you are asking for.

Re: NGS: Next Generation Unix Shell

#150

Post by fao_ »

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…

If I haven't misread, you're proposing a replacement to rm that has support for undo? Why not just make a shell script that uses mv to place the item in, say, ~/.deleted and drop it in your PATH?
Post reply on HN