Live data from Hacker News

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

utcc.utoronto.ca

231–240 of 354 posts

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

#231

Earlier quoted context omitted.

Why wouldn't they just convert them to aliases instead of adding the warnings?

aliases aren't a global state. They're shell and profile specific (as there are plenty of instances where a profile isn't loaded). With `egrep` defined as a shell script, any process (even callers who are not shells) will have the same behavior. That doesn't mean the shell script is the best solution though. Personally I'd rather they be a symlink to `grep` and have grep check the name it's been invoked as, and if it…

Sure, makes sense- so then I guess I'd amend my question to that: I can't see why they'd add the warning instead of just redirecting the command

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

#232

It's interesting to think about the way these things evolved. Imagine if, over time, the `compress` utility got -gz, -bz2, -lzma, etc. flags, and `gzip`/`bzip2` were all converted to deprecated shell scripts. When is the right time to consolidate variants under one program (and deprecate the variants), and when is it better to let small utilities keep doing one thing well(TM)? I see people talking about removing the…

The original UNIX design philosophy was very much one-command for one-thing.

=> http://harmful.cat-v.org/cat-v/ UNIX Style, or cat -v Considered Harmful

But that argument is an argument against pretty much all command-line flags. Rob Pike argues `ls` shouldn’t have an option to split the output into columns, you should pipe ls into a column-splitting program.

So the pure version of that philosophy is long-gone. It makes this current effort seem rather arbitrary and meaningless.

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

#233

Earlier quoted context omitted.

You could write a little function that does that

For me, that's the biggest takeaway: Nothing is stopping users from maintaining the behavior they had previously. It's being made explicit that the burden of maintaining that behavior is changing.

Yeah, this is a good point. This is basically just GNU saying that those old aliases are not something they want within the scope of grep itself.

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

#234

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…

”removal of cpio and, uh, tar”

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

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

#235

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…

Different behavior based on argv[0] was first brought to my attention when I discovered that /bin/sh was a symlink on some Linux systems. Bash has a Bourne shell compatibility mode.

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

#236

I use fgrep all the time. Why should I spend time converting scripts, and retraining my fingers, and forever after taking longer to type grep -F? This is a breaking change that has no upside, only downside. It is idiocy. Just to elaborate, there must be many thousands (hundreds of thousands? millions?) of shell scripts out there that use fgrep. For no reason at all (whatever maintenance burden fgrep represents must b…

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.

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.

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

#237
> What's special about GNU Grep 3.8 is that its version of egrep and fgrep now print an extra message when you run them. Specifically, these messages 'warn' (ie nag) you to stop using them and use 'grep -E' and 'grep -F' instead.

Can we please stop with the make-work nonsense??

Please stop making us change scripts just because you've decided that some command shouldn't have existed that does exist. Stop it. Just stop.

See `which` deperecation. Please, no more.

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

#238

> What's special about GNU Grep 3.8 is that its version of egrep and fgrep now print an extra message when you run them. Specifically, these messages 'warn' (ie nag) you to stop using them and use 'grep -E' and 'grep -F' instead. Can we please stop with the make-work nonsense?? Please stop making us change scripts just because you've decided that some command shouldn't have existed that does exist. Stop it. Just stop…

[deleted]

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

#239

Beyond the inadvisability of making a breaking change for no reason, it's worth noting that deprecating fgrep is actually positively undesirable. Use of fgrep should be encouraged . The reason is that many times people want to match a literal string. This is best done with, for example, "fgrep [a] Of course, one could get in the habit of using grep -F when intending the pattern to be just a literal string. Or one cou…

If we are talking about interactive use, you could always use an alias.

But if we are talking about scripts, you should at least use "fgrep -- [a] If you don’t do this, the script will fail spectacularly the day when the string happens to start with a hyphen (-).

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

#240
post #10

Earlier quoted context omitted.

It seems pretty simple, piping bash commands into other bash commands and other text stream juggling is a pretty typical use of these commands and so changing what stream is output can change the behavior of consumers of the output of these functions. I haven’t done anything with fgrep and egrep before but piping grep into another grep for more complex classes of text search is something i use a lot.

It's more than likely the warning will be printed to stderr, not out, so there will be no impact on the actual work done.

The simple fact that you have to wonder about that question is the failure.

Everything about this, even this comment I'm writing right now, is a waste of time.

Post reply on HN