3 ms·

I agree that PowerShell is theoretically better since it can deal with structured data. But in practice, I could never get as efficient with it as I could with

by doix 3y ago

I agree that PowerShell is theoretically better since it can deal with structured data. But in practice, I could never get as efficient with it as I could with "the Unix way" (everything is a string). If I was writing a "production" script, then it's better. But when I'm just trying to quickly do something on the command line, the "everything is a string" approach is good enough.

oblio 3y ago
The thing that we'd ideally want to happen, but will probably never will unless a mad person does it, would be to have something that wraps around a POSIX shell, and extends it in a sort of non-compatible way. Let's call this new tool $NEWSH. Larry Wall basically tried to do this with Perl but I guess his vision was too lax for such a pursuit, Perl tried to be everything, all at once. What I mean by this new approach is that this new tool would implement everything in POSIX shells, as a sort of v1 layer and then everything else and new and modern (typed, etc), as a sort of v2 layer. There would be simple ways to call back and forth between v1 and v2, but inside a layer, you couldn't mix and match (maybe you could do it with a construct such as "unsafe". Long term the idea would be that this tool becomes pervasive, installed and available everywhere and everyone can safely and reliably use just the v2 layer. The v2 layer would be extensible by design, so it can keep up with modern practices. You'd want to be able to go $NEWSH my-bash-script.sh and it should just work. $NEWSH my-newsh-script.nsh should also work, obviously. The reason this would never happen, IMO, is because it's a thankless job that needs to be done for at least 1 decade. This new shell would need to: - implement full POSIX shell compatibility - the v1 layer (done before, doable) - implement the new, designed from the ground up, language - the v2 layer (sort of done before by alternative shells, doable) - design a clever, simple to use, safe interop + unsafe construt for v2 (I imagine this would be hard) - package and promote this new thing, once it's stabilized, so that it's picked up by: Debian/Ubuntu/Mint, Arch, Fedora, FreeBSD, etc, and wait for literal decades for distribution to happen; Debian Stable and RHEL are especially egregious, since for ubiquity you'd want the new tool to be available in the 2 latest LTSes, so DevOps people can rely on its availability... so as I said, count 10 years for that (crazy hard and super boring) I said only a mad person would do this, because with this kind of volume and intensity of work, you can probably start a successful company or an open source project with much higher impact. Oh, and this project will be absolutely HATED (think "getting death threats" type of hate) by large parts of the community. See systemd.
- maleldil 3y ago
  This resembles OSH/YSH, especially the v1/v2 layer things. http://www.oilshell.org/ http://www.oilshell.org/
  - oblio 3y ago
    Yeah, that would be the only thing that sort of resembles what I'm saying, but I'm afraid it's biting off more that it can chew: the long term goal is to have some sort of distributed language plus it's using its own custom Python runtime of sorts, it's implemented in a convoluted way. Also, right now the project is a 1-man-show, for something of this magnitude to move fast enough it needs to become a full blown community project. Oh, Oil also need to mature. Osh IMHO needs to be fully usable as interactive shell (I don't think it is), it needs to be packaged for everything. It could be that Oil gets there but it's going to take a looong time. Oil itself was started in 2016, that was 7 years ago. I'm keeping an eye on it for sure and hoping it succeeds.
- chubot 3y ago
  (author here) Yeah you just repeated what https://oilshell.org/ https://oilshell.org/ is You'd want to be able to go $NEWSH my-bash-script.sh and it should just work. $NEWSH my-newsh-script.nsh should also work, obviously. osh my-bash-script.sh # works, it's the most bash-compatible shell by a mile ysh my-new-script.ysh # works YSH looks like this - https://www.oilshell.org/release/latest/doc/ysh-tour.html https://www.oilshell.org/release/latest/doc/ysh-tour.html (everything in this doc works, you can try it now) And then you do shopt -s ysh:upgrade to opt into new behavior. https://www.oilshell.org/release/0.19.0/doc/upgrade-breakage.html https://www.oilshell.org/release/0.19.0/doc/upgrade-breakage... YSH isn't done yet, but it's coming along nicely -- see the latest status update - https://www.oilshell.org/blog/2023/11/status-update.html https://www.oilshell.org/blog/2023/11/status-update.html --- The project isn't a solo project anymore! There have been 6 people funded by two NLNet grants, and we just got a third one, mentioned in the post. If you want it to succeed, then you should try it and report bugs. One way to view it is that Oils has a 7 year head start on any other project that wants upgrade shell. Like you say, it's a huge amount of work, and it's the ONLY project that's compatible with bash (which BTW is a much bigger job than being compatible with POSIX sh). Shell became the #6 fastest growing language on Github in 2020, so all those shell scripts people have written in the last few years make the Oils project more valuable. That is, people are writing scripts compatible with OSH at a greater rate than any other new shell (e.g. new shells == ones with precise error messages) The new command line tools like fd and bat are ALSO compatible with OSH and YSH because they use the Unix process interface :) There have been several shells that want to bundle everything into the shell, but I disagree with that philosophy, because it limits growth to being "inside" the project. (although YSH has a lot more functionality than bash built-in, like JSON support) --- People who have contributed are acknowledged in the release announcements. Testing is a good contribution. Writing weird HN comments isn't a good contribution :-P There has been some misunderstanding of the project, but very little "hate" ... Mostly encouragement!
agumonkey 3y ago
It's a very interesting topic, since the amount of brittle sed/grep/awk done by everybody using *nix on earth probably requires 128bits numbers, yet structured interactions does slow you down due to idiosyncracies. That said I wonder how quick things like powershell reward you. It's a bit like having a unit standard.

by doix 3y ago

oblio 3y ago

The thing that we'd ideally want to happen, but will probably never will unless a mad person does it, would be to have something that wraps around a POSIX shell, and extends it in a sort of non-compatible way. Let's call this new tool $NEWSH. Larry Wall basically tried to do this with Perl but I guess his vision was too lax for such a pursuit, Perl tried to be everything, all at once. What I mean by this new approach is that this new tool would implement everything in POSIX shells, as a sort of v1 layer and then everything else and new and modern (typed, etc), as a sort of v2 layer. There would be simple ways to call back and forth between v1 and v2, but inside a layer, you couldn't mix and match (maybe you could do it with a construct such as "unsafe". Long term the idea would be that this tool becomes pervasive, installed and available everywhere and everyone can safely and reliably use just the v2 layer. The v2 layer would be extensible by design, so it can keep up with modern practices. You'd want to be able to go $NEWSH my-bash-script.sh and it should just work. $NEWSH my-newsh-script.nsh should also work, obviously. The reason this would never happen, IMO, is because it's a thankless job that needs to be done for at least 1 decade. This new shell would need to: - implement full POSIX shell compatibility - the v1 layer (done before, doable) - implement the new, designed from the ground up, language - the v2 layer (sort of done before by alternative shells, doable) - design a clever, simple to use, safe interop + unsafe construt for v2 (I imagine this would be hard) - package and promote this new thing, once it's stabilized, so that it's picked up by: Debian/Ubuntu/Mint, Arch, Fedora, FreeBSD, etc, and wait for literal decades for distribution to happen; Debian Stable and RHEL are especially egregious, since for ubiquity you'd want the new tool to be available in the 2 latest LTSes, so DevOps people can rely on its availability... so as I said, count 10 years for that (crazy hard and super boring) I said only a mad person would do this, because with this kind of volume and intensity of work, you can probably start a successful company or an open source project with much higher impact. Oh, and this project will be absolutely HATED (think "getting death threats" type of hate) by large parts of the community. See systemd.

maleldil 3y ago
This resembles OSH/YSH, especially the v1/v2 layer things. http://www.oilshell.org/ http://www.oilshell.org/
- oblio 3y ago
  Yeah, that would be the only thing that sort of resembles what I'm saying, but I'm afraid it's biting off more that it can chew: the long term goal is to have some sort of distributed language plus it's using its own custom Python runtime of sorts, it's implemented in a convoluted way. Also, right now the project is a 1-man-show, for something of this magnitude to move fast enough it needs to become a full blown community project. Oh, Oil also need to mature. Osh IMHO needs to be fully usable as interactive shell (I don't think it is), it needs to be packaged for everything. It could be that Oil gets there but it's going to take a looong time. Oil itself was started in 2016, that was 7 years ago. I'm keeping an eye on it for sure and hoping it succeeds.
chubot 3y ago
(author here) Yeah you just repeated what https://oilshell.org/ https://oilshell.org/ is You'd want to be able to go $NEWSH my-bash-script.sh and it should just work. $NEWSH my-newsh-script.nsh should also work, obviously. osh my-bash-script.sh # works, it's the most bash-compatible shell by a mile ysh my-new-script.ysh # works YSH looks like this - https://www.oilshell.org/release/latest/doc/ysh-tour.html https://www.oilshell.org/release/latest/doc/ysh-tour.html (everything in this doc works, you can try it now) And then you do shopt -s ysh:upgrade to opt into new behavior. https://www.oilshell.org/release/0.19.0/doc/upgrade-breakage.html https://www.oilshell.org/release/0.19.0/doc/upgrade-breakage... YSH isn't done yet, but it's coming along nicely -- see the latest status update - https://www.oilshell.org/blog/2023/11/status-update.html https://www.oilshell.org/blog/2023/11/status-update.html --- The project isn't a solo project anymore! There have been 6 people funded by two NLNet grants, and we just got a third one, mentioned in the post. If you want it to succeed, then you should try it and report bugs. One way to view it is that Oils has a 7 year head start on any other project that wants upgrade shell. Like you say, it's a huge amount of work, and it's the ONLY project that's compatible with bash (which BTW is a much bigger job than being compatible with POSIX sh). Shell became the #6 fastest growing language on Github in 2020, so all those shell scripts people have written in the last few years make the Oils project more valuable. That is, people are writing scripts compatible with OSH at a greater rate than any other new shell (e.g. new shells == ones with precise error messages) The new command line tools like fd and bat are ALSO compatible with OSH and YSH because they use the Unix process interface :) There have been several shells that want to bundle everything into the shell, but I disagree with that philosophy, because it limits growth to being "inside" the project. (although YSH has a lot more functionality than bash built-in, like JSON support) --- People who have contributed are acknowledged in the release announcements. Testing is a good contribution. Writing weird HN comments isn't a good contribution :-P There has been some misunderstanding of the project, but very little "hate" ... Mostly encouragement!

agumonkey 3y ago

It's a very interesting topic, since the amount of brittle sed/grep/awk done by everybody using *nix on earth probably requires 128bits numbers, yet structured interactions does slow you down due to idiosyncracies. That said I wonder how quick things like powershell reward you. It's a bit like having a unit standard.