4 ms·

way to completely miss the point and turn this into a weird pissing competition (btw your "simple" awk example is super complicated and opaque to someone who do

way to completely miss the point and turn this into a weird pissing competition (btw your "simple" awk example is super complicated and opaque to someone who doesn't have the awk man page open in front of them) The script package looks really cool and I'll definitely try it out, cause honestly even though I do a lot of bash scripting it's super painful for anything but something super simple.

sgarland 3y ago
If someone doesn't know awk, then of course it'll be complicated and opaque - the same is true of practically any language. One-liners in general also tend to optimize for space. If you wanted it to be pretty-printed and with variable names that are more obvious: { PROCINFO["sorted_in"] = "@val_num_desc" top_ips[$1]++ } END { counter = 0 for (i in top_ips) { if (counter++ < 10) { print top_ips[i], i } } } But also, if you read further up in the thread, you'll see that another user correctly identified the bottlenecks in the original pipeline, and applying those optimizations made it about 3x as fast as the awk one. Arguably, if you weren't familiar with the tools (and their specific implementations, like how GNU sort and BSD sort have wildly different default buffer sizes), you'd still be facing the same problem. At least half of what people complain about with shell scripts can be solved by using ShellCheck [0], and understanding what it's asking you to do. I disagree with the common opinion of "anything beyond a few lines should be a Python script instead." If you're careful with variable scoping and error handling, bash is perfectly functional for many uses. [0]: https://www.shellcheck.net https://www.shellcheck.net
- dharmab 3y ago
  > If someone doesn't know awk, then of course it'll be complicated and opaque - the same is true of practically any language I don't think this is true. Before I learned Go, I could follow along most Go programs pretty well, and learning Go well enough to get started took less than an hour. Every attempt I've made to learn more Awk, I've bounced off.
  - deleted 3y ago
    [deleted]
  - jppittma 3y ago
    Really? I learned awk by watching a one hour youtube video one afternoon. It being a DSL really makes it super easy to learn, and this, to me suggests you probably haven't given it much time.
    - fsociety 3y ago
      Good for you, their point still holds up. Languages like Python and Go are more readable than awk and bash. They are designed to be that way, and many many years of effort have been put into them for that specific purpose. Whereas if you know awk and bash, then they can be incredibly useful in a pinch. It doesn’t knock how powerful they are. I think it is worth learning. But if something needs to be maintained then there is an argument for Python/Go/whatever.
- subjectsigma 3y ago
  > If you're careful with variable scoping and error handling, bash is perfectly functional for many uses. “Loaded guns are perfectly functional for juggling, just be careful with the trigger and you won’t shoot yourself in the foot!” You are technically correct but why bother with being careful when you could just avoid writing bash?
  - sgarland 3y ago
    Because it's really fast to iterate on if you know it, it's available basically everywhere and has no external dependencies, and you don't have to compile it.

sgarland 3y ago

If someone doesn't know awk, then of course it'll be complicated and opaque - the same is true of practically any language. One-liners in general also tend to optimize for space. If you wanted it to be pretty-printed and with variable names that are more obvious: { PROCINFO["sorted_in"] = "@val_num_desc" top_ips[$1]++ } END { counter = 0 for (i in top_ips) { if (counter++ < 10) { print top_ips[i], i } } } But also, if you read further up in the thread, you'll see that another user correctly identified the bottlenecks in the original pipeline, and applying those optimizations made it about 3x as fast as the awk one. Arguably, if you weren't familiar with the tools (and their specific implementations, like how GNU sort and BSD sort have wildly different default buffer sizes), you'd still be facing the same problem. At least half of what people complain about with shell scripts can be solved by using ShellCheck [0], and understanding what it's asking you to do. I disagree with the common opinion of "anything beyond a few lines should be a Python script instead." If you're careful with variable scoping and error handling, bash is perfectly functional for many uses. [0]: https://www.shellcheck.net https://www.shellcheck.net

dharmab 3y ago
> If someone doesn't know awk, then of course it'll be complicated and opaque - the same is true of practically any language I don't think this is true. Before I learned Go, I could follow along most Go programs pretty well, and learning Go well enough to get started took less than an hour. Every attempt I've made to learn more Awk, I've bounced off.
- deleted 3y ago
  [deleted]
- jppittma 3y ago
  Really? I learned awk by watching a one hour youtube video one afternoon. It being a DSL really makes it super easy to learn, and this, to me suggests you probably haven't given it much time.
  - fsociety 3y ago
    Good for you, their point still holds up. Languages like Python and Go are more readable than awk and bash. They are designed to be that way, and many many years of effort have been put into them for that specific purpose. Whereas if you know awk and bash, then they can be incredibly useful in a pinch. It doesn’t knock how powerful they are. I think it is worth learning. But if something needs to be maintained then there is an argument for Python/Go/whatever.
subjectsigma 3y ago
> If you're careful with variable scoping and error handling, bash is perfectly functional for many uses. “Loaded guns are perfectly functional for juggling, just be careful with the trigger and you won’t shoot yourself in the foot!” You are technically correct but why bother with being careful when you could just avoid writing bash?
- sgarland 3y ago
  Because it's really fast to iterate on if you know it, it's available basically everywhere and has no external dependencies, and you don't have to compile it.