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.

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.

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.

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.

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

> 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.

> decide that you personally are not interested in working in a manner that benefits the community of users, then you should resign and let someone else take over.

As walled gardens begin to reassert themselves, I think this advice above will be the big argument in open source over the next ten years and needs to be written on every vertical surface. Either we will have social contracts in open source, or we will have commercial contracts. There will be diminishing examples of “both” and people will continue clutching their pearls about co-opting until something changes.

“Be grateful you get anything” is good advice for people struggling to find their own peace of mind, but when it comes up in an argument that’s just abuse.

This is exactly why Torvalds is so radical on not regressing: it is costly for him (I am sure there are many things hr would have done differently now) but ensures the users’ security.

I mean they could just make it an alias that calls the appropriate grep function, and mention fgrep/egrep are just aliases in all the documentation. Tools like ShellCheck could warn on use of fgrep/egrep in scripts in favor of grep if it wants things to be pure.

But the cost of keeping an alias around for decades is negligible I think. It's cheaper than breaking every existing usage in any case.

If your reason for using fgrep is that grep -F is more characters longer, the logical thing would be to have your own function or alias which is called just f or fg.

I stopped using egrep and fgrep in scripts ~25 years ago when I found out they weren't in the standard.

grep -F is only useful when the pattern contains regex characters that should be treated literally, and since the default regex language of grep is BRE, those characters are few.

If only one special character occurs you break even on character count if you use a backslash escape:

  fgrep 'a*c'
  grep 'a\*c'

I find it amusing that someone who uses fgrep all the time - and is presumably familiar with alias and sed - would be worried about the inconvenience of updating their shell scripts...

I think the larger issue is that people generally don't do dependency management for their scripts. Scripts are programs, and they are dependent on the shell environments they are written for.

I think you're not grasping the point that the cost of using 'alias' or updating scripts, though not huge, is paid by every single user, and often over and over again, every time they switch to using a different system. Against this cost for every user, one weighs the benefits of this change - which are zero. Indeed, the benefits are negative, since the maintainers must surely be wasting more time debating the change than they will ever save from it.

Of course, scripts are dependent on their environment. That's why changing the environment for no reason is such a bad idea. Nobody manages their shell scripts to account for the possibility that 'true' might cease to exist some day...

> the cost of using 'alias' or updating scripts, though not huge, is paid by every single user, and often over and over again

The cost of a change that effects N users is paid by N users.

    user*N - change*N = user - change

The amount of work each person must do is not increased by the amount of work everyone else most do.

> Against this cost for every user, one weighs the benefits of this change - which are zero.

That point specifically I am not arguing with. I agree this change doesn't seem to have merit. Remember: I am not the one imposing it on you.

Deprecating fgrep in a grep package distribution is just like deprecating a function in a library. The only reason it would be more difficult to handle that change is if you don't have a straightforward way of managing changes in your scripts and/or shell environments.

And that's the point I was making: it's very common for shell scripts to exist in unmanaged - and frankly brittle - environments. That's a problem that is not unique to this situation.

---

Here's an example:

If someone deprecated the printf() function in gcc version 127.4, replacing it with print(format=False,...), then anyone using gcc 127.4 would have to make a straightforward change to their code. Would it be annoying and pointless? Yes, that's the criteria for this hypothetical situation. Would it be difficult to manage? No, not really. You would just update your gcc dependency version, find and replace printf, sanity check, commit, done.

The reason deprecating fgrep is scary is that people tend to manage shell scripts more liberally. In other words, they likely aren't managed at all. Are they in a git repo? Who is running it? On what machine? What user? Critically, there probably isn't a clear way to predict what version of grep is going to be installed in what environment, and when.

This isn't a new problem. Package maintainers diverge all the time on what binary names and aliases they provide. Tell me, if you opened a shell on any random GNU/Linux system you have access to, and typed "python", would it be version 2 or version 3? Would python3 be in the path?

It's valuable to be able to manage these things. That's why projects like Nix are so popular.