5

Recently I learned sed for a while and it was awkward experience due to

  • need of remembering single-letter commands (p, a, d, ...)
  • concept of single hold space for remembering the context – controlled by other similar commands (h, x, g, ...)

I said to myself: couldn't this be made more intuitive? I.e. with more verbose commands (e.g. print instead of p) and more than one buffer – standard variables according to my need (e.g. lastUserSeen)?

And then someone told me:

No, never use h or any other sed constructs except s, g, and p (with -n) or you are literally using constructs that became obsolete in the mid-1970s when awk was invented. People use those other constructs today strictly for the mental exercise, not to seriously write software, since an equivalent awk solution will be clearer, more efficient, more portable, easier to maintain/enhance, and better in every other meaningful way.

awk? I immediately jumped on and fell in love with it. Many of my multi-line programs worked on first run, without any debugging. From what I since then studied about the awk, I think it is able to completely supersede the sed. Or is there some sed feature (which I missed) effect of which cannot be easily achieved by the awk? Is there any reason why an awk user would run sed?

Edit: this is not a question "which is better", but a comparison of feature sets. Is there a feature in sed effect of which cannot be achieved similarly efficiently in awk, but it would need much more awk code?

closed as primarily opinion-based by Michael Homer, Archemar, don_crissti, Thomas Dickey, user34720 Jun 23 '17 at 10:33

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    This is like useless discussion about one programming language over another, one editor over another, one distribution over another and so on. sed has pros and cons like awk, perl or python have. If you know to handle different tools, you can choose the best for a specific problem. The simple concept of sed and single char commands can be view as advantage for quick, compact scripts. You see it as disadvantage. So this is mainly opinion based. – Philippos Jun 23 '17 at 8:43
  • Similar: When to use grep, less, awk, sed – Stéphane Chazelas Jun 23 '17 at 9:03
  • @Philippos – I think you misunderstood the question. Please see the edit. Someone can still view discontinued Symbian OS way better than today's Android, and I will not go into these religious wars. I am interested in comparison of features because there could be some obvious non-equivalencies. The answers can point to them from programmers' viewpoint, which is technically more exact. sed -i is a good example, because it cannot be equivalently efficiently implemented in awk without in-place editing extension. – miroxlav Jun 23 '17 at 9:11
  • 1
    I've learned a lot of awk from Ed but his comment over there is waaaay off... Any seasoned sed user will tell you that statement is BS. sed is just as portable as awk and just as easy to maintain if the maintainer is equally proficient with both of them. And never use h,x,d etc ? Such comments are usually made by people who cannot fully understand how sed operates on a stream of data. Try doing something like sed '$d' or sed 'x;$!d' with awk, see if you can make it "more efficient" or golf it shorter. Each has its pros and cons so yes, this is primarily opinion based. – don_crissti Jun 23 '17 at 10:35
  • 1
    Yes, because then Ed Morton will come up with an awk one liner example which is the equivalent of 11 sed commands ;) ... lol, come on man, can't you see it all depends on the input, the task at hand and the human operator ? Read, learn, practice, get better and you will know when to use one and when to use the other. – don_crissti Jun 23 '17 at 11:09
2

For a quick and easy way to edit a file in place, sed -i feature is a whole lot easier than constructing something similar using awk. I accept that platforms using gawk at version 1.4.0 or later do have the "inplace" feature to cover this.

sed -i 's/foo/bar/' filename

Reluctantly learned sed myself due to all the existing scripts using it. Given a choice, when writing a new script, awk usually wins, the code is so much more readable + maintainable.

  • 2
    sed -i is a GNU sed extension. GNU awk has a similar extension (awk -i inplace). – Stéphane Chazelas Jun 23 '17 at 9:11
  • 1
    Interesting find. So the -i will save me sequence of two additional commands, correct? I mean that without -i I have to (0) put processing result into temp file instead of original file (1) delete original file (2) rename temp file to original file. – miroxlav Jun 23 '17 at 9:43
  • Indeed. Bang on ! – steve Jun 23 '17 at 9:45
1

Most of the time, sed is used for basic editing (s///g).
Most of the time awk is used for more complex text editing.

The basic reason to use sed instead of awk, in the cases where sed and awk both provide useful (simple) answers, is that sed is ~100k and GNU awk is ~600k.

Smaller loads faster (sometimes that is important).

Older awks tend to be smaller, mawk is ~121k (we should find an old sed to make a reasonable comparison).

And there is Perl, a very powerful language, very fast in some uses, but quite big to load ~2Megabytes. Repeated use of Perl could add up to long delays.

The sed FAQ chapter 6 gives well written and quite balanced recommendations on when to use or avoid using sed, compared to awk and perl.

  • Is there any real impact of loading times of 100 KB vs 600 KB file in processing? Even if the tool was launched 50 times per second in some batch processing, the file will be provided from disk cache, dropping loading time differences almost to zero. Or not? – miroxlav Jun 23 '17 at 9:32
  • @miroxlav Loading (and processing all the start variables, files, etc) many many times will clearly add up to some measurable delay. That was one reason to use dash (a quite small shell) over bash as system shell. Personal preferences aside, it was clear that the change sped up the system loading time (many many shell calls). – Arrow Jun 23 '17 at 9:38
  • Thank you for that sed FAQ reference. It is good to have some questions answered directly from authors. – miroxlav Jun 23 '17 at 9:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.