4 ms·

Just happened to see your reply here before I went off to sleep: https://news.ycombinator.com/item?id=19276012 https://news.ycombinator.com/item?id=19276012 I

• CarolineW 8y ago
  It's not a cop-out, we disagree. > Nor is finding "common ground" the goal (this is not some sort of compromise between political parties, it's a technical argument). We disagree. When there is a disagreement, finding what you agree with the the first step in finding where the lines of reasoning diverge. Finding common ground is the first step in resolving differences. > Getting things right is the goal. Sometimes in software there are judgement calls. Maybe this is one of them, maybe our definitions differ. Sometimes definitions differ because of context or experience. In each case, the terms used are not right or wrong, they are definitions that are useful in the context. > For which, sometimes one party or the other may have to admit they are wrong - including me. This is not an "I'm right, you're wrong" situation. By my experience, in my context, what you wrote would be called a "shell solution" in the same sense as the original command-line solution would be called a "shell solution." You think that invoking AWK from the command line means that it's still a command-line script. Your definition of the terms means that you accept that invoking AWK still lets you call it a "shell solution." I think that is fundamentally and structurally different from using command line utilities such as tr, sed, sort, and uniq. So my position is clear - your solution that you call "shell" is not, in my opinion, just "shell". To me, your solution is an AWK solution, and you feed the output from your AWK program through shell utilities. You are using the terms in a manner that is different from how I'm using them, that much is now clear. Do you agree that you have written a shell script that invokes a program written in AWK? Would it be different if you wrote a shell script that invoked a C program by calling a C interpreter? Would you still call it a "shell solution to the problem?" Does it matter? Really? I've made clear why I've said that I don't class your solution as being shell, why do you care?
• CarolineW 8y ago
  OK, so as kazinator has pointed out, awk is now a mandatory part of Posix, and so is genuinely a part of "shell". My reply there says that I and my colleagues still think of awk as fundamentally different from other pipeline facilities such as tr, sed, sort, uniq, and so on, but I can see why it could, perhaps should, be though of as being "shell". So it's shell. I might, however, given my background, and remembering as I do its first introduction, always have trouble thinking of it as such.
  • vram22 8y ago
    >OK, so as kazinator has pointed out, awk is now a mandatory part of Posix, and so is genuinely a part of "shell". Interesting. This gets steadily murkier. So, just because kazinator pointed it out, you now changed your mind, and awk is now 'genuinely part of "shell"'? Could you not have checked this first yourself, before your reply to my original comment, where I said that I wrote Python and shell solutions, and you disputed that my shell solution was a shell solution (it was an awk one, in your opinion)? It also means that you did not know that "awk was part of shell" despite your claimed "four decades" in the field, and your claiming to have read "most of the classics"! Not saying those two points are not true, but what have you learned from those, if you don't know the difference between a shell script and an awk script [1]? Hmmm ... >So it's shell. In fact, BTW, even though kazinator may have said that, quoting from a POSIX spec, in a pragmatic sense, for those of us who care about getting work done, shell and awk are still different things, and awk is not a "part of shell", at least, if by "shell" is meant the Unix command-line interpreter and script runner, like sh or ksh or bash or similar. If meant in a broader sense, as in the whole command-line Unix environment, then yes, awk could be, I suppose, loosely be considered as part of shell, although I think it makes more sense to call awk part of Unix, or Unix userland. And finally, you have now come around 180 degrees, and are now saying what I said: "it's shell", although I did not use those exact words. Also, I noticed what gerbilly said in reply to you, here: https://news.ycombinator.com/item?id=19280634 https://news.ycombinator.com/item?id=19280634 >This is just pedantry. >I this read you other replies and I can't see them adding much value to the discussion. >You are just being rigid about semantics. >What action are we supposed to take having read your comments? >To be careful of not calling a pipeline with awk in it 'shell?' >To be ashamed of using awk because it's a programming language, and that is 'cheating'? I noticed that you did not reply to gerbilly, just as you did not reply to at least one of my challenges of your earlier claims., and you raised some other points, instead. Seems like moving goalposts, to me. And I think he/she is right, both in general, based on all your comments so far, that were in reply to my top-level comment, and also because of this last bit above from you, in your comment that I am replying to: >So it's shell. I might, however, given my background, and remembering as I do its first introduction, always have trouble thinking of it as such. So this is like you are saying that you acknowledge it is shell, even mentioned in the POSIX standard, but still have trouble internalizing that. Who cares about what you have trouble remembering or thinking of it as, versus what the facts on the ground are? (You said that redundantly in a couple of places, too, in this thread). It only seems to confirm the rigidity that gerbilly surmised. [1] There is still a fundamental flaw in one of your comments, about my shell solution, that I noticed. Pointing that out will have to wait until tomorrow, since I said earlier that I may be busy, and am.