3 ms·

Competing implementations sounds like a potential downside to me. That’s just more possible configurations where a bug could be hiding. Even if you use standard

Competing implementations sounds like a potential downside to me. That’s just more possible configurations where a bug could be hiding. Even if you use standard posix shell, you’d be wise to target a single implementation and stick to it.

Sir_Cmpwn 8y ago
So you think that competition between gcc and clang is harmful to the C and C++ ecosystems? If you find bugs in an implementation of POSIX sh, you should report it to that implementation. Multiple competing implementations is a sign of a good standard, it proves the standard's correctness and demonstrates its maturity. There is no standard to hold bash to. Any strange behavior of it might be decided as by design and kept forever (and replicated by anything which tries to be bash compatible) or it could be determined to be a bug and, when fixed, break the scripts which worked around it or depended on it. There's no way to know how this is going to shake out because there is no objective specification for the language. At least when there's a bug in one of these competing sh implementations that you're so worried about, it's objectively a bug and can be fixed.
- marcoperaza 8y ago
  To be more precise, my point was that you should only be targeting one of the implementations anyway. I don't see how it's a good use of people's time to be testing their scripts against every shell that claims to be sh-compatible, especially at a place like Google where the scripts are almost all being written to run on completely Google-controlled environments. But I didn't think about the bug vs. by-design issue and how that is remedied by a well-defined standard. That does seem to be a factor in favor of using a standardized language. But it doesn’t seem different in principle than depending on any software. It is liable to change and leave you with a difficult decision of forking the library or modifying your code that consumes it. Given bash’s ubiquity, it seems reasonable to expect a good level of stability. If you only target standards, the lowest-common-denominator of functionality, you will be poorer for it. Linux, for example, has all sorts of performance and functionality enhancing features over what POSIX provides.
  - Sir_Cmpwn 8y ago
    >If you only target standards, the lowest-common-denominator of functionality, you will be poorer for it. In this case, you won't. I addressed this a few comments ago: >By the time you need the things bash offers you might as well not use a shell script at all
- jhasse 8y ago
  > competition between gcc and clang is harmful to the C and C++ ecosystems? Yes. GCC will die eventually.
_jal 8y ago
This is exactly backwards. If you don't have separation of specification and application, you don't have a specification. I mean, standards aren't necessary; interpreters can absolutely be snowflakes. But multiple implementations is a sign of strength, and intentionally targeting the bugs of one implementation is short sighted, if sometimes required.

Sir_Cmpwn 8y ago

So you think that competition between gcc and clang is harmful to the C and C++ ecosystems? If you find bugs in an implementation of POSIX sh, you should report it to that implementation. Multiple competing implementations is a sign of a good standard, it proves the standard's correctness and demonstrates its maturity. There is no standard to hold bash to. Any strange behavior of it might be decided as by design and kept forever (and replicated by anything which tries to be bash compatible) or it could be determined to be a bug and, when fixed, break the scripts which worked around it or depended on it. There's no way to know how this is going to shake out because there is no objective specification for the language. At least when there's a bug in one of these competing sh implementations that you're so worried about, it's objectively a bug and can be fixed.

marcoperaza 8y ago
To be more precise, my point was that you should only be targeting one of the implementations anyway. I don't see how it's a good use of people's time to be testing their scripts against every shell that claims to be sh-compatible, especially at a place like Google where the scripts are almost all being written to run on completely Google-controlled environments. But I didn't think about the bug vs. by-design issue and how that is remedied by a well-defined standard. That does seem to be a factor in favor of using a standardized language. But it doesn’t seem different in principle than depending on any software. It is liable to change and leave you with a difficult decision of forking the library or modifying your code that consumes it. Given bash’s ubiquity, it seems reasonable to expect a good level of stability. If you only target standards, the lowest-common-denominator of functionality, you will be poorer for it. Linux, for example, has all sorts of performance and functionality enhancing features over what POSIX provides.
- Sir_Cmpwn 8y ago
  >If you only target standards, the lowest-common-denominator of functionality, you will be poorer for it. In this case, you won't. I addressed this a few comments ago: >By the time you need the things bash offers you might as well not use a shell script at all
jhasse 8y ago
> competition between gcc and clang is harmful to the C and C++ ecosystems? Yes. GCC will die eventually.

_jal 8y ago

This is exactly backwards. If you don't have separation of specification and application, you don't have a specification. I mean, standards aren't necessary; interpreters can absolutely be snowflakes. But multiple implementations is a sign of strength, and intentionally targeting the bugs of one implementation is short sighted, if sometimes required.