2

I saw someone do this to replace "upon" with "eat" in a text file called oro. 

sed -i -e "s|upon|eat|" oro

Question: what is the purpose of -e option in the above command? I tried with and without the -e option and observed no differences.

Tosh
  • 709
  • 1
    @yaegashi - if it is a duplicate, I don't think it should matter - there aren't any answers at that link which answer the question. There are a few which talk about ways to handle it - but not a one which discusses its purpose - especially in the context of -i. Ok, there was one - a good one - short and sweet - but not regarding -i, – mikeserv Jun 03 '15 at 04:39
  • @mikeserv This answer explains it pretty well: you can't have sed '/foo/i\bar; /fred/a\barny; /harry/c\potter', since i, a, and c have to be terminated by newlines. Using -e allows you to pass i, a, and c on the command line. -i is completely irrelevant to this issue. – lcd047 Jun 03 '15 at 06:18
  • @lcd047 - you're wrong about -i - and none of those have to be terminated by newlines either. -e does not allow you terminate it with a newline - a newline does that. – mikeserv Jun 03 '15 at 06:21
  • @mikeserv Please try this: echo foo | sed -e '/foo/a\' -e 'bar' – lcd047 Jun 03 '15 at 06:26
  • @lcd047 - i know how it works - but it doesn't work with newlines, and they don't need terminating newlines, either. At least, not in this case. There are two ways to terminate those commands portably - one you've just demonstrated, and the other is a newline. Except that's not the only way to do it the way you have just done. – mikeserv Jun 03 '15 at 06:31
  • @lcd047 - maybe look here. – mikeserv Jun 03 '15 at 06:33
  • @mikeserv My point was to show you why -e is needed. echo foo | sed '/foo/a\bar' doesn't work, while echo foo | sed -e '/foo/a\' -e bar does (with no -i in sight, either). I wasn't trying to find all (or any) ways to make a\ work, portable or not. – lcd047 Jun 03 '15 at 06:35
  • @lcd047 - But you didn't. You did as those answers do and talked about where it's needed. I know where it's needed - and i also know why. I don't believe you do - and those answers don't discuss it either. It's not a big deal - but you're not helping your case by confirming my complaint. And, yes, i know there was no -i in sight, but there is one the question here, and it is not unrelated. – mikeserv Jun 03 '15 at 06:39
  • @mikeserv I don't believe you do - Am I allowed to call you names in response, then? :) And, yes, i know there was no -i in sight, but there is one the question here, and it is not unrelated. - Then please show how it's related. So far you (1) have rejected my explanation without giving any reason, and (2) started a pissing contest. Surely you can do better than that? – lcd047 Jun 03 '15 at 06:48
  • @lcd047 - I didn't call you any names - I certainly don't discriminate against people based on their understanding of edgecase sed parsing rules. And anyway, just that you know where it's needed is far more than most, so if I did - and if ever it was in any danger of affecting my opinion of you - it would have positively done so. But it didn't - and never would have. Yes, I don't believe you do - I'm sorry if that offends you. But I am done talking with you about it. If you wish to have some answers from my perspective - you can follow the link. Or not. I don't care. – mikeserv Jun 03 '15 at 06:54
  • 1
    @mikeserv Ok, so to answer your question why: -e compiles its arguments as a string (compile_string() in GNU sed sources), while -f and '...' compile their argument as a program (compile_file() in GNU sed). This means -e terminates commands, which is why sed -e '/foo/a\' -e bar works, and sed '/foo/a\' -e bar doesn't. In the original question -e doesn't make any difference because s doesn't care whether something follows or not. Have a good day, too. – lcd047 Jun 03 '15 at 07:01
  • @lcd047 - Yeah, that is, in a roundabout way, why. The -e command is a script - as is -f - they can be intermingled. Anyway, GNU writes its sources according to a standard - which is far clearer on the matter. The terminator in both cases is a null read - the end of the script, EOF. It's not a newline, but that is a pedantic argument to make on my part anyway. Still, the answers linked don't come anywhere close to discussing that. By spec: The application shall not present a script that violates the restrictions of a text file except that the final character need not be a newline. – mikeserv Jun 03 '15 at 07:07

0 Answers0