Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub – nushell/nushell: A new type of shell

github.com

Post reply on HN
Print view View original

381–390 of 411 posts

Re: GitHub – nushell/nushell: A new type of shell

#381

Post by edwinyzh »

talideon wrote: post #283
stackedinserter wrote: post #273

What if we added json output mode to all shell commands? Or at least make some wrappers that parse their unstructured text output into json. We would be able to use standard pipelines and jq to filter/query outputs, without any custom shells. Just imagine: ifconfig --json | jq '.[] | [.interface, .inet] | @tsv'

You're not the first person to think of that. See Juniper's libxo: https://github.com/Juniper/libxo It's integrated into a lot of FreeBSD's command line tooling, and is very useful, when it's available.

So a lot of FreeBSD command line tools support JSON output? That's cool! And I wish it was linux...

Re: GitHub – nushell/nushell: A new type of shell

#382

Post by pjmlp »

pornel wrote: post #326
pjmlp wrote: post #314

Earlier quoted context omitted.

Which is basically the same thing as /std=language, when applied to different translation units.

There is the similarity that the editions don't really matter for ABI, but otherwise editions are substantially different from the std switch. C/C++ std switches freeze the entire language and disable newer features. Editions don't. Rust 2015 edition isn't an old version of Rust. It's the latest version of Rust, except it allows `async` as an identifier. Editions don't really have an equivalent in C, but they're clos…

That only works because the Editions get updated after being released.

The same can happen to ISO C and C++, that is what technical revision documents are for.

> Therefore, the answer to the question of, say, “what is a valid C++14 program?” changes over time, up until the publication of C++17, and so forth. In practice, the situation is a bit more complicated when compiler vendors offer conformance modes for specific language revisions (e.g. -std=c++11, -std=c++17). Vendors may consider defect resolutions to apply to any historic revision that contains the defect (whereas ISO considers only the most recent publication as the Standard).

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213...

In both cases, it is expected that compilers update their understanding what a specific language revision means.

Re: GitHub – nushell/nushell: A new type of shell

#383

Post by pjmlp »

steveklabnik wrote: post #262
pjmlp wrote: post #259

Earlier quoted context omitted.

I am not convinced that editions are much better than language version switches. They only work in the ideal case that whole dependencies are available as source code, the same compiler is used for the whole compilation process and for light syntactic changes. In fact for IntoIterator , a small fix to the editions was made, https://blog.rust-lang.org/2021/05/11/edition-2021.html With 40 years of history, several Rust…

Two out of three of those things have nothing to do with editions. The final one is basically saying “you can’t make huge changes,” and I’m not sure how that’s a criticism of the possibility of “in 40 years there will be too many changes.”

> Therefore, the answer to the question of, say, “what is a valid C++14 program?” changes over time, up until the publication of C++17, and so forth. In practice, the situation is a bit more complicated when compiler vendors offer conformance modes for specific language revisions (e.g. -std=c++11, -std=c++17). Vendors may consider defect resolutions to apply to any historic revision that contains the defect (whereas ISO considers only the most recent publication as the Standard).

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213...

Feel free to think I am only doing FUD, and coming from C++ side I am clueless about how editions will fare in the future.

Re: GitHub – nushell/nushell: A new type of shell

#384

Post by aerique »

christophilus wrote: post #224
aerique wrote: post #159

Earlier quoted context omitted.

I don't know if fish counts as an alternative shell since it is still pretty close to bash and zsh, just with better defaults requiring less configuration (similar to i3wm with respect to "better defaults"). I just use it as interactive shell and for scripts I use `/bin/sh`. So I don't really run into a lot of problems, only sometimes with scripts that do not have a proper `#!/path/to/shell` declaration at the top. (…

I’ve been poking around with Sway, coming from Gnome (which I mostly love). What got you into i3 vs a normal desktop, and how long did it take you to realize it was a good fit?

Phew, I've been using tiling window managers for 15+ years now so I don't really know. I've always been interested in trying out different window managers and UI/UX concepts.

When I started with Linux in the 90's it had FVWM by default as graphical interface which was pretty different when being used to Amiga, Atari ST and Windows 3.1. (They were all pretty different from each other.)

Of course I had to run Enlightenment with some rusty graphics when I discovered it, but I think WM2/WMX[1] was the first window manager where I realized I preferred the more minimalistic ones.

After trying out more WMs I ended up at awesome[2] which I ran for years. It had the best support for both floating and tiling windows. (I do like some floating windows now and then but never liked the "normal" desktop concept which is, paraphrasing Fred Brooks, more of a flight seat concept.)

Then WMs like xmonad started appearing and I tried those out but they're pretty much "tiling only" and I did not like xmonad's tiling windows approach. It's been too long since I used it and I'm not sure it is still applicable but it forced you to use specific layouts and the current window was always maximized.

So at some point i3 appeared (like fish shell and Doom Emacs) and when trying it out it by default already did most of the things that I liked and that I had to configure in other window managers, so that was nice. It was a pretty good fit right away.

I have used some other WMs like EXWM and StumpWM over the years because I'm both an Emacs and Lisp weeny but they're like less mature i3 clones so I've been back at i3 for a while now.

[1] http://www.xwinman.org/wm2.php

[2] https://awesomewm.org/

Re: GitHub – nushell/nushell: A new type of shell

#386

Post by hibbelig »

j1elo wrote: post #331
hibbelig wrote: post #299

Earlier quoted context omitted.

If you want to make the systems homogeneous, then you need homogeneous teams, too. Maybe some team members prefer fish, others prefer zsh, still others prefer bash. Your suggestion means that everyone has to use the same shell for their command line. I find that it is better to allow each team member to have their own working environment: different (command line) shell, different editors/IDEs, different keyboard shor…

no no no, I meant that I prefer using Bash everywhere, including my own machine, because anyway I'll need to end up translating most stuff I write to a Bash or even POSIX compatible script so... as someone said in other comment, why not cut the intermediary step. It makes it easier for me, the less context switches the better production code I'll produce. But of course, I believe others should be free to make their o…

I understand your point about being able to write proper bash scripts. On the one hand, I never use Java as my shell, but I am able to write proper Java programs just fine; why should bash be different?

On the other hand, I've been using Bourne-ish shells (mostly bash with short bouts of zsh) for twenty-plus years and I have no clue about arrays. (I know the difference between "$@" and "$*" (including the quotes), but that's it.) Now I have been using fish for a year or so, and I also have no clue about arrays in fish... :-)

Re: GitHub – nushell/nushell: A new type of shell

#387

Post by emptyparadise »

dundarious wrote: post #367
roywashere wrote: post #359

Earlier quoted context omitted.

Oh and how /bin/bash is bash3 on macOS instead of the contemporary bash5 by default. And how sh is dash on Debian, or Ubuntu, I forgot. Some of the reasons why I would prefer python3 scripts (or perl) over sh or bash

Pretty annoying to reliably #! to python3 as well. Is it /usr/bin/python or python3?

/usr/bin/env python3

Re: GitHub – nushell/nushell: A new type of shell

#388

Post by vkoskiv »

Macha wrote: post #199
vkoskiv wrote: post #87

Earlier quoted context omitted.

Binary releases seem uncommon from my perspective. Every time I go to install a piece of software written in Rust from homebrew, it invariably starts installing some massive Rust toolchain as a dependency, at which point I give up and move on. Maybe it's a case of the packagers taking a lazy route or something, or maybe there is a reason for depending on cargo. I have no idea.

Isn't homebrew specifically supposed to build from source? e.g. the example on the homepage of a recipe is running ./configure && make on wget. The fact that you installed the XCode CLI tools for that wget example to work when you first installed homebrew because homebrew itself requires it, and you only get Cargo the first time you get a rust dependency seems to be what you're really complaining about.

Homebrew tries to install binaries by default. (They call them bottles) Building from source happens if a suitable 'bottle' isn't available, or when `--build-from-source` is specified with the install command.

I know cargo is installed only once, but I don't want cargo. I don't build Rust software myself, so I don't want to have it hanging out on my system taking up space purely just so I can have one or two useful programs that were written in Rust and depend on it. I'll just go with some other alternative.

Re: GitHub – nushell/nushell: A new type of shell

#389

Post by vkoskiv »

indemnity wrote: post #180
vkoskiv wrote: post #87

Earlier quoted context omitted.

Binary releases seem uncommon from my perspective. Every time I go to install a piece of software written in Rust from homebrew, it invariably starts installing some massive Rust toolchain as a dependency, at which point I give up and move on. Maybe it's a case of the packagers taking a lazy route or something, or maybe there is a reason for depending on cargo. I have no idea.

Do you have some specific examples? E.g. ripgrep is packaged on most operating systems I have used, along with exa, and a few other Rust utils I use. I certainly do not use Cargo to install them.

Perhaps the packagers on your platform went that extra mile to build binary packages. Taking a quick look, the Homebrew formula[0] for ripgrep on macOS just lists a dependency on Cargo (rust) and then seems to invoke the cargo command for installation. I'm not well versed in Ruby though, so my interpretation could be wrong.

I don't want to come off as entitled, either. I know the Homebrew folks are doing a ton of brilliant, ongoing work to make it work as well as it does, so I can't really blame them for potentially taking a shortcut here.

[0] https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/...

Re: GitHub – nushell/nushell: A new type of shell

#390

Post by tomduncalf »

silentguy wrote: post #308
tomduncalf wrote: post #72

Looks pretty cool. Anecdotally, I found switching shell to be more of a challenge than expected - I’ve been using (oh-my-)zsh for years and decided to try fish, but all the little differences were too annoying for me to get used to - I guess you build up a lot of “muscle memory”! That said, I probably just use the same commands most of the time. If you were doing more advanced stuff maybe it makes more sense to inves…

I think you can achieve most of the fish features in zsh with the help of plugins. The most compelling feature of fish was history substring search. You type something, press up button and you get a command in history with that substring. I used 'history-substring-search' plugin to achieve that. There are also 'syntax-highlighting' and 'completion' plugins which bring fish shell features to zsh. I use prezto for its…

Good tip, thanks!
Post reply on HN