> > That also says:
> >
> > The use of conflicting mutually-exclusive arguments produces undefined
> > results, unless a utility description specifies otherwise.
> >
> > In that paragraph, "application" refers to the thing invoking the utility.
> > So
> > a conforming script/user/etc is prohibited from calling grep -E -F.
>
> Oops. Studying that again, i come to the conclusion that you are right.
>
> So we are not required to change it.
>
> - in favour of change: erroring out is a bit less error prone
> - against change: not erroring out is potentially more useful
> because it allows overriding when playing with aliases and
> with concatenation of option lists
> - in favour of change: but the above games are dangerous and can
> trap people with non-portable behaviour
> - against change: every change risks breaking people's scripts
> - against change: other implementations differ from each other,
> so we would just trade one portability issue for another
>
> So, no clear argument either way, which probably means that it should
> be left alone...
if (Fflag && Eflag) {
fprintf(stderr, " ----------\n");
fprintf(stderr, " / \\\n");
fprintf(stderr, " / REST \\\n");
fprintf(stderr, " / IN \\\n");
fprintf(stderr, " / PEACE \\\n");
fprintf(stderr, " / \\\n");
fprintf(stderr, " | __progname |\n");
fprintf(stderr, " | 0 Au |\n");
fprintf(stderr, " | killed by an |\n");
fprintf(stderr, " | undefined |\n");
fprintf(stderr, " | behaviour |\n");
fprintf(stderr, " | 2017 |\n");
fprintf(stderr, " *| * * * | *\n");
fprintf(stderr, " _________)/\\\\_//(\\/(/\\)/\\//\\/|_)_______\n");
reboot(RB_NOSYNC);
abort();
}
Or, we stick to the existing undefined behaviour, which is assuredly
compatible with behaviours people have in scripts written in the last
30 years.
If you want strict behaviours, you write a new command. Then collect
a user community for it. Over time, watch the things you didn't
define strictly build up... until you find yourself in similar
circumstances...
