I’m not even sure what strucrued data would really mean, so I’m pretty sure it’s not useful to my usecase lol
Probably not, but to give an easy example:
~> ls | where modified >= (date now) - 30day
╭───┬───────────┬──────┬────────┬────────────╮
│ # │ name │ type │ size │ modified │
├───┼───────────┼──────┼────────┼────────────┤
│ 0 │ Downloads │ dir │ 4,0 kB │ 4 days ago │
│ 1 │ Musik │ dir │ 4,0 kB │ a week ago │
╰───┴───────────┴──────┴────────┴────────────╯
Here, ls doesn’t just return a string representing directory content as text, but a table where each file is an entry with attributes that have their own data type (e.g. size is Filesize while modified is Datetime). That’s why I’m able to filter based on one of them; that part isn’t part of ls, but of the shell itself. In a classic shell, this filtering would need to be handled in the originating binary in its own specific way, or you’d need to parse its output, transform it using tools like sed and awk etc. This here is a special case because ls is built into the shell; for non-builtin commands, if they offer it, you can have them output structured data as json or something else and read it into nu, like
~> ip -j a | from json | where {|device| $device.address? != nulland$device.addr_info? != [] and$device.link_type =~ "ether"} | get addr_info.0 | select -o local broadcast scope
╭───┬────────────────────────────────────────┬─────────────────┬────────╮
│ # │ local │ broadcast │ scope │
├───┼────────────────────────────────────────┼─────────────────┼────────┤
│ 0 │ 192.168.178.72 │ 192.168.178.255 │ global │
│ 1 │ 2001:9e8:4727:2c00:3071:91ff:fed1:9e26 │ │ global │
│ 2 │ fdaa:66e:6af0:0:3071:91ff:fed1:9e26 │ │ global │
│ 3 │ fe80::3071:91ff:fed1:9e26 │ │ link │
╰───┴────────────────────────────────────────┴─────────────────┴────────╯
It’s kind of cool, but I don’t need it that often either, so I just play around with it when I feel like it.
Probably not, but to give an easy example:
~> ls | where modified >= (date now) - 30day ╭───┬───────────┬──────┬────────┬────────────╮ │ # │ name │ type │ size │ modified │ ├───┼───────────┼──────┼────────┼────────────┤ │ 0 │ Downloads │ dir │ 4,0 kB │ 4 days ago │ │ 1 │ Musik │ dir │ 4,0 kB │ a week ago │ ╰───┴───────────┴──────┴────────┴────────────╯
Here,
ls
doesn’t just return a string representing directory content as text, but a table where each file is an entry with attributes that have their own data type (e.g.size
isFilesize
whilemodified
isDatetime
). That’s why I’m able to filter based on one of them; that part isn’t part ofls
, but of the shell itself. In a classic shell, this filtering would need to be handled in the originating binary in its own specific way, or you’d need to parse its output, transform it using tools likesed
andawk
etc. This here is a special case becausels
is built into the shell; for non-builtin commands, if they offer it, you can have them output structured data as json or something else and read it into nu, like~> ip -j a | from json | where {|device| $device.address? != null and $device.addr_info? != [] and $device.link_type =~ "ether"} | get addr_info.0 | select -o local broadcast scope ╭───┬────────────────────────────────────────┬─────────────────┬────────╮ │ # │ local │ broadcast │ scope │ ├───┼────────────────────────────────────────┼─────────────────┼────────┤ │ 0 │ 192.168.178.72 │ 192.168.178.255 │ global │ │ 1 │ 2001:9e8:4727:2c00:3071:91ff:fed1:9e26 │ │ global │ │ 2 │ fdaa:66e:6af0:0:3071:91ff:fed1:9e26 │ │ global │ │ 3 │ fe80::3071:91ff:fed1:9e26 │ │ link │ ╰───┴────────────────────────────────────────┴─────────────────┴────────╯
It’s kind of cool, but I don’t need it that often either, so I just play around with it when I feel like it.