4 ms·

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

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

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