5 ms·

Would be interesting to test this out on SourceMage[0], seeing as how its package manager is written entirely in bash. [0] https://sourcemage.org/Intro https:/

Would be interesting to test this out on SourceMage[0], seeing as how its package manager is written entirely in bash. [0] https://sourcemage.org/Intro https://sourcemage.org/Intro

chubot 9y ago
Interesting, I didn't know about SourceMage. It appears to be a source-based distro like Gentoo, and if it's package manager is written in bash, it's a perfect use case. Since I have my hands full with the distros I'm using, I may not be able to try it for awhile, but I saved this page for further reading. I still think distros are somewhat "broken", so alternative approaches are interesting to me. (Just one problem off the top of my head: packages are old, distros can't keep up with PyPI, npm, CRAN, etc.) If you know the SourceMage code, please try it with OSH :) Or if you know its developers, they might want to hear about a cleaner shell that's compatible with bash (although it's nascent) I spent some time last fall implementing some constructs that the Nix package manager uses, even though I don't use Nix. Nix uses bash heavily as well.
- igravious 9y ago
  Hey, love your project's ambition but I think it's unhelpful if you say things like, “ I still think distros are somewhat "broken", so alternative approaches are interesting to me.” (Think of all the work you've put into your shell project, now think of how much integration work must be done to keep a distro going.) That said, I think you've highlighted _the_ problem that _all_ distros face that would get me to change distros if someone solved it. That is to say, “(Just one problem off the top of my head: packages are old, distros can't keep up with PyPI, npm, CRAN, etc.)” That is a doozy of a problem. One last thing–you mention four things: The trap builtin is unimplemented; alias is also unimplemented. set -h / hashall is a stub that does nothing. OSH builds are in a sense "shallow". Is there some way to get OSH to be un-shallow? For instance if I've invoked a shell script with OSH I'd probably like any shell script dialect that it can handle to have OSH invoked as well. Also, surely it would help you out with debugging OSH because you'd immediately way more lines of shell script! Implementing `trap', `alias', `set -h' seem like no-brainers prior to 0.4
  - chubot 9y ago
    Hm I probably could have said "distros are suboptimal" and it would have meant essentially the same thing. But I wasn't disparaging anyone's work, if that's your concern. "Debian is broken" would be closer to that, but I didn't say that. :) But yes I do think distros are doing the best they can with the raw material they have to work with (upstream sources, autoconf, etc.) I have some ideas for a distro but I think I have my hands full with shell, and it is a big problem because you can't do it by yourself. You need an army to help you maintain packages to some standard! ----- For the shallow problem, I'll probably implement something like set -o hijack-shebang. It's relatively easy for OSH to open scripts it runs and check for a shebang that looks like a shell, and then prepend "osh" to the argv array. It should really only be used for debugging OSH, because it wouldn't be good practice to "lie" about your shebangs. That logic is fundamental and baked into the kernel! "trap" has come up a lot, although I'm not sure if it will be in the 0.4 release. I'm making releases pretty often -- every 6 weeks or so. "alias" is interesting because it sits between the lexer and the parser, and no other shell feature is like that.
    - igravious 9y ago
      Or symlinks to OSH of the various shells it can emulate?
      - chubot 9y ago
        Yes that's true, I should add the ability to symlink /bin/bash or ~/bin/bash to the oil binary and have it work. It actually works in this "busybox" style already, but it only supports a few names like "osh" and "sh". I didn't mention that because it's not a good idea yet to make OSH the default shell on any system :)
        igravious 9y ago
        But for your test suite and testing OS build systems to wring out incompatibilities and bugs it might work a treat (if it detects certain environment variables). Sounds great! You put so much effort into your blog posts, it's impressive…

Would be interesting to test this out on SourceMage[0], seeing as how its package manager is written entirely in bash. [0] https://sourcemage.org/Intro https://sourcemage.org/Intro

chubot 9y ago

Interesting, I didn't know about SourceMage. It appears to be a source-based distro like Gentoo, and if it's package manager is written in bash, it's a perfect use case. Since I have my hands full with the distros I'm using, I may not be able to try it for awhile, but I saved this page for further reading. I still think distros are somewhat "broken", so alternative approaches are interesting to me. (Just one problem off the top of my head: packages are old, distros can't keep up with PyPI, npm, CRAN, etc.) If you know the SourceMage code, please try it with OSH :) Or if you know its developers, they might want to hear about a cleaner shell that's compatible with bash (although it's nascent) I spent some time last fall implementing some constructs that the Nix package manager uses, even though I don't use Nix. Nix uses bash heavily as well.

igravious 9y ago
Hey, love your project's ambition but I think it's unhelpful if you say things like, “ I still think distros are somewhat "broken", so alternative approaches are interesting to me.” (Think of all the work you've put into your shell project, now think of how much integration work must be done to keep a distro going.) That said, I think you've highlighted _the_ problem that _all_ distros face that would get me to change distros if someone solved it. That is to say, “(Just one problem off the top of my head: packages are old, distros can't keep up with PyPI, npm, CRAN, etc.)” That is a doozy of a problem. One last thing–you mention four things: The trap builtin is unimplemented; alias is also unimplemented. set -h / hashall is a stub that does nothing. OSH builds are in a sense "shallow". Is there some way to get OSH to be un-shallow? For instance if I've invoked a shell script with OSH I'd probably like any shell script dialect that it can handle to have OSH invoked as well. Also, surely it would help you out with debugging OSH because you'd immediately way more lines of shell script! Implementing `trap', `alias', `set -h' seem like no-brainers prior to 0.4
- chubot 9y ago
  Hm I probably could have said "distros are suboptimal" and it would have meant essentially the same thing. But I wasn't disparaging anyone's work, if that's your concern. "Debian is broken" would be closer to that, but I didn't say that. :) But yes I do think distros are doing the best they can with the raw material they have to work with (upstream sources, autoconf, etc.) I have some ideas for a distro but I think I have my hands full with shell, and it is a big problem because you can't do it by yourself. You need an army to help you maintain packages to some standard! ----- For the shallow problem, I'll probably implement something like set -o hijack-shebang. It's relatively easy for OSH to open scripts it runs and check for a shebang that looks like a shell, and then prepend "osh" to the argv array. It should really only be used for debugging OSH, because it wouldn't be good practice to "lie" about your shebangs. That logic is fundamental and baked into the kernel! "trap" has come up a lot, although I'm not sure if it will be in the 0.4 release. I'm making releases pretty often -- every 6 weeks or so. "alias" is interesting because it sits between the lexer and the parser, and no other shell feature is like that.
  - igravious 9y ago
    Or symlinks to OSH of the various shells it can emulate?
    - chubot 9y ago
      Yes that's true, I should add the ability to symlink /bin/bash or ~/bin/bash to the oil binary and have it work. It actually works in this "busybox" style already, but it only supports a few names like "osh" and "sh". I didn't mention that because it's not a good idea yet to make OSH the default shell on any system :)
      - igravious 9y ago
        But for your test suite and testing OS build systems to wring out incompatibilities and bugs it might work a treat (if it detects certain environment variables). Sounds great! You put so much effort into your blog posts, it's impressive…