8 ms·

> Uses a package manager written in less than 1000 lines of POSIX sh (excluding blank lines and comments). Enough to get 20 bugs :-). I wish there was a good s

> Uses a package manager written in less than 1000 lines of POSIX sh (excluding blank lines and comments). Enough to get 20 bugs :-). I wish there was a good standard alternative to bash (sh in this case) for shell programming. Otherwise I like the spirit, it's a good match with collapse os ;-)

pampa 6y ago
> I wish there was a good standard alternative to bash (sh in this case) for shell programming. There is perl! :)
tarruda 6y ago
For quite some time I've been using https://github.com/tarruda/python-ush https://github.com/tarruda/python-ush on personal scripts and it is working very well. If you like python, I recommend giving it a try :)
- deleted 6y ago
  [deleted]
rwnspace 6y ago
Could you explain more re: bugs? Dylan Araps sort of specialises in well-written (ba)sh and iirc uses shellcheck meticulously. I ask not to be combative in case you're just making a casual joke - more I'd like understand how bugs might creep in to (ba)sh code - even if say, one follows shellcheck and is as competent as Dylan.
- Kototama 6y ago
  I saw that after posting. It's not a critic of Dylan's work, more a critic of how difficult it is to write good bash code. Your comment on shellcheck and Dylan expertise just confirm it. It's like C, you could write safe C but it's very difficult. I wish there was a language with the ubiquity of Bash but modern and safe.
  - rwnspace 6y ago
    Ah I'm with you, thanks for the explanation - you're quite right. I've done a fair bit of bash and still I fully expect parts of the syntax to escape my memory. A modern and safe shell would be oil [0], ubiquity is WIP. [0] http://www.oilshell.org/ http://www.oilshell.org/
  - cpach 6y ago
    »I wish there was a language with the ubiquity of Bash but modern and safe« I agree. But reaching such a point would be hard. Not impossible, but hard. I think the main problem would be to gain traction for an alternative. Because if one questions the status quo, then there are tons of alternative paths to go by. But which of them are viable…? It’s not easy to pick a winner in this kind of situtation. And most people, even in tech, would not want to spend hours on trying out/developing a new shell that won’t gain any significant traction. The Bourne shell was developed in the mid 70s. There were not many other scripting languages around then, so Bourne shell became a major player. They could probably have used Lisp if they wanted to, but AFAIK Lisp was not widespread within the Unix world back then. These days we have many other models for interpreted languages. Ruby, Python, Perl, TCL, Scheme, Clojure, etc etc. Let’s say someone wrote a Python-inspired shell that aimed to replace sh/Bash. Now you need to gain traction in order to build up a useful and sound ecosystem that has the ability to replace all those shell scripts out there. But how would you convince the Ruby fans or Scheme fans to use that? Therein lies a big challenge. Getting people to continue using sh is not as hard, since it at least is standard, despite its shortcomings. [Slightly edited.]
    - chubot 6y ago
      That's the point of Oil: https://github.com/oilshell/oil https://github.com/oilshell/oil A new Unix shell. Our upgrade path from bash to a better language. It runs thousands of lines of existing shell scripts unmodified, but there's also a brand new language that will be familiar to Python or JS programmers. See http://www.oilshell.org/blog/2020/01/simplest-explanation.html http://www.oilshell.org/blog/2020/01/simplest-explanation.ht... It works and you can try it now. The downside is that the implementation is more like a slow prototype, but that's being addressed, and the release I made today has stats about the C++ version (blog post forthcoming).
goldenkey 6y ago
One thing that irks me is the verbosity of simply renaming file extensions of all files in a directory. On Windows: ren ∗.js ∗.mjs On Unix: for x in ∗.js; do mv "$x" "${x%.js}.mjs"; done Feels like shells should have one line list comprehensions without the obtruse do/done. Are there any shell enhancements like zsh or the like, that make simple list operations less verbose?
- stutonk 6y ago
  Linux, at least, has rename(1) where you can just use the same syntax as Windows ren.
  - goldenkey 6y ago
    I know about that utility -- still not shell though. The fact that you need a utility to make such a simple task readable is pointing to the shell language lacking.
    - stutonk 6y ago
      By your own logic, your own UNIX solution to the file renaming problem is "not shell" since it uses the mv "utility". Or do you mean rename is not POSIX? The shell language certainly is lacking for almost anything beyond its original purpose of gluing together pipelines/graphs of UNIX commands; it's a largely unintentional DSL from the time before many modern notions of language ergonomics had become established. The point is, there is an array of solutions to reduce the nuisance of having to deal with the language equivalent of a stone knife such as programs like rename or actual general-purpose scripting languages. Sure, you can cut most things with a stone knife with enough time and effort but why would you if you have a bunch of sharp, metal knives within easy reach?
      - goldenkey 6y ago
        Okay so how would it be done without mv..using the POSIX rename syscall? https://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html https://pubs.opengroup.org/onlinepubs/009695399/functions/re... mv is basically just a shim over rename so I don't see your point. Shell may be to glue things together but it's supposed to also be a decent language for doing file/filename related things.
sirn 6y ago
> I wish there was a good standard alternative to bash (sh in this case) for shell programming. I would say Tcl! Tcl is one of the most underrated programming language that everybody probably has installed. It has existed for as long as ksh and even long before bash. It is simple and powerful enough that first version of Redis were written in it[1]. MacPorts is written in Tcl (including its ports DSL) and I enjoyed every moment working with it. [1]: https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e88a8 https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...
- nrclark 6y ago
  Agreed 100% with this. TCL is a super cool language IMO. It's mature, unixy, and has minimal external dependencies. The ecosystem is stable and slow moving. I would encourage anybody to try it out! The syntax takes some adjustment because it's not lval/rval-based, which is maybe why it's not so widely used now. But if you want a language that's more robust than shell and more minimal than Python, consider TCL for your next project.
  - deleted 6y ago
    [deleted]

pampa 6y ago

> I wish there was a good standard alternative to bash (sh in this case) for shell programming. There is perl! :)

tarruda 6y ago

For quite some time I've been using https://github.com/tarruda/python-ush https://github.com/tarruda/python-ush on personal scripts and it is working very well. If you like python, I recommend giving it a try :)

deleted 6y ago
[deleted]

rwnspace 6y ago

Could you explain more re: bugs? Dylan Araps sort of specialises in well-written (ba)sh and iirc uses shellcheck meticulously. I ask not to be combative in case you're just making a casual joke - more I'd like understand how bugs might creep in to (ba)sh code - even if say, one follows shellcheck and is as competent as Dylan.

Kototama 6y ago
I saw that after posting. It's not a critic of Dylan's work, more a critic of how difficult it is to write good bash code. Your comment on shellcheck and Dylan expertise just confirm it. It's like C, you could write safe C but it's very difficult. I wish there was a language with the ubiquity of Bash but modern and safe.
- rwnspace 6y ago
  Ah I'm with you, thanks for the explanation - you're quite right. I've done a fair bit of bash and still I fully expect parts of the syntax to escape my memory. A modern and safe shell would be oil [0], ubiquity is WIP. [0] http://www.oilshell.org/ http://www.oilshell.org/
- cpach 6y ago
  »I wish there was a language with the ubiquity of Bash but modern and safe« I agree. But reaching such a point would be hard. Not impossible, but hard. I think the main problem would be to gain traction for an alternative. Because if one questions the status quo, then there are tons of alternative paths to go by. But which of them are viable…? It’s not easy to pick a winner in this kind of situtation. And most people, even in tech, would not want to spend hours on trying out/developing a new shell that won’t gain any significant traction. The Bourne shell was developed in the mid 70s. There were not many other scripting languages around then, so Bourne shell became a major player. They could probably have used Lisp if they wanted to, but AFAIK Lisp was not widespread within the Unix world back then. These days we have many other models for interpreted languages. Ruby, Python, Perl, TCL, Scheme, Clojure, etc etc. Let’s say someone wrote a Python-inspired shell that aimed to replace sh/Bash. Now you need to gain traction in order to build up a useful and sound ecosystem that has the ability to replace all those shell scripts out there. But how would you convince the Ruby fans or Scheme fans to use that? Therein lies a big challenge. Getting people to continue using sh is not as hard, since it at least is standard, despite its shortcomings. [Slightly edited.]
  - chubot 6y ago
    That's the point of Oil: https://github.com/oilshell/oil https://github.com/oilshell/oil A new Unix shell. Our upgrade path from bash to a better language. It runs thousands of lines of existing shell scripts unmodified, but there's also a brand new language that will be familiar to Python or JS programmers. See http://www.oilshell.org/blog/2020/01/simplest-explanation.html http://www.oilshell.org/blog/2020/01/simplest-explanation.ht... It works and you can try it now. The downside is that the implementation is more like a slow prototype, but that's being addressed, and the release I made today has stats about the C++ version (blog post forthcoming).

goldenkey 6y ago

One thing that irks me is the verbosity of simply renaming file extensions of all files in a directory. On Windows: ren ∗.js ∗.mjs On Unix: for x in ∗.js; do mv "$x" "${x%.js}.mjs"; done Feels like shells should have one line list comprehensions without the obtruse do/done. Are there any shell enhancements like zsh or the like, that make simple list operations less verbose?

stutonk 6y ago
Linux, at least, has rename(1) where you can just use the same syntax as Windows ren.
- goldenkey 6y ago
  I know about that utility -- still not shell though. The fact that you need a utility to make such a simple task readable is pointing to the shell language lacking.
  - stutonk 6y ago
    By your own logic, your own UNIX solution to the file renaming problem is "not shell" since it uses the mv "utility". Or do you mean rename is not POSIX? The shell language certainly is lacking for almost anything beyond its original purpose of gluing together pipelines/graphs of UNIX commands; it's a largely unintentional DSL from the time before many modern notions of language ergonomics had become established. The point is, there is an array of solutions to reduce the nuisance of having to deal with the language equivalent of a stone knife such as programs like rename or actual general-purpose scripting languages. Sure, you can cut most things with a stone knife with enough time and effort but why would you if you have a bunch of sharp, metal knives within easy reach?
    - goldenkey 6y ago
      Okay so how would it be done without mv..using the POSIX rename syscall? https://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html https://pubs.opengroup.org/onlinepubs/009695399/functions/re... mv is basically just a shim over rename so I don't see your point. Shell may be to glue things together but it's supposed to also be a decent language for doing file/filename related things.

sirn 6y ago

> I wish there was a good standard alternative to bash (sh in this case) for shell programming. I would say Tcl! Tcl is one of the most underrated programming language that everybody probably has installed. It has existed for as long as ksh and even long before bash. It is simple and powerful enough that first version of Redis were written in it[1]. MacPorts is written in Tcl (including its ports DSL) and I enjoyed every moment working with it. [1]: https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e88a8 https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...

nrclark 6y ago
Agreed 100% with this. TCL is a super cool language IMO. It's mature, unixy, and has minimal external dependencies. The ecosystem is stable and slow moving. I would encourage anybody to try it out! The syntax takes some adjustment because it's not lval/rval-based, which is maybe why it's not so widely used now. But if you want a language that's more robust than shell and more minimal than Python, consider TCL for your next project.
- deleted 6y ago
  [deleted]