4 ms·

This is a very silly way of writing it though. grep|sed can almost always be replaced with a simple awk: awk '/^x/ { sub("a", "b"); print $2; }' foo.txt. This w

This is a very silly way of writing it though. grep|sed can almost always be replaced with a simple awk: awk '/^x/ { sub("a", "b"); print $2; }' foo.txt. This way, the whole command fits on one line. If it doesn't, put your awk script in a separate file and simply call it with "awk -f myawkscript foo.txt".

yesenadam 8y ago
>sub("a", "b"); That should be gsub, shouldn't it? (sub only replaces the first occurrence)
- Hello71 8y ago
  Yes.
geofft 8y ago
I use awk in exactly this way personally, but, awk is not as commonly readable as grep and sed (in fact, that use of grep and sed should be pretty comprehensible to someone who just knows regular expressions from some programming languages and very briefly glances at the manpages, whereas it would be difficult to learn what that awk syntax means just from e.g. the GNU awk manpage). So, just as you could write a Perl one-liner but you shouldn't if you want other people to read the code, I'd probably advise against the awk one-liner too.
- yesenadam 8y ago
  Not sure why you say grep and sed are more readable than awk! (not sure what 'commonly readable' means). Or that even that particular line in awk is harder to understand than the grep and sed man pages. The awk manpage even has examples, including print $2. The sed manpages must be the most impenetrable manpages known to 'man', if you don't already understand sed. (People might already know s///g because 99% of the time, that's all sed is used for.)
ncallaway 8y ago
I would disagree that their way of writing it is silly. It is instantly plainly obvious to me what each step of their shell script is doing. While I can absolutely understand what your shell script does after parsing it, it's meaning doesn't leap out at me in the same way. I would describe the prior shell script as more quickly readable than the one that you've listed. So, perhaps it's not a question of one being more silly than the other—perhaps the author just has different priorities from you?
- anthk 8y ago
  That's bullshit. On million files, spawning subproceses could add a several lag per pipe. This way, awk runs straightly. AWK is base knowledge on Unix. Shell scripts, specially the bloated bash, not. Readable? Priorities? I've done quicker jobs with awk and windows binary logs with strings(1) with the more than, literally, 100+ lines from newbies. If people learn more about its tools instead of adding bloat unnedeedly because of ignorance OLD and ULTRADOCUMMENTED UNIX tools, - -cough, GNU folks and GNU/Linux distros- most of the crappified scripts and (fake) "usability" switches woudn't even exist. Such as column, tr, "objdum -x $FILE | grep NEEDED" instead of ldd, tput for nice dialog like interfaces in shell, join, fmt, and so on. Also, makefiles/m4. They cut down times exponentially.
zorga 8y ago
And you've utterly missed the point. His version is better than your suggestion, it's cleaner and more readable and built from simpler parts. Banging grep and sed together is far more common than digging into awk.

yesenadam 8y ago

>sub("a", "b"); That should be gsub, shouldn't it? (sub only replaces the first occurrence)

Hello71 8y ago
Yes.

geofft 8y ago

I use awk in exactly this way personally, but, awk is not as commonly readable as grep and sed (in fact, that use of grep and sed should be pretty comprehensible to someone who just knows regular expressions from some programming languages and very briefly glances at the manpages, whereas it would be difficult to learn what that awk syntax means just from e.g. the GNU awk manpage). So, just as you could write a Perl one-liner but you shouldn't if you want other people to read the code, I'd probably advise against the awk one-liner too.

yesenadam 8y ago
Not sure why you say grep and sed are more readable than awk! (not sure what 'commonly readable' means). Or that even that particular line in awk is harder to understand than the grep and sed man pages. The awk manpage even has examples, including print $2. The sed manpages must be the most impenetrable manpages known to 'man', if you don't already understand sed. (People might already know s///g because 99% of the time, that's all sed is used for.)

ncallaway 8y ago

I would disagree that their way of writing it is silly. It is instantly plainly obvious to me what each step of their shell script is doing. While I can absolutely understand what your shell script does after parsing it, it's meaning doesn't leap out at me in the same way. I would describe the prior shell script as more quickly readable than the one that you've listed. So, perhaps it's not a question of one being more silly than the other—perhaps the author just has different priorities from you?

anthk 8y ago
That's bullshit. On million files, spawning subproceses could add a several lag per pipe. This way, awk runs straightly. AWK is base knowledge on Unix. Shell scripts, specially the bloated bash, not. Readable? Priorities? I've done quicker jobs with awk and windows binary logs with strings(1) with the more than, literally, 100+ lines from newbies. If people learn more about its tools instead of adding bloat unnedeedly because of ignorance OLD and ULTRADOCUMMENTED UNIX tools, - -cough, GNU folks and GNU/Linux distros- most of the crappified scripts and (fake) "usability" switches woudn't even exist. Such as column, tr, "objdum -x $FILE | grep NEEDED" instead of ldd, tput for nice dialog like interfaces in shell, join, fmt, and so on. Also, makefiles/m4. They cut down times exponentially.

zorga 8y ago

And you've utterly missed the point. His version is better than your suggestion, it's cleaner and more readable and built from simpler parts. Banging grep and sed together is far more common than digging into awk.