Live data from Hacker News

We are stuck with egrep and fgrep (unless you like beating people)

utcc.utoronto.ca

281–290 of 354 posts

Re: We are stuck with egrep and fgrep (unless you like beating people)

#281
post #270
post #263

Earlier quoted context omitted.

Bash actually has a POSIX compatibility mode. There is a great deal in POSIX that was not in Bourne, native arithmetic expressions being the first to come to mind, then new-style command substitution. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... All of the POSIX utility standards, including the grep variants, can be found in the URL's parent directory: https://pubs.opengroup.org/onlinepubs/96999197…

> Bash actually has a POSIX compatibility mode. It's partial. A short example is `date&>FILE`. [edited typo] On a POSIX shell, `date` will run in the background and the date will be written to stdout (`date&`) and `FILE` will be created or truncated (`>FILE`). Using `bash --posix`, the date will be written to `FILE`, since the incompatible bashism `&>` still takes priority.

I agree that is ambiguous.

If I were writing such a script where I wanted to launch a background process, and then create/truncate a file, I myself would separate them:

  date &
  >FILE
Bash wouldn't mistake that, but a lot of shell scripts look like line noise and there are situations where bad form is required (quoted in an ssh, for example).

Obviously, people wanting the bash functionality in POSIX would:

  date > file 2>&1
Bash discourages the latter form in my man page, but anyone interested in portability knows how profoundly bad that advice is.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#282

Earlier quoted context omitted.

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.

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 ecos…

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.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#283

Earlier quoted context omitted.

Apparently zsh replaces =cmd with cmd's absolute path. TIL.

Yes, very useful to bypass aliases if need be, quickly edit a script ("vi =my-script"), etc. I don't think bash has it; you need to use where/whence/which/command/whatever (I can never remember, why are there so many?!)

Hack: \command instead of command is very unlikely to be aliased, so should work fine.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#285
post #151

Earlier quoted context omitted.

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.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#286
post #151

Earlier quoted context omitted.

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

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

Re: We are stuck with egrep and fgrep (unless you like beating people)

#287
post #286

Earlier quoted context omitted.

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

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

Re: We are stuck with egrep and fgrep (unless you like beating people)

#288

Earlier quoted context omitted.

When it comes to avoiding forks, the question is why do egrep, fgrep have to be shell scripts rather than interpret the invocation name (argv[0]) for switching behavior. Also, I find the original POSIX spec to lump everything into a single grep binary questionable since egrep, fgrep developed as extension and restriction, resp. of grep under a classic regexp discourse and it isn't clear at all that automaton construc…

The gnu coding standards has this to say: https://www.gnu.org/prep/standards/standards.html#index-beha... Please don’t make the behavior of a utility depend on the name used to invoke it. It is useful sometimes to make a link to a utility with a different name, and that should not change what it does. The next section provides some reasoning: Providing valid information in argv[0] is a convention, not guaranteed. Wel…

So if you symlink grep to something else then you have to use `-E` for that, for the 99.999999% use case of the rest of the world egrep being a hardlink to grep would have worked just fine.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#289
post #278

There seems to be a lot of confusion in this discussion about what the change is and how egrep and fgrep work. These are not symlinks like some have suggested but rather shell scripts. You can see the exact commit diff here: https://git.savannah.gnu.org/gitweb/?p=grep.git;a=blobdiff;f... I remember around ~10 years ago being told "you should never use `egrep` because it is slower than `grep -E`." precisely because th…

> I remember around ~10 years ago being told "you should never use `egrep` because it is slower than `grep -E`." I remember around 30 years ago reading that egrep was faster (the UNIX versions were entirely separate implementations, egrep of course being newer) and have used it ever since.

exactly the same here.

although i'm using ripgrep more now, proving that you can teach an old dog new tricks.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#290
post #220
post #138

On my system, egrep and fgrep are _already_ shell scripts, just changed to add the stupid warning: $ cat =egrep =fgrep #!/bin/sh cmd=${0##*/} echo "$cmd: warning: $cmd is obsolescent; using grep -E" >&2 exec grep -E "$@" #!/bin/sh cmd=${0##*/} echo "$cmd: warning: $cmd is obsolescent; using grep -F" >&2 exec grep -F "$@" Looking at src/egrep.sh in the git repo[1], I see that before this warning was added in 2021, the…

If you have interacted with Paul Eggert in real life (I have; he's a professor at UCLA), you would've known that he is a man that values purity over practicality. Not surprising at all.

Is it the same guy that maintains tzdb? https://lwn.net/Articles/870478/
Post reply on HN