3

Seems like this should just remove at most 2 spaces from the start of each line: cat test.txt | 9 sed 's/^ //g; instead it replaces all spaces from the start of the line. GNU's sed seems to be have as I'd expect here, for comparison, but I'm interested in learning the Plan 9 way.

Note: the 9 sed syntax here is because I'm running it from plan9port.

In more detail:

$ cat test.txt
This
  is
    a test.
Bye
$ cat test.txt | 9 sed 's/^  //g'
This
is
a test.
Bye

I would expect that the output would be more like using GNU sed:

$ cat test.txt | sed 's/^  //g'
This
is
  a test.
Bye
bbarker
  • 11,636
  • 9
  • 38
  • 62
  • Please add sample input and your desired output for that sample input to your question. – Cyrus Sep 23 '18 at 20:09
  • @Cyrus, right you are - updated – bbarker Sep 23 '18 at 20:22
  • 1
    Every sed behaves the way you expect, not just GNU sed. idk what that `9` is doing but maybe it's introducing a loop where it keeps calling sed until it fails? What happens when you remove the UUOC and the redundant `g` and do `9 sed 's/^ //' test.txt` (assuming that `9` is necessary for some reason)? – Ed Morton Sep 23 '18 at 20:37
  • @EdMorton `9` calls plan9port `sed` when it isn't on the `PATH`. But, if I specify the absolute path to `sed` it works, but only if I leave off the redundant `g` (I didn't realize it was redundant). Odd, I thought I tried this variation earlier (obviously not though). – bbarker Sep 23 '18 at 21:02
  • After reading more about `\g` I can see why it might be an issue; not sure why GNU's behaves differently here. – bbarker Sep 23 '18 at 21:06
  • The `g` SHOULD have no effect. GNU sed is doing what every sed should do. `g` means replace the regexp across the whole line `^` matches 2 blanks at the start of the line. Full stop, end of story. `g` specifically does NOT mean `keep matching that regexp until it no longer matches` which is what your code seems to be doing. Something is apparently broken. If you'd like help to figure out what - Does your original code behave as desired without the `g`, i.e. does `cat test.txt | 9 sed 's/^ //' test.txt` work? What about `9 sed 's/^ //g' test.txt`? – Ed Morton Sep 23 '18 at 21:08
  • As a perhaps more minimal example of what does not work, avoiding use of `9`, ``` /path/to/plan9port/bin/sed 's/^ //g' test.txt``` still removes all whitespace on every line before a word. – bbarker Sep 23 '18 at 21:11
  • OK, then it's that version of sed that's broken. Whoever implemented it apparently misunderstood what `g` meant. Given that, you should avoid using it as who knows what else might be broken. – Ed Morton Sep 23 '18 at 21:13

1 Answers1

1

Looks like plan 9s sed is broken as it's treating

sed 's/^  //g'

as if it was (pseudo-code):

do
    sed 's/^  //'
until the sed output is no longer different from the input

or:

sed 's/^  *//'

or similar instead of the correct interpretation which is the same as if the g wasn't present:

sed 's/^  //'
Ed Morton
  • 188,023
  • 17
  • 78
  • 185
  • Just for a bit more clarification, the Open Group doc says of **g**: "Globally substitute for all non-overlapping instances of the BRE rather than just the first one". So, in that case, would the plan9 interpretation be correct? Ref: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html – bbarker Sep 23 '18 at 21:30
  • 1
    No because the BRE you used starts with the start-of-string anchor, `^`, which, since sed by default reads one line at a time, in this case means `start of line` and the start of the line obviously doesn't occur anywhere else in the line other than the start of it so there is just 1 single match for that BRE and it's the 2 blanks at the start of the line. – Ed Morton Sep 23 '18 at 21:38
  • 1
    Of course ... thanks; filed a bug report at: https://github.com/9fans/plan9port/issues/183 – bbarker Sep 23 '18 at 21:51