@david_chisnall @swetland I tried to live with nushell for a while to get some of this in a mature setup, and the structured stuff it has can be nice. In the end I found it just isn't enough of a _shell_ for me. I wouldn't necessarily have predicted that I'd never give up expansions before giving nushell a real try, but the constant reordering things for interpolation instead I just never got over. nushell is also massive because it carries the kitchen sink inside the shell itself
@raggi @david_chisnall @swetland yeah the massive binary and depedency tree put me off. it feels like giving up something important
@whitequark @raggi @david_chisnall David's approach is extremely appealing because it allows for support to be incrementally added to things rather than requiring an all-or-nothing shift to get the fancier behaviors.
It does have the friction of needing a kernel patch... so even if various kernel projects are willing to pick it up without a lot of deliberation and debate it'd take a while to percolate, but then again the magic of open source is you can actually have experimental kernel patches.
@whitequark @raggi @david_chisnall I think you could actually do a version of this as a driver rather than a subsystem change (so it'd be really easy to build just a single little module rather than having to do a whole kernel rebuild). Basically have the driver just have a couple ioctls where you use the driver fd to invoke the content negotiation actions on a pipe fd you pass in, just one level of indirection.
@swetland @raggi @david_chisnall oh yeah that would work!
@whitequark @raggi @david_chisnall On the userspace side code could try to open /dev/content-negotiation, try the direct ioctls (once they exist), and fall back to good 'ol plaintext if neither are available.
The down side of that approach is that it interacts poorly with sandboxing. Now every process that you might invoke interactively needs permission to access a new path.