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

321–330 of 354 posts

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

#321

Post by mannykannot »

teddyh wrote: post #291
mannykannot wrote: post #284

Earlier quoted context omitted.

There is no largest prime.

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 implications of the argument you are using.)

The NASA managers prior to the Challenger crash thought that what they really wanted was something showing them an actual problem existed. Erring on the side of caution is generally prudent, even in relatively small matters.

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

#322

Post by dschuetz »

Seriously, what's the deal? Just use aliases instead, if you're fond of using egrep or fgrep yourself. Refactoring and re-deploying scripts should not be a big issue in any environment either these days. Admin/Devs are lazy, yes. But THAT is the least of their problems maintaining shell scripts.

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

#323

Post by 1vuio0pswjnm7 »

chasil wrote: post #320
1vuio0pswjnm7 wrote: post #318

Earlier quoted context omitted.

Yikes. This is why I do not use bash. Too complicated. For Linux, I added tab autocomplete to dash and use that for both interactive and non-interactive shell instead of bash. Saves keystrokes and bytes. No need to keep typing "#!/bin/sh" into every script.

You can compile dash with a line editing library, but it does not come in most packages.

I use libedit. I am used to NetBSD sh; dash is similar, derived from the same source. I wanted dash to behave more like NetBSD sh, so I changed it. Anyway, I am not a huge fan of "packages". (The problems described in this thread are one reason why.) Of course I use packaged binaries in some instances, but normally I only install them when needed, use them and then uninstall them when I am done. I prefer to compile the kernel and userland myself. That includes the shell. Simply compiling dash with libedit does not provide tabcompletion. Need to make some small changes.

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

#324

Post by m463 »

hnlmorg wrote: post #146

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…

wow. Didn't realize they are shell scripts on linux.

on (an older) macos system, they are identical executables

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

#325

Post by Jenda_ »

I first thought about different warning that GNU grep >= 3.8 emits: about "stray \" (it's also in the changelog - https://lists.gnu.org/archive/html/info-gnu/2022-09/msg00001...). I have personally seen this one several times already and I only have grep 3.8 on my desktop, as I use Debian stable everywhere else. But this warning may prevent hidden bugs in the future.

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

#326

Post by blep_ »

chubot wrote: post #197

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…

You may also be interested in `grep -P`, where `P` is short for `Please just use PCRE like everything else in this century`. I don't think any of the others support that though.

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

#327

Post by dataflow »

mike_hock wrote: post #304
tannhaeuser wrote: post #191

Earlier quoted context omitted.

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

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 anything. It's like having an argv[1] parameter that is always ignored. It's much better to make it do something that logically corresponds to its value, and the same goes when the index is 0.

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

#329

Post by chaxor »

hnlmorg wrote: post #211
chaxor wrote: post #184

Earlier quoted context omitted.

> "if concerned with performance why are you running code as a shell script" Rewrite grep in python before running - got it. :P

That's not what I suggested. I was saying if you're writing performance sensitive code with a hot loop calling `egrep` then a smarter approach might be to use a language better tuned for performance which supports regex libraries. Shell scripts have their place and can out perform most languages if you're writing simple logic that can run across large datasets in parallel, such as cat very-large-file | grep "do not w…

Perhaps I should have added a "/s", in addition to my ":p", but I appreciate the explanation here nonetheless

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

#330

Post by cryptonector »

naikrovek wrote: post #309
cryptonector wrote: post #248

Earlier quoted context omitted.

Exactly.

the name of an executable is like a global variable the instant it is used as data; it can be changed at any time by someone else and then behavior changes. names are not data. don't make them data. names are names.

Using argv[0] for dispatch has worked for 4+ decades. There is zero non-contrived evidence that it ever fails to work.

Further, there's 4+ decades of legacy here, and it's very rude to break backwards compatibility with something like this where there's no need, no security vulnerability that must be fixed by breaking backwards compatibility.

Post reply on HN