Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

utcc.utoronto.ca

Post reply on HN
Print view View original

191–200 of 354 posts

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

#191

Post by tannhaeuser »

ratmice wrote: post #177
tannhaeuser wrote: post #166

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…

Thanks for the link, but I find that reasoning entirely unconvincing:

The ability to interpret argv[0] as a way to avoid exec is traded for hypothetical linking - but wherever linking is used (such as for idk a mail filter or other configurable executable) that's the place where a wrapper shell script could be used instead. And avoiding improper launching of egrep/fgrep from a program that doesn't bother to build argv[0] properly is also an (unlikely) non-use case that's better handled by fixing that offending program.

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

#192

Post by adren67 »

cies wrote: post #165

I'm on ripgrep (Rust, very fast). Thanks BurntSushi!

I completely agree that rg/ripgrep is a way better alternative to most grep implementations including GNU grep not only in terms of feature

check https://beyondgrep.com/feature-comparison/ for a detailed comparison

but also in terms of speed, including the fact that ripgrep allows greping by default in compress files, many different encoding and more!

This software is really a must-have for anyone who spends some time on the CLI

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

#193

Post by yubiox »

Beltalowda wrote: post #123
salawat wrote: post #111

Earlier quoted context omitted.

So. Thought experiment. Which has lower cognitive load if everyone starts doing it? Explicitly specifying switches, or argv magic? I'd argue, the switches are. In the abscence of the symlinking, that is how the tool functionality would have to be driven anyway. Argv magic now runs into a problem if another program sharing the name ever comes into existence on the path. It's also completely unergonomic in a sense, bec…

I don't think grep does any argv-stuff; I took a quick look and I don't see it. As far as I can tell this is the entire maintenance burden: $ cat =egrep =fgrep #!/bin/sh exec grep -E "$@" #!/bin/sh exec grep -F "$@"

what shell does this?

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

#194

Post by mananaysiempre »

pbhjpbhj wrote: post #175
PaulHoule wrote: post #140

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.

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' ??

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.

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

#195

Post by masklinn »

saalweachter wrote: post #159
kevincox wrote: post #2

What problem is this warning trying to solve? Are these two symlinks too much maintenance burden? Or is the check in the code hurting the code quality? Is the extra check at startup ruining performance? I'm usually in favour of having one way to do things but in this case, with this much legacy it just doesn't seem worth it.

At a guess, it isn't actually the symlinks, it's the argument parsing they're trying to simplify. Old programs have stupidly complex argument parsing. If you can pass your arguments as "cmd foo bar path", "cmd -f bar path", "cmd -fbar path", "cmd path --foo=bar" or "fcmd bar path" and "cmdf path bar", it can be really convenient for users who can structure their commands in the way that makes the most sense for them.…

> At a guess, it isn't actually the symlinks, it's the argument parsing they're trying to simplify.

There’s no parsing. GNU’s egrep and fgrep are trivial shell scripts:

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

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

#197

Post by chubot »

BTW I ONLY use egrep and fgrep !!!

- egrep means [0-9]+ works like in Perl/Python/JS/PCRE/every language, not [0-9]\+ like GNU grep.

- egrep syntax is consistent with bash [[ $x =~ $pat ]], awk, and sed –regexp-extended (GNU extension)

- These are POSIX extended regular expressions. Awk uses them too.

- `fgrep` is useful when I want to search for source code containing operators, without worrying about escaping

This style makes regular expressions and grep a lot easier to remember! I want to remember 2 regex syntaxes (shell and every language), not 3 (grep, awk, every language) !

This change should be reverted; there is no point to needless breakage

Again you wouldn’t remove grep –long-flags because it’s not POSIX

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

#198

Post by markstos »

acdha wrote: post #171
3pt14159 wrote: post #70

Earlier quoted context omitted.

The problem is that we don't just live on our own machines. We hop around to different boxes and just being able to type what you are used to matters. My dotfiles and other tools don't go or even work everywhere. We shouldn't change the oldest parts of our OSes without a really good reason.

I find this reasoning interesting since it's why I _stopped_ using egrep/fgrep around the turn of the century: because those aren't standard, it wasn't uncommon to find that you depended on some behaviour which wasn't available in the version installed on some random server but it worked when you used grep.

I don't remember why I stopped using the shorter `egrep` and only use `grep -E`, but I suspect this was the reason. I used to work on a variety of BSD and Linux servers.

I'm fine with this clean-up and simplification. Eventually, there will be more future users of `grep` than past users.

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

#199

Post by teddyh »

The GNU tools and programs are, theoretically, created for the GNU system, which has evidently chosen to (eventually) not provide fgrep and egrep, as they are not part of the POSIX standard. This is the GNU project’s choice to do. Other operating system projects, like Debian GNU/Linux, who use the GNU tools to provide their operating system, might choose otherwise and (separately) provide the fgrep and egrep tools. This would then be their choice (and one that I personally expect them to make).

I.e. if you don’t run straight GNU as your OS, don’t complain about this; instead object if your operating system which you actually use or depend on choose to break behavior and interfaces which your programs rely on.

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

#200

Post by kevincox »

dahart wrote: post #155

The article and very few comments acknowledge that this is being done to facilitate removal of these binaries. Assuming the binaries are going away, is it better to add a warning, or to surprise people be just removing them? In general, there’s a good, legitimate, hard question here about how to handle removing things from our software. It needs to be done, probably more often than we do it, and it’s hard enough for…

I don't think most of the comments are worrying about the difference between warning or removal. Most of the comments are about what is wrong with egrep continuing to work perfectly well as it has for a decade without warning or being removed.
Post reply on HN