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

161–170 of 204 posts

Re: NGS: Next Generation Unix Shell

#161

Post by spc476 »

CJefferson wrote: post #92
txutxu wrote: post #88

Earlier quoted context omitted.

'Ctrl + z', 'bg' and 'fg' are for that.

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

What you are asking for, "post-redirection" (a term I just coined) is not an easy task. Redirection is, but that's set up prior to the program run (warning: pseudocode ahead):

    child = fork()
    if child == 0 then
      stdout = open("output","w")
      stderr = open("error","w")
      dup2(stdout,FILENO_STDOUT)
      dup2(stderr,FILENO_STDERR)
      Close(stdout)
      Close(stderr)
      Execve("someprogram",arglist,envlist)
    End
Standard Unix stuff. But doing that after the program is running isn't easy. The only way I know of is to send the program SIGSTOP (stops execution of the program---said signal can't be caught), and using ptrace(), inject code into the process to open the output file and call dup2() to get the redirection going, calling said code, then resuming the program.

I suppose one could script gdb (or whatever Unix debugger exists on the suystem) to do such a thing, but the fact that no one has really done this might mean something.

Re: NGS: Next Generation Unix Shell

#162

Post by qorrect »

zyxley wrote: post #140
lfowles wrote: post #101

Earlier quoted context omitted.

Personally, I use fish as my interactive shell. Bash still exists in the background for purposes of _the whole world runs on it_.

Same here.

Same here too. Fish on all local machines, bash on AWS instances, and all scripts written in bash, simply for compatibility.

Re: NGS: Next Generation Unix Shell

#163

Post by AckSyn »

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…

Slackware jumped from Version 4 to 7 back in 1999.

Anyways, Powershell is pretty amazing and they did get it right. However, some of the syntax leaves much to be desired. I mean this:

Get-ChildItem $Path | Where {$_.extension -eq '.DLL'}

It's the worst example of a recursive search for a specific file extension, easiest being "gci -Recurse -Include .DLL", but the syntax using {$_. ,'*'} is used in many places, most of which I've been able to figure out less complicated replacements and achieve the same results. This includes being able to pipe out each "object" in the resulting text appropriately.

This isn't a bash against powershell. They did get it right, but I'm left wondering why they bothered including this kind of syntax'ing?

Re: NGS: Next Generation Unix Shell

#164

Post by spc476 »

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…

It sounds a lot like the VMS shell (outside the directory manipulation and file redirection which was horrid, it wasn't that bad of a shell and the help facility was first rate).

Re: NGS: Next Generation Unix Shell

#165

Post by spc476 »

voaie wrote: post #6

> The problem with outdated shells looks pretty clear: they were made with one kind of tasks in mind but are used for other, bigger and more complex tasks. Such scripts usually look as a fight against the language and working around it much more than using it to solve the problem. Mind you, > Create a shell (in that language) that is up to date with today's tasks - cloud, remote execution on a group of hosts. I'd rat…

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 output to a program on a third machine and have that redirect the output to a file on a fourth machine, all from the command line. I don't recall the exact syntax, but it was something like:

    cat @2/path/to/large/file | @3/bin/grep 'foo' >@4/tmp/output
(Individual hosts were numbered on a QNX ethernet based network, but the default permmissions were Unix like). All of this was a consequence of the message-based QNX operating system (whether messages were delivered locally or remotely was invisible to programs) but I don't see why something like can't be done today.

Re: NGS: Next Generation Unix Shell

#166

Post by leephillips »

typon wrote: post #159
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?

I'm sure you've heard of the Shellshock bug.

Shellshock is a flaw in bash parsing and has nothing to do with that fact that bash happens to be written in C. Also, it's only a problem for untrusted input sent to bash. Typically, from the internet.

Re: NGS: Next Generation Unix Shell

#167

Post by mastax »

jandrese wrote: post #156
txutxu wrote: post #27

Earlier quoted context omitted.

If it's hard to try to convince them about fish... try to convince them to enter commands in a browser over a web stack, as a "shell". If they are conscious about the parts involved and the security repercussion, maybe they will say the same: "no". On the other side, technology is not advanced only by older SysAdmins, and it's nice to see new projects, experiments and developments.

> try to convince them to enter commands in a browser over a web stack, as a "shell". What? I had never heard of fish before and this is making me nop out pretty quickly.

Fish is not web based. I think he's referring to the browser ui in the OP.

Re: NGS: Next Generation Unix Shell

#168

Post by GunboatDiplomat »

oblio wrote: post #39
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, 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 have to disagree with the idea that everything should be standardized. What's the point of different distros if everything is just going to be the same? Might as well just tell everyone, "Ok, we're all going to use CentOS."

Re: NGS: Next Generation Unix Shell

#169

Post by stephenmm »

chriswarbo wrote: post #83
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, since it's the most common shell in use. Bash already provides two "modes": when called as `sh` it is more POSIX-compliant, when called as `bash` it allows more bash-specific features and syntax. Maybe `bash` invocation can remain for backwards compatibility, and a new mode be added (e.g. `sash` for "sane shell") which can be used for breaking changes in the name of saf…

The new name has to be dcbash or maybe dcsh but dcbash is more fun.

Re: NGS: Next Generation Unix Shell

#170

Post by oblio »

GunboatDiplomat wrote: post #168
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 have to disagree with the idea that everything should be standardized. What's the point of different distros if everything is just going to be the same? Might as well just tell everyone, "Ok, we're all going to use CentOS."

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.).

Standards are generally good (HTTP, IP, SSL, TCP, POSIX, USB, etc.).

Post reply on HN