This could really use a short, pithy code example at the start of the readme to show what it looks like. Otherwise, you have to get pretty far into the docs to see any actual commands, or click the example link which doesn’t display well on mobile.
A very old and beloved pig, but still alas, a pig.
It's great to extend the shell idiom, to patch up its inconsistencies and unportabilites, to make it better. I love the progression of sh, csh, tcsh, ksh, bash, zsh, fish, and others. But it's also Sisyphean. At the end, you still have a shell experience not a programming language experience. And as long as we're talking about programming things, the full toolset will remain more direct, more powerful, more maintainable—and thus more apt.
I hate gol-lumping over the gap between a dashed-off Bash or Zsh script and the Python equivalent (say), but the full language has better semantics, typing, exceptions, modules, data structures, expressive power, and tooling. As the person who not only has to dash off the initial POC but extend and maintain it over time, and someone who's tried both routes, if there's any complexity at all—any datetimes, timestamps, or timezones to be wrangled; any complex JSON to be parsed out of an API; any significant parsing or concurrency to be managed—going to prefer the full tools every time.
I've been using it as my shell for 2-3 years, and it has improved a LOT since then. The interactive experience is great, and it's wonderful assembling scripts in its REPL. I can use my editor to edit the bufferline too using ctrl+o.
The best thing about it is that's it's self-contained. You don't have to assume anything about the users environment, as Nushell has almost everything you'd need fot common tasks built-in.
Modern cmd line scripting is an interesting area and I like seeing people's different approaches to improving it. Personally, I want to get as far away from writing control flow, loops, etc in Bash as I can. I'm working on https://github.com/amterp/rad which is a CLI scripting language that takes a more Python-like approach, which people here might find interesting, though it serves slightly different cases than Modernish.
I greatly appreciate these kinds of tools but I always err on the side of what's installed by default wherever possible so I can work across hosts as soon as i land
agreed. and the setup for this tool in particular looks… complicated and annoying, at least at first glance
for myself, if i want a shell script to be _portable_ i just write it in POSIX sh and try to be smart about dependencies
and if i don't care about portability, i'd rather just use a nicer shell like bash or zsh or fish (i'd actually like to mess with ysh at some point)
i feel like i'm much more likely to encounter a system with one of those shells available than one with modernish installed, and the idea of introducing a bundling/build step into shell scripts is deeply unappealing to me.
i can see why this exists, i think, and i imagine there are people who find it useful. i simply am not among them.
i also find it disappointing that their most basic example shows the setup in bash instead of sh, but that might just be me.
I get wanting some level of portability, but what kind of systems do you still encounter (and want to run your scripts on) that have sh yet lack Bash? I would've expected that to be the baseline nowadays.
For me it's small alpine containers running in k8s, and trying to get weird stuff running on my kobo ereader (can quickly get to a chroot with bash, but the base system doesn't have it).
Their `use` shell function should really be `use1` and `use` should process its whole argument list. Then their opening example could be `use safe sys/base` and "dialect tweaking" can be just one line with the option but not requirement to be multiple lines. Just a thought.
Comparison with Bash, from https://github.com/modernish/modernish/blob/master/EXAMPLES....
# Plain POSIX sh
# ModernishThis could really use a short, pithy code example at the start of the readme to show what it looks like. Otherwise, you have to get pretty far into the docs to see any actual commands, or click the example link which doesn’t display well on mobile.
Said with love: This is lipstick on a pig.
A very old and beloved pig, but still alas, a pig.
It's great to extend the shell idiom, to patch up its inconsistencies and unportabilites, to make it better. I love the progression of sh, csh, tcsh, ksh, bash, zsh, fish, and others. But it's also Sisyphean. At the end, you still have a shell experience not a programming language experience. And as long as we're talking about programming things, the full toolset will remain more direct, more powerful, more maintainable—and thus more apt.
I hate gol-lumping over the gap between a dashed-off Bash or Zsh script and the Python equivalent (say), but the full language has better semantics, typing, exceptions, modules, data structures, expressive power, and tooling. As the person who not only has to dash off the initial POC but extend and maintain it over time, and someone who's tried both routes, if there's any complexity at all—any datetimes, timestamps, or timezones to be wrangled; any complex JSON to be parsed out of an API; any significant parsing or concurrency to be managed—going to prefer the full tools every time.
Many such cases.
Nushell fixes this: https://nushell.sh/
I've been using it as my shell for 2-3 years, and it has improved a LOT since then. The interactive experience is great, and it's wonderful assembling scripts in its REPL. I can use my editor to edit the bufferline too using ctrl+o.
The best thing about it is that's it's self-contained. You don't have to assume anything about the users environment, as Nushell has almost everything you'd need fot common tasks built-in.
Some example scripts I've written:
- Link all files in a dir & deduplicate based on hash, in parallel, handling all cases: https://github.com/RGBCube/random-scripts/blob/master/linear... - A simple github->forgejo migration/live mirroring script: https://github.com/RGBCube/GitHub2Forgejo/blob/master/github...
All of these only need nushell, and not even coreutils.
Modern cmd line scripting is an interesting area and I like seeing people's different approaches to improving it. Personally, I want to get as far away from writing control flow, loops, etc in Bash as I can. I'm working on https://github.com/amterp/rad which is a CLI scripting language that takes a more Python-like approach, which people here might find interesting, though it serves slightly different cases than Modernish.
I greatly appreciate these kinds of tools but I always err on the side of what's installed by default wherever possible so I can work across hosts as soon as i land
agreed. and the setup for this tool in particular looks… complicated and annoying, at least at first glance
for myself, if i want a shell script to be _portable_ i just write it in POSIX sh and try to be smart about dependencies
and if i don't care about portability, i'd rather just use a nicer shell like bash or zsh or fish (i'd actually like to mess with ysh at some point)
i feel like i'm much more likely to encounter a system with one of those shells available than one with modernish installed, and the idea of introducing a bundling/build step into shell scripts is deeply unappealing to me.
i can see why this exists, i think, and i imagine there are people who find it useful. i simply am not among them.
i also find it disappointing that their most basic example shows the setup in bash instead of sh, but that might just be me.
I get wanting some level of portability, but what kind of systems do you still encounter (and want to run your scripts on) that have sh yet lack Bash? I would've expected that to be the baseline nowadays.
For me it's small alpine containers running in k8s, and trying to get weird stuff running on my kobo ereader (can quickly get to a chroot with bash, but the base system doesn't have it).
It's all written in shell, no other dependencies. This is what so many shells that tried to "revitalize" sh missed! I'll definitely adopt this.
Their `use` shell function should really be `use1` and `use` should process its whole argument list. Then their opening example could be `use safe sys/base` and "dialect tweaking" can be just one line with the option but not requirement to be multiple lines. Just a thought.
Perfect name!