Hacker News Reader

Comment by barrkel | Hacker News Reader

There's a certain type of person who gets pleasure from following rules exactly, particularly when other people don't follow those rules. A kind of smug moral superiority.

If they get into a position of power, they can make life worse for other people, without much regard for the actual cost of breaking such rules.

Removing egrep and fgrep is desperately petty stuff.

View on HN

If you look at the POSIX standard that removes fgrep & egrep [1], then you can see that most of the utilities being removed there really are quite obscure things.

In light of that, then another (perhaps more charitable) way to look at it is that the maintainers are keen to clean up stuff that they perceive as old cruft, and perhaps don't realise quite how ingrained these particular pieces of "cruft" are into the ecosystem.

(On the other hand: the same POSIX link specifies the removal of cpio and, uh, tar. I'm not sure I see that last one flying.)

[1] https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu...

”removal of cpio and, uh, tar”

They’ve finally figured out how to make people use pax.

No `tar`? BURN. IT. ALL. DOWN.

Dear God, what could they possibly be thinking? People are capable of making changes, I think we've all switched from `more` to `less`, *csh to more modern shells, etc., and if `pax` is really all that I'm happy to switch. But removing tar is insane.

It’s a show of how free software partisans are often out of touch.

The cost of egrep and fgrep is just two symbolic links. Some people though would rather talk about ‘libre’ and ‘free as in speech’ and ‘free as in beer’ than talk at all about the user experience. And they wonder why most people just run windows or macOS, but they’ll never understand.

> The cost of egrep and fgrep is just two symbolic links.

A cost that needs to be paid every time you invoke them (a double lookup in the filesystem). Just use a regular link.

(I felt a pedantic response would be in the spirit of this change by the GNU project).

> > The cost of egrep and fgrep is just two symbolic links.

> A cost that needs to be paid every time you invoke them (a double lookup in the filesystem). Just use a regular link.

I'm having a bit of trouble understanding the outrage. Can't all egrep/fgrep in all scripts be fixed once in one or two commands and remain fixed?

     $ sed -i 's/fgrep/grep\ -F/' *.sh

(or something)

I see it as getting accustomed to bells and whistles on some modern shell (like tab completion on zsh and others), then having to use a shell on another system without them (some ragged old korn) and getting tripped up... and the ultimate solution is to be conscious that these things don't work everywhere, so don't be too reliant on them.

How would you find every script given that people download all sorts of scripts all the time? What about docker images?

And that doesn't even open the can of worms relating to quoting...

If we don't know where our scripts are, we have much deeper issues, but still not insurmountable.

      $ sed -i 's/fgrep/grep\ -F/' $(grep -rw '/' -e 'fgrep')

(or something)

I don't manage docker images, but surely there must be a way to do something as simple as replace a file in one image,[1] and if that can be done, doing so in all images is just one clever step away.

[1] https://stackoverflow.com/questions/40895859/how-can-i-overw...

Aside:

What do you mean by "use a symbolic link" (I'm familiar with `ln -s` fwiw) the alias carries the command switch, how do you do that with a link?

    # example
    alias egrep='grep -E'

A program like "grep" gets the path to the binary in argv[0], if it sees that argv[0] is something like

   /some/path/fgrep

it adds the -E flag. A hard link works OK too, as done copying the whole binary.

This is not the case for GNU grep. It appears only some BSDs do this.

You use argv0 to check the program name. The utility has to support it in code which GNU apparently dislikes as someone mentioned elsewhere in the thread.

Currently, egrep and fgrep are shell scripts (the too-simple version of this idea would be

  #!/bin/sh
  exec /usr/bin/grep -E "$@"

but that would mess up help messages and probably also needs disaster handling in case exec fails). Another traditional way, however, is to symlink everything to a single binary, which uses argv[0] or getprogname() to see which name the user called it under and acts accordingly. In the extreme case, you get the "multi-call binaries" Busybox or Toybox, which contain an entire set of Unix utilities in a single (not-too-slim) executable image. GNU grep also used that technique at some point in its history, but it was discarded for a reason I don't recall.

Actually it turns out that, at least in debian 11, you were right on the money:

    cat `which egrep`
    #!/bin/sh
    exec grep -E "$@"

But I agree that it would be cleaner and trivial to implement this behavior by depending on argv[0], GNU style guide be damned.

The worst is when the rule they cite isn't a real rule at all, like Lennart Poettering's defense of systemd breaking on usernames starting with a digit, which is completely valid as far as the Linux kernel is concerned but he decided such names were ackshully against the rules and therefore systemd wasn't broken, bug report closed not-a-bug.

> There's a certain type of person who gets pleasure from following rules exactly, particularly when other people don't follow those rules. A kind of smug moral superiority.

HN commenters in a nutshell.

Not you in particular, but oh my god, the rules-lawyering and lecturing on this site is unbearable at times.

We've seen a lot of this in recent years.

Reply on news.ycombinator.com