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

241–250 of 354 posts

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

#241

Post by raverbashing »

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…

> But it is always possible to launch the program and give a nonsensical value in argv[0].

Well, if you're being a smart@ss and doing that, don't expect it not to break later.

Putting a weird value there and hoping it won't break is as stupid as calling the program with wrong options and hoping it will work.

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

#242

Post by Beltalowda »

Ensorceled wrote: post #79
Beltalowda wrote: post #29

Earlier quoted context omitted.

They didn't necessarily "choose communities to represent". As the maintainer and author of various open source libraries and tools that are used by many thousands, in most cases it's just that ... I'm one of the few willing to spend the time on it, and it's usually useful for myself as well. I don't really "represent" any community or anyone. That said, I certainly wouldn't have put in this change myself, because I w…

That's a very different thing than joining GNU. If your package gets adopted by thousands of peoples that's having this community thrust upon you. I still feel you have an obligation to transfer to someone willing to shoulder the responsibility if this happens, an obligation incurred by publishing it in the first place. Though, I don't feel too strongly about this.

Jim Meyering made the change, who has been maintaining these things from before half the people here were born.

Even when taking over maintainership for popular packages later on, people often aren't exactly breaking down the door for it. So my philosophy is simple: "if you do the work, you get to decide". I may like or dislike these decisions, and at times I may even rant about how stupid a certain decision is, but in the end ... the people doing the work get to decide. The alternative of being beholden to a vaguely defined "community" of armchair quarterbacks is much worse, IMO.

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

#243

Post by Asooka »

It's probably time for the Linux world to distance itself from the trash fire that is GNU, as they keep breaking backwards compatibility. This isn't 1970, it's 2022, people! You do not just break the world for no good reason.

GNU has served its purpose, it's time to stop relying on them. It would be a lot easier to convince the BSD people to support the few GNU specific flags in user land utilities and to add GNU libc compatibility, than it would be to convince the GNU maintainers to write good software.

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

#244

Post by richard_todd »

mirker wrote: post #228
richard_todd wrote: post #213

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…

As someone who learned about regular expressions before extensively using grep, I found grep to be quite unintuitive, since extended grep is what I am conceptually thinking about from a “theory” point if view. One difference between grep and compression is that grep is bounded by regular languages, but compression is more free form. It’s conceivable to therefore view grep as mature enough of a technology to be finish…

Consider the popularity of ffmpeg and imagemagick. Putting the mainstream algorithms together under one interface seems to be an appealing model to a lot of people, even though new algorithms are constantly being developed in those areas.

Personally, for audio encoding, I'm much happier just installing ffmpeg than I would be gathering and learning a bunch of flac/ogg/opus/mp3/etc encoders.

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

#245

Post by Beltalowda »

forgotpwd16 wrote: post #209
yubiox wrote: post #193

Earlier quoted context omitted.

what shell does this?

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?!)

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

#246

Post by hinkley »

radford-neal wrote: post #107

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…

> decide that you personally are not interested in working in a manner that benefits the community of users, then you should resign and let someone else take over.

As walled gardens begin to reassert themselves, I think this advice above will be the big argument in open source over the next ten years and needs to be written on every vertical surface. Either we will have social contracts in open source, or we will have commercial contracts. There will be diminishing examples of “both” and people will continue clutching their pearls about co-opting until something changes.

“Be grateful you get anything” is good advice for people struggling to find their own peace of mind, but when it comes up in an argument that’s just abuse.

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

#247

Post by Beltalowda »

ur-whale wrote: post #134
Beltalowda wrote: post #24

Earlier quoted context omitted.

stderr

> stderr For now.

Clearly that will never be done. Outputting this to stdout would be ridiculous and break everyone and everything using it. Might as well just outright remove egrep and fgrep. Ridiculous comment.

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

#248

Post by cryptonector »

raverbashing wrote: post #241
ratmice wrote: post #177

Earlier quoted context omitted.

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…

> But it is always possible to launch the program and give a nonsensical value in argv[0]. Well, if you're being a smart@ss and doing that, don't expect it not to break later. Putting a weird value there and hoping it won't break is as stupid as calling the program with wrong options and hoping it will work.

Exactly.

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

#249

Post by cryptonector »

hnlmorg wrote: post #172
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…

> 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. I don't know. I'd have taken the argv[0] approach personally. And it's the approach some other grep implementations have taken too (eg https://github.com/freebsd/freebsd-src/blob/main/usr.bin/gre... ). The argv[0] approach (to me) feels like a righ…

Switching behavior according to argv[0] been used in Unix for decades. mv(1)/ln(1)/cp(1) historically are the same program, hardlinked.

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

#250

Post by _jal »

iso1631 wrote: post #99
_jal wrote: post #60

Earlier quoted context omitted.

> It is legitimate to consider convenience for the maintainers In which case, time to fork it. I don't fucking care who you are, you do not break grep and keep a privileged position on my machine.

Nobody is stopping you from forking it.

That's the plan. I haven't built a new package in a while, time to remember how `fpm` works.

Conflicts: grep

Provides: grep

Post reply on HN