Earlier quoted context omitted.
> The common alternate character, for those cases where normal slashes are not suitable, is a comma character; ‘,’. I've always used "|" since it's so visually similar, and you always want to quote regular expressions anyway.
Doesn’t that confuse you because it is the alternation symbol ( https://regular-expressions.mobi/alternation.html ) in many, if not all, regular expression syntaxes?
Using different delimiters in sed (2010)
21–30 of 30 posts
Re: Using different delimiters in sed (2010)
#22Earlier quoted context omitted.
> The common alternate character, for those cases where normal slashes are not suitable, is a comma character; ‘,’. I've always used "|" since it's so visually similar, and you always want to quote regular expressions anyway.
Doesn’t that confuse you because it is the alternation symbol ( https://regular-expressions.mobi/alternation.html ) in many, if not all, regular expression syntaxes?
Re: Using different delimiters in sed (2010)
#23Earlier quoted context omitted.
Doesn’t that confuse you because it is the alternation symbol ( https://regular-expressions.mobi/alternation.html ) in many, if not all, regular expression syntaxes?
And comma appears in repetition limits (like in /a{1,2}/). I don't see much difference.
Re: Using different delimiters in sed (2010)
#24On 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
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.
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
Re: Using different delimiters in sed (2010)
#25On 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
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.
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
Re: Using different delimiters in sed (2010)
#26Earlier quoted context omitted.
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.
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
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.bi...
So, while your interpretation of the shell splitting is correct, it's the different getopt declarations that cause this pain
Re: Using different delimiters in sed (2010)
#27Earlier quoted context omitted.
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.
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…
Re: Using different delimiters in sed (2010)
#28Earlier quoted context omitted.
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…
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.
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
Re: Using different delimiters in sed (2010)
#29Earlier quoted context omitted.
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.
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
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
Re: Using different delimiters in sed (2010)
#30Earlier quoted context omitted.
> The common alternate character, for those cases where normal slashes are not suitable, is a comma character; ‘,’. I've always used "|" since it's so visually similar, and you always want to quote regular expressions anyway.
Doesn’t that confuse you because it is the alternation symbol ( https://regular-expressions.mobi/alternation.html ) in many, if not all, regular expression syntaxes?