4 ms·

There is nothing wrong with complex code that is correct and readable. I imagine those who have a problem with the GNU version have not done a lot of shell scri

There is nothing wrong with complex code that is correct and readable. I imagine those who have a problem with the GNU version have not done a lot of shell scripting and therefore don't see a need for the complexity. The system V version would really suck in a lot of situations. Of course people love to criticize because it makes it sound like they know something.

angersock 12y ago
Generally no, other than the fact that it is complex--complexity itself is a sin. Always has been, always will be, though it can be forgiven. Anyways, what's the issue with the System V version, other than not handling newlines? Also, what is the purpose with the Plan 9 loading the thing into a buffer first, other than perhaps to get the benefit of an all-or-nothing write? I suspect weirdness with the Plan 9 file handling but am not certain.
- sangnoir 12y ago
  Correctness beats complexity any day. Incorrectness is an unforgivable sin.
- sjolsen 12y ago
  >complexity itself is a sin Complexity is inherent to any task in some degree. That complexity must be expressed in full in any program which performs that task correctly, whether in terms of language/library constructions or the ways in which those are combined. When the tools with which you implement a task (here, C and the core Unix API) are structured substantially differently than the high-level concepts of which that task is composed, there is additional complexity inherent to mapping those concepts. In light of that, I don't understand what you mean by, "complexity itself is a sin," unless you're referring specifically to the strictly unnecessary complexity introduced by a sub-optimal mapping of high-level semantics to core constructs. I don't think that's the kind of complexity we're seeing here. I think we're seeing the complexity inherent to mapping shell-level semantics to C semantics and the semantics of the Unix API, specifically error-handling semantics. I agree with jws that what this code demonstrates is that the core Unix API is difficult to use for writing precisely correct high-level programs, even ones as simple as echo. I feel that this is exactly why it's important that core high-level programs like echo encapsulate as much of the complexity of mapping to C as possible (that is, in the style of GNU rather than SysV): so that one can easily write reliable programs with high-level tools like the shell without worrying about that complexity.
stonogo 12y ago
Those of us who program in shells that are not broken do not need echo to do tricks for us.
- jcoffland 12y ago
  You must be a *BSD user.

angersock 12y ago

Generally no, other than the fact that it is complex--complexity itself is a sin. Always has been, always will be, though it can be forgiven. Anyways, what's the issue with the System V version, other than not handling newlines? Also, what is the purpose with the Plan 9 loading the thing into a buffer first, other than perhaps to get the benefit of an all-or-nothing write? I suspect weirdness with the Plan 9 file handling but am not certain.

sangnoir 12y ago
Correctness beats complexity any day. Incorrectness is an unforgivable sin.
sjolsen 12y ago
>complexity itself is a sin Complexity is inherent to any task in some degree. That complexity must be expressed in full in any program which performs that task correctly, whether in terms of language/library constructions or the ways in which those are combined. When the tools with which you implement a task (here, C and the core Unix API) are structured substantially differently than the high-level concepts of which that task is composed, there is additional complexity inherent to mapping those concepts. In light of that, I don't understand what you mean by, "complexity itself is a sin," unless you're referring specifically to the strictly unnecessary complexity introduced by a sub-optimal mapping of high-level semantics to core constructs. I don't think that's the kind of complexity we're seeing here. I think we're seeing the complexity inherent to mapping shell-level semantics to C semantics and the semantics of the Unix API, specifically error-handling semantics. I agree with jws that what this code demonstrates is that the core Unix API is difficult to use for writing precisely correct high-level programs, even ones as simple as echo. I feel that this is exactly why it's important that core high-level programs like echo encapsulate as much of the complexity of mapping to C as possible (that is, in the style of GNU rather than SysV): so that one can easily write reliable programs with high-level tools like the shell without worrying about that complexity.

stonogo 12y ago

Those of us who program in shells that are not broken do not need echo to do tricks for us.

jcoffland 12y ago
You must be a *BSD user.