Thanks @dmatos2012 for another great PR!

I'm wondering if uuname can just return the data instead of printing it out? It would be great to have something closer to $nu.os-info.

❯ $nu.os-info
╭────────────────┬─────────╮
│ name           │ windows │
│ arch           │ x86_64  │
│ family         │ windows │
│ kernel_version │ 22631   │
╰────────────────┴─────────╯

Maybe something like this

╭───────────────────┬─────────────────────────╮
│ kernel-name       │ Windows_NT              │
│ node-name         │ DESKTOP-1QK8J8G         │
│ kernel-release    │ 10.0                    │
│ kernel-version    │ 22631                   │
│ machine           │ x86_64                  │
│ processor         │ unknown                 │
│ hardware-platform │ unknown                 │
│ operating-system  │ MS/Windows (Windows 11) │
╰───────────────────┴─────────────────────────╯

Thanks @dmatos2012 for another great PR!

I'm wondering if uuname can just return the data instead of printing it out? It would be great to have something closer to $nu.os-info.

❯ $nu.os-info
╭────────────────┬─────────╮
│ name           │ windows │
│ arch           │ x86_64  │
│ family         │ windows │
│ kernel_version │ 22631   │
╰────────────────┴─────────╯

Thought about something similar as well to the output of ls , but wasnt exactly sure if thats something we wanted.

However, with your suggestion, it means there would be only one way of using it: namely uname, which will print out all the flags as record as you pointed out. i really like it, since it avoids the mess of all the -n, -p,-i. Will give it a try :)

ya, i think it would be more nushell-y just to print out a record if we can get the information.

Not quite right but looking better.

❯ uname 
╭──────────────────┬─────────────────────────╮
│ kernel-name      │ Windows_NT              │
│ nodename         │ MYHOSTNAME              │
│ kernel-release   │ 10.0                    │
│ kernel-version   │ 22631 x86_64 MS/Windows │
│ machine          │ (Windows                │
│ operating-system │ 11)                     │
╰──────────────────┴─────────────────────────╯

Much better now :)

Please check this and the uutils PR and let me know what you think. I realized that trying to parse the long string was no good because probably every system will output in a different way so we needed a more structured output from uutils.

As far as testing goes, given that we have no flags now, I think we will have to rely on their test harness at least for now.

Looks good on my windows box. I'll try to test it on mac later.

❯ uname
╭──────────────────┬─────────────────────────╮
│ kernel-name      │ Windows_NT              │
│ nodename         │ MYHOSTNAME              │
│ kernel-release   │ 10.0                    │
│ kernel-version   │ 22631                   │
│ machine          │ x86_64                  │
│ operating-system │ MS/Windows (Windows 11) │
╰──────────────────┴─────────────────────────╯

This is what my mac says. Long kernel-version, not saying that's bad, was just surprised.

❯ uname
╭──────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ kernel-name      │ Darwin                                                                                                │
│ nodename         │ M1X.local                                                                                             │
│ kernel-release   │ 23.3.0                                                                                                │
│ kernel-version   │ Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:44 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6000 │
│ machine          │ arm64                                                                                                 │
│ operating-system │ Darwin                                                                                                │
╰──────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────╯

I guess we're just waiting for the core-utils release. Is that correct?

I guess we're just waiting for the core-utils release. Is that correct?

Yes, technically we are waiting for it to be merged first, and then the release, but aside from that everything should be ready.

yay! one step closer.

yeah I think I somehow messed up the branch but should be fixed now @fdncred. So maybe time to take it for a ride and wait for the release of uutils. Looking forward for this getting released :)

It's kind of amazing how troublesome a little utility like this can be. I really appreciate all the effort doing the uutils PR and making changes here, so it works nushell-y. All good stuff. Thanks very much!

I guess we're still waiting for a coreutils release? @tertsdiepraam is there a coreutils release in our future? 🤣

🔮👀

My cristal ball says.... yes, should be fairly soon

Will this replace $env.os-info?

Will this replace $env.os-info?

no. $nu.os-info is a compile time variable that we plan on keeping. it's helpful because it's super fast.

yay, looks like coreutils 0.25 has been released

I think this should be ready to go now @fdncred ? The diff probably looks weird as I noticed all of the Cargo.toml were changed lol, but think should be good now :)

I'd like to keep all uu_* crates on the same version so I changed them all to 0.0.25. I think bad things may happen if we mix and match versions.

No clue what this means

The Cargo.lock just needs to be commited as well after the version bump. This check is aimed to catch bad tests or out of date Cargo.lock

Thanks again @dmatos2012!!