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

101–110 of 204 posts

Re: NGS: Next Generation Unix Shell

#101

Post by lfowles »

nailer wrote: post #38
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…

That's because fish is a better version of existing shells. It's not significantly different to throw away what we have. Sane syntax and proper colors and better autocomplete make it better than bash, but not enough to throw away the network effects of bash. Think of hg trying to compete with git - it might be better, but it's not better enough . As a shell person (I'm the maintainer of https://certsimple.com/rosetta…

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

Re: NGS: Next Generation Unix Shell

#102

Post by kps »

CJefferson wrote: post #89
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…

But, I need to remember to do that. How about (for example): $ for i in $(ls | grep 'cheese\|fish' | head -n 5) ... I'm sure there is a way to make this work correctly (take 5 filenames containing either cheese or fish), but I'd need to put more thought into making it work correctly.

  ls | grep 'cheese\|fish' | head -n 5 | while read -r i …

Re: NGS: Next Generation Unix Shell

#103

Post by athenot »

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…

On the flip side, you can have multiple filesystem entries (via hard links) to the same set of files and set up your own playground directory while keeping a mirror view of the same directory. Remove a file from dir A, and it's still in dir B. Once you're satisfied with the result, you can delete the entire dir B. Accidentally removed a file from A? Restore it from B by making another hard link. (Caveat: hard links don't work with directories unless you're Apple TimeMachine)

Re: NGS: Next Generation Unix Shell

#104

Post by Natanael_L »

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…

It would require the programs to explicitly describe their actions to the shell and by default behaving in a reversible manner. That would allow you to single out effects you dislike, and tell it to undo it.

Kind of like making the shell behave in relation to your OS as an editor/IDE + version control system, rather than just as an editor/IDE. Old versions are preserved until you purge them.

Or perhaps it would just simulate state changing actions by default, waiting to be told to execute them.

Re: NGS: Next Generation Unix Shell

#105

Post by Bjartr »

voidz wrote: post #13
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…

Thanks to tmux, I don't have a problem with multiple interactive commands and their outputs. If I need to do something new, I open another shell on a new pane. Not that other solutions aren't welcome, but this works for me. If I don't want output at all, the &>/dev/null output redirection works, or file descriptor redirection, for which zsh has useful methods. Spaces in filenames are easily solved by quoting filename…

One of the problems tmux and friends don't solve that a "smarter" underlying system might add is the ability to make the choice to detach a process or redirect its output after it's already begun running.

For example, I specifically have had on many occasions started something and then later wished I'd previously started screen. While, "gain the knowledge to better configure your environment to start" is a valid response, equally valid is a desire for a more flexible default environment in general.

Re: NGS: Next Generation Unix Shell

#106

Post by joosters »

kps wrote: post #99
joosters wrote: post #72

Earlier quoted context omitted.

Once again, you're getting too hung up on my dumb little example, which I spent exactly 0 seconds thinking about. It's the general problem that's interesting (and annoying), the 'command1 | command2' general case. If you want a difficult example, then take a more real-world example: e.g. the workflow of a 'find [some stuff] |grep [some other stuff]' is one to consider. That's where horrid workarounds like -print0 and…

The (ex) AT&T Research command tw(1) has pretty much replaced find(1) for me (particularly with some canned search selectors for particular projects).

I'm struggling to find any information on this command (it's not an easy name to search for!) Do you have any links you could share please?

Re: NGS: Next Generation Unix Shell

#107

Post by joosters »

txutxu wrote: post #76
joosters wrote: post #72

Earlier quoted context omitted.

Once again, you're getting too hung up on my dumb little example, which I spent exactly 0 seconds thinking about. It's the general problem that's interesting (and annoying), the 'command1 | command2' general case. If you want a difficult example, then take a more real-world example: e.g. the workflow of a 'find [some stuff] |grep [some other stuff]' is one to consider. That's where horrid workarounds like -print0 and…

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.

Re: NGS: Next Generation Unix Shell

#108

Post by ilyash »

Thanks for your input and GitHub stars! You are all very welcome to open GitHub issues with your suggestions.

I'm looking for developers to join the project. There is a lot of work to do :)

Ilya Sher, the author.

Re: NGS: Next Generation Unix Shell

#109

Post by oblio »

gioele wrote: post #87
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…

> 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. Like the Austin group, the technical committee that constantly releases updates to POSIX and the Single…

Aren't those folks more "enterprise" oriented than "quality of life" oriented?
Post reply on HN