4 ms·

There are a ton of little errors in this post (at the time of my leaving this comment, of course): the variable delimiter example is missing the close _, the fi

by saurik 5y ago

There are a ton of little errors in this post (at the time of my leaving this comment, of course): the variable delimiter example is missing the close _, the first word example is missing the open ', and the except line 5 example is missing a space; meanwhile, these snippets will cause bad habits, such as thinking about "words" as "things involving letters", using -r instead of -E, and a massive knowledge gap with respect to appropriate use of semicolons... I'm also really confused as to why sed is suddenly "s" in one of the examples. This just isn't a very good reference, and I'm not sure if the author thinks about how "c" works, but it really needs a \ afterwards, no matter what the one specific version of sed you are using might allow :/. As someone who loves sed so much he nigh unto regrets how much he uses it: "beware". FWIW, I'd argue that the path to true sed mastery eventually goes through the hold space, which isn't mentioned here. For some real fun, and an exercise that might change how you mentally model what sed is capable of, check out SedSokoban. https://aurelio.net/projects/sedsokoban/ https://aurelio.net/projects/sedsokoban/

imiric 5y ago
While this might not be the ultimate sed reference, it turned me onto some patterns I haven't used before. The examples aren't meant to be used directly and will involve some trial and error before they're useful, but knowing what's possible makes it a very valuable reference.
adrianscheff 5y ago
Thank you for the feedback and the constructive criticism. Regarding the hold space I found it very confusing to use and understand. IMO it represents the 80/20 of sed (80% effort for 20% results). You're right, I'm using -r even when it's not necessary. To my defense I think it's a good habit to have since without it regex expressions are painful to write. I didn't considered that using -E it's a better choice but I'll correct that now. (one might argue again that typing -r is easier than -E :D ). Regarding the definition of words - I also thought of that when I wrote that snippet. I know it's not the complete regex for a word and that word regex patterns might differ. And I was probably a bit lazy - but I'll correct it presently. I'd also like to say that I didn't write this as an absolute and ultimate reference. If I'm honest I wrote this as much to teach others as to solidify this knowledge myself. Now since it seems it gained traction I'm kinda obligated to make this better, no? Darn. :) PS: if you'd like to help me make this better please submit a pull request or leave a comment here. Looking at your profile I see that you try to limit your online time so I probably shouldn've asked. :P
- dolmen 5y ago
  No mention of ';' to have multiple command on one line. Example: sed '10{p;q;}' myfile.txt
  - adrianscheff 5y ago
    Thank you for your feedback! Personally I very rarely use the ; operator since it works badly with braces and commands that use files. However I've added an example using the ; operator. PS: May I humbly point out that the command you provided will actually print up to line 10 and then a duplicate line. Like I said, unexpected (even though it seems logical). :)
    - dolmen 5y ago
      Yes: forgot -n
- dolmen 5y ago
  Most examples that use '#!/bin/bash' should be rewritten to use '#!/usr/bin/sed -f'. Example "multiple replacements": #!/usr/bin/sed -f s/a/A/ s/foo/BAR/ s/hello/HELLO/ Save it as replace.sed; chmod u+rx replace.sed; ./replace.sed myfile.txt
  - adrianscheff 5y ago
    Thanks, I've modified to use .sed scripts instead. I used bash scripts because I remembered (incorrectly it seems) that sed scripts were unsafe.
- chasil 5y ago
  CentOS 7's sed doesn't support -E, but CentOS 8 does. That might cause some confusion. Also, FYI, this is the link for the POSIX specification for sed: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s... Notice that -i is not POSIX.
dolmen 5y ago
Direct link to sokoban.sed: https://github.com/aureliojargas/sokoban.sed/blob/master/sokoban.sed https://github.com/aureliojargas/sokoban.sed/blob/master/sok...
dolmen 5y ago
100% agree. This document shows practices of sed, but the author doesn't seem aware of best practices. A sed script starting with '#!/bin/bash' is a bad practice.
- adrianscheff 5y ago
  Ha, you got me there. I remembered incorrectly that sed scripts where bad practice and one should use bash instead. I've corrected the mistake. What other good practice suggestions do you have? (if you're comfortable answering and have the time)

by saurik 5y ago

imiric 5y ago

While this might not be the ultimate sed reference, it turned me onto some patterns I haven't used before. The examples aren't meant to be used directly and will involve some trial and error before they're useful, but knowing what's possible makes it a very valuable reference.

adrianscheff 5y ago

Thank you for the feedback and the constructive criticism. Regarding the hold space I found it very confusing to use and understand. IMO it represents the 80/20 of sed (80% effort for 20% results). You're right, I'm using -r even when it's not necessary. To my defense I think it's a good habit to have since without it regex expressions are painful to write. I didn't considered that using -E it's a better choice but I'll correct that now. (one might argue again that typing -r is easier than -E :D ). Regarding the definition of words - I also thought of that when I wrote that snippet. I know it's not the complete regex for a word and that word regex patterns might differ. And I was probably a bit lazy - but I'll correct it presently. I'd also like to say that I didn't write this as an absolute and ultimate reference. If I'm honest I wrote this as much to teach others as to solidify this knowledge myself. Now since it seems it gained traction I'm kinda obligated to make this better, no? Darn. :) PS: if you'd like to help me make this better please submit a pull request or leave a comment here. Looking at your profile I see that you try to limit your online time so I probably shouldn've asked. :P

dolmen 5y ago
No mention of ';' to have multiple command on one line. Example: sed '10{p;q;}' myfile.txt
- adrianscheff 5y ago
  Thank you for your feedback! Personally I very rarely use the ; operator since it works badly with braces and commands that use files. However I've added an example using the ; operator. PS: May I humbly point out that the command you provided will actually print up to line 10 and then a duplicate line. Like I said, unexpected (even though it seems logical). :)
  - dolmen 5y ago
    Yes: forgot -n
dolmen 5y ago
Most examples that use '#!/bin/bash' should be rewritten to use '#!/usr/bin/sed -f'. Example "multiple replacements": #!/usr/bin/sed -f s/a/A/ s/foo/BAR/ s/hello/HELLO/ Save it as replace.sed; chmod u+rx replace.sed; ./replace.sed myfile.txt
- adrianscheff 5y ago
  Thanks, I've modified to use .sed scripts instead. I used bash scripts because I remembered (incorrectly it seems) that sed scripts were unsafe.
chasil 5y ago
CentOS 7's sed doesn't support -E, but CentOS 8 does. That might cause some confusion. Also, FYI, this is the link for the POSIX specification for sed: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s... Notice that -i is not POSIX.

dolmen 5y ago

Direct link to sokoban.sed: https://github.com/aureliojargas/sokoban.sed/blob/master/sokoban.sed https://github.com/aureliojargas/sokoban.sed/blob/master/sok...

dolmen 5y ago

100% agree. This document shows practices of sed, but the author doesn't seem aware of best practices. A sed script starting with '#!/bin/bash' is a bad practice.

adrianscheff 5y ago
Ha, you got me there. I remembered incorrectly that sed scripts where bad practice and one should use bash instead. I've corrected the mistake. What other good practice suggestions do you have? (if you're comfortable answering and have the time)