[packages/grep] - move from GREP_OPTIONS environmental variable to alias due to its obsolescence

[Adam Osuchowski]

Jacek Konieczny wrote:
> Such a shell script for any interactive shell started, just because one
> or two PLD users have uncommented the /etc/env.d/GREP_OPTIONS we might
> have wrongly introduced long time ago?

There are no difference between putting grep's options into alias and
into $GREP_OPTIONS since grep automatically interprets this variable.
They both have same security and other impacts. If grep developers hadn't
decided to obsolete support for this variable, it would remain in PLD's
/etc/env.d for long time without anybody care.

> I don't think it is worth it.

Surely, nothing is worth for someone who doesn't use it...

> Keeping backward compatibility for any strange feature we might have
> once thought it was a good idea would only make more and more mess in
> our distribution. I would say: let's break compatibility whenever we can
> get things simpler/safer/more functional this way and the compatibility
> cost is not too big. If the system won't boot because of the change,
> then it might be a good idea to introduce backward-compatibility hack.
> This is not such a case.

Ok, so why there are still other aliases defined in /etc/shrc.d? For example:

$ grep alias /etc/shrc.d/*.sh
[...]
/etc/shrc.d/colorls.sh:alias ls="ls --color=$COLOR_MODE"
/etc/shrc.d/pinfo.sh:   alias info="pinfo"
/etc/shrc.d/pinfo.sh:   alias man="pinfo -m"
/etc/shrc.d/which.sh:alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
[...]

They also make more mess, they also get things more complicated and less
secure and they also could be the cause of quarrel. Why such ls is good
and grep is bad? Let's break compatibility and remove them all. These,
who want to use them, will define them in their own shell configs.