0

On MKS SED for Windows, this

TYPE Q:\temp\curtainssetspread.M3U | SED -E "/z/{s_a_b_}"

fails with

sed: garbage after command

Why?

This usage accords correctly with docs:

a,b{    groups all commands until the next matching }, so that sed executes the entire group only if the { command is selected by its address(es).
ChrisJJ
  • 2,191
  • 1
  • 25
  • 38
  • 1
    I'm not sure about peculiarities of MKS sed, but `s_a_b` is just a single command and POSIX sed would accept `/z/s_a_b_` without curly braces. Try inserting `;` before the closing brace, that fixes some problems in BSD sed. – Benjamin W. Aug 21 '17 at 01:53
  • Also, any reason why you're using underscores instead of slashes? – Benjamin W. Aug 21 '17 at 03:03
  • @Benjamin To reduce escaping. Underscore less frequently appears inside the delimited string than slash. And I find underscore leaves the delimitation more visible. – ChrisJJ Aug 21 '17 at 07:31
  • @Benjamin, inserting ; before the closing brace does fix it. Because using ; as a command separator is undocumented for MKS SED https://www.mkssoftware.com/docs/man1/sed.1.asp I think HTNW's is the strictly better workaround. But your implied "Because ; is missing" is the best answer, so please post it as an answer for me to tick. – ChrisJJ Aug 21 '17 at 07:36
  • @SLePort, that doesn't necessitate change of delimiter from slash. Only Slash inside the regexp or replacement would. – ChrisJJ Aug 21 '17 at 11:02

1 Answers1

1

According to POSIX, the } must be preceded by a newline. I'm not sure what MKS does, but the beauty of having a standard is that the following should work on all systems (using multiple -es joins each string together with newlines in between):

sed -e "/z/{s_a_b_" -e "}"

If it doesn't work, it's a bug in MKS and should be reported, as they say their sed is POSIX-compliant.

I do suggest following Benjamin's advice and just doing

sed -e '/z/s_a_b_'

if possible, though.

HTNW
  • 27,182
  • 1
  • 32
  • 60
  • No one saw that >_ – HTNW Aug 21 '17 at 03:09
  • It does work on MKS SED, despite that ' (using multiple -es joins each string together with newlines in between)' is undocumented behaviour https://www.mkssoftware.com/docs/man1/sed.1.asp . Thanks. – ChrisJJ Aug 21 '17 at 07:45
  • "they say their sed is POSIX-compliant". They imply it, but I'd like to see where they actually state it. – ChrisJJ Aug 21 '17 at 07:45
  • At the very end of [the man page](https://www.mkssoftware.com/docs/man1/sed.1.asp), in the "Portability" section, they say they support POSIX. – HTNW Aug 21 '17 at 13:06
  • The verb 'support' is conspicuously absent :) http://www.mkssoftware.com/support/kb/faqs.asp?product=Toolkit#art19 is inconclusive. Given the stated objectives, I can't see they'd want SED to be POSIX compatible for good reason, but they're not saying it is, and I wonder if that too is for good reason. I.e. it isn't. – ChrisJJ Aug 21 '17 at 17:50
  • Does it matter? There's no reason for an attempt at Windows interop to somehow break POSIX sed's `-e`. Very few systems that call themselves POSIX-compliant actually are, in all respects, but those are controlled deviations, usually. Anyway, there's no phrase saying "`-e` won't append its argument to the script with a newline," explicitly, but they *do* state POSIX-compliance, so they state that `-e` works this way by proxy. – HTNW Aug 21 '17 at 17:54
  • "Does it matter?" Yes compatibility matters. "they do state POSIX-compliance" Nowhere that I can see. – ChrisJJ Aug 21 '17 at 22:15
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/152473/discussion-between-htnw-and-chrisjj). – HTNW Aug 21 '17 at 22:36