[illumos-Developer] sed -i behavior - question

Erik Trimble erik.trimble at oracle.com
Tue Dec 21 10:24:31 PST 2010


On 12/21/2010 6:55 AM, Garrett D'Amore wrote:
> On 12/21/10 02:51 AM, Joerg Schilling wrote:
>> "Garrett D'Amore"<garrett at damore.org>  wrote:
>>
>>> If you don't use sed, or care about it, delete this message.
>>>
>>> The question centers around "-i" in our implementation of sed.  
>>> While we
>>> have a "-i" flag, it *assumes* a suffix (extension) will follow it.  
>>> The
>>> next argument is taken as such unconditionally.  (E.g. it uses i: in
>>> getopt string.)
>>>
>>> Now GNU sed has the SUFFIX as optional.  It looks at the next string 
>>> and
>>> tries to make a decision based on whether the next option starts with a
>>> "-" or not.   This feels far "tar-ish", unfortunately, and violates the
>>> CLIP (and I think, the POSIX rules too.)
>> The only clean way to implement optional option-Arguments is to 
>> require the
>> arguments to directly (without space) follow the option.
>
> I'd argue that optional option arguments are inherently unclean, but I 
> agree with you in this regard.  If you have to live with them, then 
> this is probably the best compromise.
>
> In this case, I'm not yet convinced we have to follow the GNU 
> example.  Certainly FreeBSD does not.
>
>   - Garrett

I'm all for as much GNU-compatibility as we can get, but not at the 
price of POSIX compliance.  That is, if someone so very much needs GNU 
sed, well, they know where that is.

Frankly, as a long-term sed user, I think I've used '-i' maybe a couple 
of times over 20 years.  For software packages that use GNU configure, 
it's a simple test for compatibility - if you don't have it, then it's 
easy to get.  I don't see any pre-built packages using esoteric sed 
commands; so, that leaves custom scripts people have written.  I'm not 
really in favor of supporting people's bad habits, even if it nominally 
increase "portability".

Maybe this suggestion:  enforce the POSIX style, and print a warning if 
the GNU style is supplied instead?

I know this sounds kinda snobbish, but POSIX compliance is really 
important to me; I've worked in far too many multi-platform shops to 
tolerate vendor-specific stuff (from wherever it comes).


-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)




More information about the Developer mailing list