5 ms·

On a related note, I found Bruce Barnett's sed tutorial is one of the best Sed guide out there: http://www.grymoire.com/Unix/Sed.html http://www.grymoire.com/Un

by devy 8y ago

On a related note, I found Bruce Barnett's sed tutorial is one of the best Sed guide out there: http://www.grymoire.com/Unix/Sed.html http://www.grymoire.com/Unix/Sed.html

mdaniel 8y ago
It was really good, thank you! I learned a ton of new tricks from it Separately, I feel like I could have a full time job submitting PRs to fix the GNU-ism of using `sed -i"" ...` versus the BSD/macOS syntax of `sed -i "" ...`. I don't know which of those two camps broke from the other, but holy hell it _broke_ for sure.
- thisacctforreal 8y ago
  How does the GNU-ism work at a shell level? In your first example $0 is "sed", $1 is "-i", $2 is "...", no? What signifigance does the -i"" have in bash apart from 'concat -i to ""'? The BSD syntax is plain, $1 is the option "-i", $2 is the value for that option: "", $3 is "...". Edit: off by one
  - mdaniel 8y ago
    I don't believe it's a bash-ism, I would guess it's GNU getopt defining the `-i` as only optionally requiring an argument, versus the built-in getopt that BSD is using: https://git.savannah.gnu.org/cgit/sed.git/tree/sed/sed.c?h=v4.7#n196 https://git.savannah.gnu.org/cgit/sed.git/tree/sed/sed.c?h=v... https://github.com/freebsd/freebsd/blob/release/7.0.0/usr.bin/sed/main.c#L133 https://github.com/freebsd/freebsd/blob/release/7.0.0/usr.bi... So, while your interpretation of the shell splitting is correct, it's the different getopt declarations that cause this pain
  - mmt 8y ago
    Indeed, appending an empty string to -i doesn't modify it in any way, AFAIK. It's that the GNU version doesn't require an argument, but, if an argument is to be provided, it must be done as part of the flag, not as a separate element of argv. The MacOS version allows either way of providing an argument, so -i.orig tends to be portable (assuming the -i flag is supported in the first place). Differences in how "traditional" (be they sysv or bsd) versus gnu utilities handle flags and arguments [1] is very well rooted in history, and is hardly unique to sed. I suspect the main reason this has been forgotten is that Linux, which ships with gnu utilities, has been so dominant for so long, though, even before that, it was difficult to find a then-current unix on which gnu utilities couldn't be installed. [1] As the sibling comment points out, the source of difference is getopt, of which there were more than just two versions.. including not even using a library
- mmt 8y ago
  This strikes me a bit like a "doctor, it hurts when I go like that" problem. What's the use case [1] for using a zero-length suffix argument (i.e. editing the file "in place" with no backup)? It's not as if sed is operating on the file actually in place. It uses a temporary file anyway. Varying levels of reliability/portability can be achieved by controlling that temporary file (or subsequent artifacts) oneself, the first level being just to "rm" the backup. [1] Assuming this is in scripting, since the interactive situation is easily enough adjusted on the fly
  - mdaniel 8y ago
    Heh, if I had a dollar for every time I have encountered "what are you doing" while dealing with shell, or (worse!) Makefile, tomfoolery in open source projects, I'd be retired. So, in some sense you're right, but ultimately in the "but it doesn't matter" way because I'm not the only one writing shell, nor the only machine upon which things have to build.
    - mmt 8y ago
      At some point, though, if you're the one complaining about a specific detail, in a way, you're the (only) one. I've seen plenty of un-portable shell scripting, too, but my professional experience includes a time where, essentially, no software [1] could be assumed to be portable, and I did get some dollars for every time, since it was part of my job to ensure as consistent a build environment as possible. In light of your clarification, my question becomes: isn't it actually good to have such assumption-breaking differences in that they call attention to something that is likely to have a broader pattern of non-portability, in which case a broadly effective [2] workaround can be applied? [1] Even/especially GNU tools, where there was something of an assumption that the OS would provide at least fairly complete BSD-compatibility. The existence, and evolution, of libiberty and the autotools, among others, should be instructive. [2] e.g. installing (all the) GNU tools and putting them first in the path on a system that otherwise uses "traditional" syntax

by devy 8y ago

On a related note, I found Bruce Barnett's sed tutorial is one of the best Sed guide out there: http://www.grymoire.com/Unix/Sed.html http://www.grymoire.com/Unix/Sed.html

mdaniel 8y ago

It was really good, thank you! I learned a ton of new tricks from it Separately, I feel like I could have a full time job submitting PRs to fix the GNU-ism of using `sed -i"" ...` versus the BSD/macOS syntax of `sed -i "" ...`. I don't know which of those two camps broke from the other, but holy hell it _broke_ for sure.

thisacctforreal 8y ago
How does the GNU-ism work at a shell level? In your first example $0 is "sed", $1 is "-i", $2 is "...", no? What signifigance does the -i"" have in bash apart from 'concat -i to ""'? The BSD syntax is plain, $1 is the option "-i", $2 is the value for that option: "", $3 is "...". Edit: off by one
- mdaniel 8y ago
  I don't believe it's a bash-ism, I would guess it's GNU getopt defining the `-i` as only optionally requiring an argument, versus the built-in getopt that BSD is using: https://git.savannah.gnu.org/cgit/sed.git/tree/sed/sed.c?h=v4.7#n196 https://git.savannah.gnu.org/cgit/sed.git/tree/sed/sed.c?h=v... https://github.com/freebsd/freebsd/blob/release/7.0.0/usr.bin/sed/main.c#L133 https://github.com/freebsd/freebsd/blob/release/7.0.0/usr.bi... So, while your interpretation of the shell splitting is correct, it's the different getopt declarations that cause this pain
- mmt 8y ago
  Indeed, appending an empty string to -i doesn't modify it in any way, AFAIK. It's that the GNU version doesn't require an argument, but, if an argument is to be provided, it must be done as part of the flag, not as a separate element of argv. The MacOS version allows either way of providing an argument, so -i.orig tends to be portable (assuming the -i flag is supported in the first place). Differences in how "traditional" (be they sysv or bsd) versus gnu utilities handle flags and arguments [1] is very well rooted in history, and is hardly unique to sed. I suspect the main reason this has been forgotten is that Linux, which ships with gnu utilities, has been so dominant for so long, though, even before that, it was difficult to find a then-current unix on which gnu utilities couldn't be installed. [1] As the sibling comment points out, the source of difference is getopt, of which there were more than just two versions.. including not even using a library
mmt 8y ago
This strikes me a bit like a "doctor, it hurts when I go like that" problem. What's the use case [1] for using a zero-length suffix argument (i.e. editing the file "in place" with no backup)? It's not as if sed is operating on the file actually in place. It uses a temporary file anyway. Varying levels of reliability/portability can be achieved by controlling that temporary file (or subsequent artifacts) oneself, the first level being just to "rm" the backup. [1] Assuming this is in scripting, since the interactive situation is easily enough adjusted on the fly
- mdaniel 8y ago
  Heh, if I had a dollar for every time I have encountered "what are you doing" while dealing with shell, or (worse!) Makefile, tomfoolery in open source projects, I'd be retired. So, in some sense you're right, but ultimately in the "but it doesn't matter" way because I'm not the only one writing shell, nor the only machine upon which things have to build.
  - mmt 8y ago
    At some point, though, if you're the one complaining about a specific detail, in a way, you're the (only) one. I've seen plenty of un-portable shell scripting, too, but my professional experience includes a time where, essentially, no software [1] could be assumed to be portable, and I did get some dollars for every time, since it was part of my job to ensure as consistent a build environment as possible. In light of your clarification, my question becomes: isn't it actually good to have such assumption-breaking differences in that they call attention to something that is likely to have a broader pattern of non-portability, in which case a broadly effective [2] workaround can be applied? [1] Even/especially GNU tools, where there was something of an assumption that the OS would provide at least fairly complete BSD-compatibility. The existence, and evolution, of libiberty and the autotools, among others, should be instructive. [2] e.g. installing (all the) GNU tools and putting them first in the path on a system that otherwise uses "traditional" syntax