Am I in the minority of developers then? I don't know awk and sed and I'm honestly not very interested in learning them. But bash I definitely agree with. I still use a cheatsheet to get the syntax right because it's weird as hell imo.
Am I in the minority of developers then? I don't know awk and sed and I'm honestly not very interested in learning them. But bash I definitely agree with. I still use a cheatsheet to get the syntax right because it's weird as hell imo.
Let's say you're on my team, and I've decided I'm a real stickler for code formatting. But I've got peculiar tastes, and one day I decide I want to have all parentheses stand out very clearly in your code.
So let's say you've got a set of source files in C, C++, or Java. Your choice. And I want you to modify them so that in each source file, every open- and close-paren has exactly one space character before and after
I like sed. I like perl one-liners. I would consider it a mistake to try to do this on a real codebase in a batch manner with just a regexp. You'd be far better off googling to find a source code formatter that includes a real parser, like clang-format.
The point of the question is more to gauge your understanding of/familiarity with available tools and ability to think laterally rather than immediately jump to "I've got to write some real code to solve this"
As an aside, the stuff I used sed/awk for in the past have pretty much been replaced by Python for me. These days it's pretty rare to not have a default Python install on any Unixy box one spins up and in the rare cases I use Windows I tend to install Anaconda so it's also slightly more cross-platform for my use cases.
curl https://raw.githubusercontent.com/kedarmhaswade/cities/master/area-codes.csv | \
awk -F, '{print $1}' \
> ~/area_codes.txt
Now, could you use grep? Yeah, sure. But for really quick examples like this - things that lend themselves to it (e.g. a raw CSV with mostly crap you don't need but something you do), this is super fast. Anything more complicated and I'd break out a regex, though.Awk/Sed are optimised for text/data processing.[0] While Bash might work, will the script work on all systems (and version)? [1] awk & predecessor sed are good for one liner programs and suitable for problems that need fast, reliable solutions.
reference
[0] Opening, closing files; reading, breaking and counting record fields.
[1] OS use Bash or Bourne? https://en.wikipedia.org/wiki/Bash_(Unix_shell)#Portability
On Linux, I can use this sed command: sed -i ‘s/^”//’ example.txt
That deletes any quotation marks that are at the beginning of a line. It does it in-place, and while you have the option to rename the old file and replace it with a new file with the original name (using "sed -i.bak ‘s/^”//’ example.txt" would move the existing example.txt file to example.txt.bak and write a new one in-place), if you leave out the .bak, it just writes it in-place with no backup file.
On OS X, though, that command won't work. You have to specify a backup file, even if it's blank. "sed -i “” ‘s/^”//’ example.txt" would replace the text in-place without a backup. sed -i “.bak” ‘s/^”//’ example.txt would replace the file and move the original to "example.txt.bak".
Even with sed and awk, you still have to stop and wonder if it will work cross-platform.
If you used an operating system that shipped with BusyBox, you'd be similarly frustrated. But operating systems are tradeoffs with pros/cons. Using a different set of tools makes it distinct, not "out of date".
1. https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-c...
True, but I was thinking awk/sed was a good multi OS tool with minimal code effect.
Well that kills my idea why to use awk/sed. What would you use @freehunter?
Given that description, I'd agree. Now I understand the crux of the problem, problem solved using disposable code in terse language or script.
Awk is also POSIX standard; a good remaining reason to use it (if it is a feasible alternative for a task) is that a script has to be portable outside of GNU/Linux.
So I'm surprised at the following part of your comment:
> There is no reason to use perl in situation when awk kicks its butt with clearer, shorter code free of distracting author and other line noise
In my experience, the shorter ask code tends to be the one with sigils.