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

331–340 of 354 posts

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

#331

Post by henearkr »

henearkr wrote: post #124
ksherlock wrote: post #38

Earlier quoted context omitted.

GNU egrep and fgrep are wrapper scripts (and have been for 10 years for more). Wrapper scripts that now warn you not to use them. https://git.savannah.gnu.org/cgit/grep.git/tree/src/egrep.sh

This should be the top comment lol. Such an insanity... They are wrapper scripts that precisely enable to obey to the advice the warning is giving, yet the warning ends up advising not using the wrapper...

I cannot edit anymore, so I add this: This is the case in a distribution (Arch) that has effectively taken the maintainer's advice into account, not the reverse.

So I was wrong, and let's not be unfair to the maintainer.

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

#332

Post by teo_zero »

kccqzy wrote: post #293
Phelinofist wrote: post #290

Earlier quoted context omitted.

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

Yes he is. He's a maintainer for a lot of GNU software including Emacs, sort, etc. Running fgrep -U -l -r "Paul Eggert" /usr/bin should turn up quite a few results. (That's of course an undercount because he doesn't always put his name into everything he touches.)

You surely mean

  grep -F -U -l -r "Paul Eggert" /usr/bin
Don't you?

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

#333

Post by arrakeen »

debian appears to be just removing the warnings:

    grep (3.8-2) unstable; urgency=low
      This Debian grep release removes the deprecation warning about egrep and
      fgrep. These alternative programs will be still shipped by Debian. Although,
      for portability reasons, users are encouraged to use grep with the concerned
      options instead of those alternative programs.

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

#334

Post by AshamedCaptain »

rgoulter wrote: post #121
AshamedCaptain wrote: post #50

Earlier quoted context omitted.

Both of your suggestions are basically equivalent to "think before you upgrade" and/or "don't upgrade". This is the second elephant in the room with all these distros that "don't use globals" and/or statically link everything (or do an analogue to that, like nix). There's very little benefit for desktops. So the upgrade to dependency X breaks component Y, and you are forced not to update X, or at least, Y's copy of X…

> The situation is as unatenable long-term as it is on a regular distro. I may be misremembering, but isn't this pretty much the default user experience on rolling distributions like Arch Linux? -- You consult the wiki to see what changes you need to make are (or maybe see what breaks after an update), make the change, and get on with your desktop experience.

That is exactly my point.

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

#335

Post by teddyh »

romeoblade wrote: post #302
teddyh wrote: post #239

Earlier quoted context omitted.

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

I thought I was the only one who perfected long options! Are you me? I've had coworkers call me out (not rude, just "hey you know you just use -l... instead of --longopt") on calls because I always use long options when available. I use the hyphen explanation all the time as I've ran into it a few times. I also prefer CLI applications that are designed to use the "=" for arguments with long options. Applications whic…

I don’t always use long options interactively, only sometimes, but I certainly try to always use it in scripts, for readability.

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

#336

Post by tomn »

txutxu wrote: post #266
tomn wrote: post #158

Earlier quoted context omitted.

the overhead isn't even an extra fork, as it uses exec

On most context involving "using grep", shell scripts, interactive shell, etc, it's nothing. 81 Vs 128 system calls on my laptop (just printing --version) $ strace -fc grep -E --version 2>&1 | tail -1 100.00 0.000000 0 81 3 total $ strace -fc egrep --version 2>&1 | tail -1 100.00 0.000000 0 128 6 total Measured with "time" 0m0.002s Vs 0m0.003s, always, testing 4 times each option. Most situations where it could be be…

true. using hyperfine on my machine shows that grep is about 2x faster than egrep (and yeah, still nothing, 1.5 vs. 3ms)

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

#337

Post by teddyh »

mannykannot wrote: post #321
teddyh wrote: post #291

Earlier quoted context omitted.

Using that model, we can prove conclusively that, since a behavior has changed (a warning printed), it might cause problems. Therefore, we cannot prove that it cannot cause problems. What we would really like, though, is an actual problem shown to exist. Just like in mathematics; it’s one thing to prove that it’s impossible to prove something could not exist, but another thing entirely to show it existing .

You are overlooking something here: I never said anything about proof. I explicitly wrote 'convincing evidence' because proof is too demanding! It's rather amusing how you have flipped from saying "you can't prove a negative" to an argument for the certainty of observable effects and the probability of consequences! (you wrote might cause problems, but everyone can see that's an unrealistic understatement of the impl…

> everyone can see that's an unrealistic understatement of the implications of the argument you are using

If nobody can show an actual existing problem, or even an example of reasonable code someone could have written which would be impacted by a the printed warning, then yes, I would think that I was charitable when I wrote “might cause problems”.

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

#339

Post by mike_hock »

dataflow wrote: post #327
mike_hock wrote: post #304

Earlier quoted context omitted.

I find the reasoning convincing. It's the principle of least surprise. And a bunch of other principles. I don't want a program to care what it's executable name is, if it's being invoked with a relative path, absolute path, through a symlink or hardlink or anything else. Of course, there are exceptions to the rule, like busybox. The point is to have uniform, predictable behavior across the ecosystem and not have ever…

What makes the reasoning unconvincing for me is that it's simply wrong: argv[0] is not the name of the program being invoked. If it were, I would agree, but it's not. Rather, it's simply another argument whose default value is the name of the program being invoked, but you can pass something else in place of it if you want. Moreover, what I find surprising is seeing a knob that I can adjust, but which doesn't do anyt…

> argv[0] is not the name of the program being invoked [...] it's simply another argument whose default value is the name of the program being invoked

That's your opinion. Another opinion would be that it's an interface contract with the calling program to pass the path to the program being invoked in argv[0]. This contract has been established by common practice and a corresponding expectation by most programs, even if it wasn't formally specified.

I'm not necessarily taking that position, but I can see convincing reasons to do so, and as such the reasoning in the article is also convincing.

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

#340

Post by ykonstant »

btdmaster wrote: post #283
Beltalowda wrote: post #245

Earlier quoted context omitted.

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.

This is a very useful hack, thanks. Unfortunately, my defensive scripting instincts do not allow me to use it on the "serious" situations.
Post reply on HN