It's Past Time To Stop Using egrep & fgrep Commands, Per GNU grep 3.8

[mdedetrich]

This is only more fabricated BS. Rationalizing someone else's BS still leaves you with BS. It's the GIGO principle.

Firstly its not bullshit, for something to be bullshit it has to be shown to be blatantly false. This is stating a hypothetical argument and if you argue that this is bullshit then you are basically claiming all of history is bullshit because in a lot of cases there isn't first hand evidence and so people need to piece together theories from what they have.

GIGO is also a hilarious (not in a good way) comparison.

According to the Computerphile interview excerpt that ssokolow posted, they didn't rely on static linking to build more complicated data processing pipelines, but rather used temp files.

The whole argument is that they didn't want rely on static linking which is why (hypothetically) they came up with shell and also apparently used temp files. What you are saying isn't disapproving this point at all, the opposite.

[rob11311]

Sometimes API breakage is a good thing. fgrep and egrep as shell scripts is lower performance than alias option alias option is technically worse than the direct commands in the shell script. Lot of ways making fgrep and egrep alias only has another advantage.

No need for shell scripts or even aliases, this is pointless breakage that makes instructional books incorrect.

The program can check how it was run, then set the flag appropriately.
Hardlinking the commands: ln {e,f,}grep avoids duplication. All you have to do probably is set an option flag, but I haven't looked at the current implementation.

Also it's easier to justify a single static binary with 3 heavily used commands too. In the past many programs in a suite used together were linked in that way to save disk space and cached memory improving performance.

[oiaohm]

The program can check how it was run, then set the flag appropriately.
Hardlinking the commands: ln {e,f,}grep avoids duplication. All you have to do probably is set an option flag, but I haven't looked at the current implementation.

What you just described in the busybox method that is process arg0. This does in fact have a downsides. What if something else hardlinks to egrep/fgrep.... this will change the arg0 value. Shell scripts as egrep and fgrep have a overhead but also processing and checking arg0 every run has a overhead. Yes there have been some fun issues with busybox and some items ln -s to the provided programs for odd reasons. Alias there are no files to link due to it being Alias and the shell script method link to works perfectly fine..

rob11311 the current method for GNU grep is the shell scripts and has been that for over 5 years and before that it was 3 independent binaries. Yes 3 independent binaries because old scripts you cannot depend on arg0 as your deciding value because they may have soft or hard linked stuff.

Big questions is how is egrep and fgrep still being used?

If people are still directly using it from programs that are not shell you need a file entry on disc.
If people are still hard/soft linking egrep/fgrep around under different names individual binaries/shell scripts are still required for egrep/fgrep because the arg0 method will not be dependable and alias will not work.

Of course there is a good question really does egrep/fgrep shell scripts need to remain in gnu grep as they can be used basically generically with all versions of grep.

alias egrep='grep -E'​
alias fgrep='grep -F'​​​

Yes the -E and -F to replicate egrep and fgrep are mandated by the posix standard to be part of the grep command.

No need for shell scripts or even aliases, this is pointless breakage that makes instructional books incorrect.

Sorry the idea of the pointless breakage you need to look closer. You are making a posix conforming shell script that should not contain egrep or fgrep. Instruction books contain a lot of bashish yes dash and bash detect themselves running as /bin/sh they disable stack of stuff to be some what in posix conformance..

https://pubs.opengroup.org/onlinepub...ties/grep.html
Yes the Posix standard has grep but does not have egrep or fgrep.

This grep has been enhanced in an upwards-compatible way to provide the exact functionality of the historical egrep and fgrep commands as well. It was the clear intention of the standard developers to consolidate the three greps into a single command.

The old egrep and fgrep commands are likely to be supported for many years to come as implementation extensions, allowing historical applications to operate unmodified.

Yes posix standard egrep and fgrep is for historical applications. Yes the Linux standard base had the same define. Instruction books teaching new people how to do things should be using grep -E instead of egrep and grep -F instead of fgrep because egrep and fgrep is not part any standard to be included. Yes egrep and fgrep should be optional extras and most likely in their own package as either shell script or alias.

Please note it was back in 1991 that egrep and fgrep was declared historical by posix standard. So this is 20 years of people writing instructions ignoring the standards.

[coder]

Firstly its not bullshit, for something to be bullshit it has to be shown to be blatantly false.

Stating something as fact without any direct knowledge or supporting sources is, in fact, bullshit. It cannot be acceptable to spout made-up facts and get partial credit if you turn out to be 10% correct, by luck or happenstance. If you don't have compelling, supporting evidence, then what you're saying is merely noise and should be treated as such.

This is stating a hypothetical argument

That's not how it was phrased. It was stated as fact, so that's the standard against which it must be measured.

and if you argue that this is bullshit then you are basically claiming all of history is bullshit

History relies upon sources, which good historians try to use and cite. If this measured up to that standard, we'd be having a very different discussion. Yes, there's not only one version of history, but the narrative that wins out should be the one that's most consistent with the preponderance of supporting evidence. To make historical claims with zero supporting evidence would be considered malpractice and you'd quickly be disregarded as a quack or conspiracy theorist.

The whole argument is that they didn't want rely on static linking which is why (hypothetically)

I already said I'm not interested in your pathetic attempts to rationalize that BS. Cite sources or don't waste your time replying.

You're obviously defending Luke_Wolf because you're still butthurt over the last stupid argument you lost with me. He clearly doesn't know what the F he's talking about, or he wouldn't have posted and doubled-down on his ignorant statements about stdout. He doesn't need you to try and salvage any of his arguments. In fact, nobody does. If you don't have solid evidence, then you're really not helping the world by pushing his narrative of "alternative facts" around the origins of pipes.

Think about your motives and objectives. If you do, you should see that this is truly a cause you never should have taken up. Find something better to do with your time and energy.

[ssokolow]

Please note it was back in 1991 that egrep and fgrep was declared historical by posix standard. So this is 20 years of people writing instructions ignoring the standards.

Microsoft didn't decide to drop support for Win16 until Win64, on the rationale that two decades of backwards compatibility should be enough, and preserving egrep and fgrep is a much easier thing.

It's this sort of decision that makes people call Linux API unstable compared to the near-monopoly choice everyone has at least some familiarity with.

Hell, for my older games (eg. Loki Software releases), I often find it's easier to just run the Windows version in Wine than the Linux version on Linux.

[mdedetrich]

Stating something as fact without any direct knowledge or supporting sources is, in fact, bullshit. It cannot be acceptable to spout made-up facts and get partial credit if you turn out to be 10% correct, by luck or happenstance. If you don't have compelling, supporting evidence, then what you're saying is merely noise and should be treated as such.

No its not, thats called absense of evidence. Bullshit would be someone stating something thats the complete opposite of what another person has said.

History relies upon sources, which good historians try to use and cite. If this measured up to that standard, we'd be having a very different discussion. Yes, there's not only one version of history, but the narrative that wins out should be the one that's most consistent with the preponderance of supporting evidence. To make historical claims with zero supporting evidence would be considered malpractice and you'd quickly be disregarded as a quack or conspiracy theorist.

You clearly have no idea how history works. In a lot of cases there is zero or little evidence, and in those cases historians we say "we cannot absolutely prove this is what happened, but because x and y and z occurred there are some plausible theories as to what happened". Even if there is evidence it doesn't mean it's reliable either, people can lie or selectively say things.

I already said I'm not interested in your pathetic attempts to rationalize that BS. Cite sources or don't waste your time replying.

Sorry, but no one cares what you are interested in. If you don't want to participate in the discussion because people cannot provide 100% hard evidence (which in cases like this its quite common) then don't.

You're obviously defending Luke_Wolf because you're still butthurt over the last stupid argument you lost with me.

Speaking of coming with up with bullshit, I am not "obviously" butthurt by anything. In fact I have no idea what argument you are talking about likely because I have completely forgotten about it and/or I didn't "lose it" like you think I did. Unlike some people around here, I don't get overly emotional or defensive about internet arguments on forums. You should probably do the same and take a chill pill before you get thrombosis or something.

He clearly doesn't know what the F he's talking about, or he wouldn't have posted and doubled-down on his ignorant statements about stdout. He doesn't need you to try and salvage any of his arguments. In fact, nobody does. If you don't have solid evidence, then you're really not helping the world by pushing his narrative of "alternative facts" around the origins of pipes.

Sorry to burst your black and white naive world view, but a lot of things are made based of assumptions due to lack of complete evidence. You may not like it, thats fine, but people do this and its useful to do so because there isn't a 100% accurate recollection of all events in history.

Think about your motives and objectives. If you do, you should see that this is truly a cause you never should have taken up. Find something better to do with your time and energy.

I am just stating that what Luke_Wolf said is plausible based on the evidence. I cannot claim with certainty thats what happened but judging by the evolution of what occurred with nix/POSIX its not unreasonable to claim. I don't have any real motives or objectives apart from engaging in a discussion for exchange/debate of information. The f**k you think this is, some kind of holy war or some political party debate?

And to be clear I am not defending Luke_Wolf, he obviously was overconfident in what he was stating but his conclusion on that specific point isn't entirely stupid either. He may have said some other stupid stuff which I can't comment on (which is why I didn't), but then again everyone has said stupid shit so if you are going to dismiss him on that we shouldn't be selective about it because for example right now, in my view you are saying stupid stuff.

[oiaohm]

Microsoft didn't decide to drop support for Win16 until Win64, on the rationale that two decades of backwards compatibility should be enough, and preserving egrep and fgrep is a much easier thing.

egrep and fgrep were both declared historical in 1991 by posix standard. So by standard has been only for backwards compatibility for over 2 decades now.

It's this sort of decision that makes people call Linux API unstable compared to the near-monopoly choice everyone has at least some familiarity with.

Again no. This decision to remove egrep/fgrep from GNU grep should have been done along time ago. People have been ignoring that egrep and fgrep are not part of the posix standard and are only list for historic compatibility. Being for compatibility egrep and fgrep with possible alias should most likely be in their own compatibility package.

Also think about this GNU grep is not the only grep program made. egrep and fgrep done as shell script or alias would be generic between all grep implementations.

You talk about Linux ABI as unstable. The egrep and fgrep are unstable cross posix implementations. If you are making a script that is posix compadible it should not contain egrep and fgrep. Like it or not there is a valid reason to remove egrep and fgrep functionality from all the grep packages and move it to a compatibility package.

The problem here is people have not been reading the standard that grep is meant to be based on. Posix standard defines the core functionality of the grep package. This does not contain egrep or fgrep as being part of that package.

Basically its over 2 decades later and the shoe on egrep and fgrep is finally dropping because the one maintianing the GNU grep read the standard and noticed that egrep and fgrep should not be included in the core grep package. If people/maintainers want them they should be doing their own alias and shell scripts. Not generating shell scripts will make GNU grep build process simpler.

Having a generic solution for egrep and fgrep will make it simple when ever someone decide to make their own grep program.

Hell, for my older games (eg. Loki Software releases), I often find it's easier to just run the Windows version in Wine than the Linux version on Linux.

I don't disagree that there is a problem with old binaries on Linux. Windows has SXS to have multi runtimes. Wine in fact has to support this functionality. Windows ABI is not more stable than Linux ABI. The difference here is Windows has a proper system to run multi generations of ABI at the same time..

There is something really horrible here as well. The worst to run Loki games on modern day Linux when you look closer is using functionality in glibc that was removed for security reasons. So yes some of them the safe answer is run the Windows version in Wine not the loki binary if you are going to network the game at all.

Backwards compatibility is a true Pandora box of a problem.. Its nice to have but having it brings stack of problems including quite lot of security ones. Lot of malware works so well on windows due to how many backdoors have to be kept around to be backwards compatible.

[ssokolow]

Again no. This decision to remove egrep/fgrep from GNU grep should have been done along time ago. People have been ignoring that egrep and fgrep are not part of the posix standard and are only list for historic compatibility. Being for compatibility egrep and fgrep with possible alias should most likely be in their own compatibility package.

They were part of the POSIX standard for a period of time (they're listed as utilities from a previous version of the standard, now removed), meaning that the responsible thing to do as a stewards of a POSIX-compliant platform is to preserve compatibility with now-legacy scripts that were written when they were part of the standard.

Also think about this GNU grep is not the only grep program made. egrep and fgrep done as shell script or alias would be generic between all grep implementations.

Again, I don't care how they're implemented... just that the maintainers take responsibility for ensuring that scripts which depend on them continue to work.

I don't disagree that there is a problem with old binaries on Linux. Windows has SXS to have multi runtimes. Wine in fact has to support this functionality. Windows ABI is not more stable than Linux ABI. The difference here is Windows has a proper system to run multi generations of ABI at the same time..

Again, I don't care how it's achieved. I'm talking about, as an end-user, the observed effect. Windows manages to achieve best-in-class backwards compatibility while Linux does not... which leads platform developers to try to justify the status quo and The Year of the Linux Desktop™ to not come because users look and say "All I know is that, from where I'm standing, Microsoft did what I need and you didn't, so I'll go with Microsoft".

[oiaohm]

They were part of the POSIX standard for a period of time (they're listed as utilities from a previous version of the standard, now removed), meaning that the responsible thing to do as a stewards of a POSIX-compliant platform is to preserve compatibility with now-legacy scripts that were written when they were part of the standard.

This is error. First Posix standard covering shell 1992 there is a issue.

https://pubs.opengroup.org/onlinepubs/009656399/toc.pdf

The egrep utility may be withdrawn from a future issue; applications should migrate to grep−E.

Yes that is 1994 but the first version had the same warning. Any script written after 1991 should not be using egrep if it is it not posix conformant. Yes egrep and fgrep yes are both in the posix standard with marking of do not use for over 2 decades and this is from the first version of the Posix standard covering shell.

Now read the Posix define of "To Be Withdrawn":

To Be Withdrawn
Some of the utilities in this issue are marked TO BE WITHDRAWN. Various factors may have
contributed to the decision to withdraw a utility. In all cases, the reasons for withdrawal of a
utility are documented on the relevant pages.
If a migration path exists, advice is given to application developers regarding alternative means
of obtaining similar functionality.This information may be found in the APPLICATION
USAGE sections on the relevant pages.
Interfaces marked TO BE WITHDRAWN shall comply with this document’s requirements.
However, they will be marked WITHDRAWN in a future issue of this document.Interfaces
marked WITHDRAWN may still exist on conformant implementations.
Application writers should not use functionality marked TO BE WITHDRAWN.

Then read:

Withdrawn
Withdrawn interfaces may still exist on conformant implementations.However, they will not
appear in the next issue of this document.Application writers should not use functionality
marked WITHDRAWN.
If a migration path exists, advice is given to application developers regarding alternative means
of obtaining similar functionality.This information may be found in the APPLICATION
USAGE sections on the relevant pages.

Once something is removed from the POSIX standard its optional for a POSIX platform to have it. In fact if what you are doing is Posix conforming new you should not be using the Withdrawn or To Be Withdrawn functionality.

Again, I don't care how they're implemented... just that the maintainers take responsibility for ensuring that scripts which depend on them continue to work.

By Posix standard this is wrong. The reality is no script written in the last 20+ years should have used egrep or fgrep. If your script written after 1992 contains egrep or fgrep its non conformant to posix standard. Yes no application should be using egrep or fgrep either.

ssokolow this is a case those who wrote the scripts that are broken by egrep or fgrep being removed need to take responsibility for not being standard conforming.

This is the problem here. People have kept on using egrep and fgrep in scripts after the Posix standard told them clearly not to. egrep and fgrep should have been moved out to their own package at least a decade ago. Yes so that egrep and fgrep being used when they should not have been could have been clearly detectable.

Again, I don't care how it's achieved. I'm talking about, as an end-user, the observed effect. Windows manages to achieve best-in-class backwards compatibility while Linux does not... which leads platform developers to try to justify the status quo and The Year of the Linux Desktop™ to not come because users look and say "All I know is that, from where I'm standing, Microsoft did what I need and you didn't, so I'll go with Microsoft".

https://github.com/lutris/asgard/
No ssokolow you care how it's achieved. Person using lutris on Linux can have quite a simple time installing lots of the old Loki games due to the above project. Why the provide a legacy runtime. Steam store has a lot of really old Linux native games that work. Guess what steam runtime for compatibility.

Does Linux technically have best in class backwards compatibility yes Linux does. The difference here Windows has a single interface for multi runtime support being SXS and Linux has multi options. There is a lack of agreement here, valve, lutris and many others have not come to agreement on single system to have something like SXS on Linux.

Something to remember the Linux kernel in 64 bit mode still supports 16 bit protected mode for win16 applications. The 64 bit Linux kernel has more backward compatibility than 64 bit Windows kernel like it or not. Linux user space is able to be massive backwards compatible.

Linux best in class backwards compatibility when you get the applications to work but with the worst interface majority of this caused by different parties coming up with completely different ways to solve the multi runtime issue. Windows has really decent interface due to how SXS works and having a single agree on system for multi runtimes but its backwards compatibility for the running applications is slightly worse as in more applications that refuse to run due to features changes at kernel level.

ssokolow funny right that Windows technically has second best backwards compatibility when you compare to how well the old legacy applications run to how they should have run. This is something people would not give Linux first place for. Most people looking at how much effort is required to run legacy applications not how well those applications in fact work after you put in the effort.

Funny right Linux has massive effort to get legacy applications to work but then able to run them perfectly. Windows has massively reduced effort to get legacy applications to work but those applications have minor to major issues in their functionality. Some of the reason why Valve started looking at Linux in the first place is they were getting quite sick of having to do refunds to windows users who would install old game and find out that the game had glitches due to the limitations of the windows backwards compatibility solution.

ssokolow the reality here if you did not care how it was achieved you would not care about the amount of effort you would put in on Linux to get as close to perfect backwards compatibility with application as possible so it matches it historic behavior as close as possible. You really do care how backwards compatibility is achieved you want user simple right not perfection? Perfection end up with a stack of adjustable things.

[coder]

No its not, thats called absense of evidence.

It would be "absence of evidence" if the statements were well-founded. When given the opportunity to cite sources, he failed to do so. Therefore, it can be treated only as noise.

You clearly have no idea how history works. In a lot of cases there is zero or little evidence, and in those cases historians we say "we cannot absolutely prove this is what happened, but because x and y and z occurred there are some plausible theories as to what happened".

There's never zero evidence, if they're doing their job properly. Even when addressing a gap in historical records, historians are operating on the basis of a set of preconditions, post-conditions, cultural, and contextual information, in order to form one or more conjectures about what happened during the gap. However, such conjectures are only acceptable after exhausting all feasible avenues to find actual sources (even unreliable ones, which can sometimes still be useful).

You clearly have no idea how history works.

Sorry, but no one cares what you are interested in.

You replied to me, so you clearly do. If you don't then drop it.

If you don't want to participate in the discussion because people cannot provide 100% hard evidence

That's a false dichotomy. There was no attempt to backup the historical claims, whatsoever. To make such a statement shows you're being disingenuous.

And I can absolutely participate in a discussion without humoring needless flights of fancy or equivocations. You don't get to dictate the terms of my participation.

You should probably do the same and take a chill pill before you get thrombosis or something.

Thanks for your concern about my health. I am, in fact, chill.

Sorry to burst your black and white naive world view, but a lot of things are made based of assumptions due to lack of complete evidence. You may not like it, thats fine, but people do this and its useful to do so because there isn't a 100% accurate recollection of all events in history.

You misunderstand the issue.

The problem with what you're doing is that you see a narrative that sounds plausible and want to explore it. That would be fine, if you were diligent about investigating the historical record and seeing where the facts lead. However, to take an unsupported statement of fact, and then further expound upon it just fills the internet with more misinformation. And your statements weren't couched as naked conjecture, but rather as a defense of (as far as we can tell) baseless claims.

We should be striving to increase the signal to noise ratio, which is accomplished by either increasing signal or decreasing noise. In this case signal represents historical fact, and noise represents historical fiction. Historical facts aren't 100% knowable, but we can get pretty close, most of the time, through diligent attempts to find utilize multiple sources. There can never be 100% signal and zero noise, but that's not a reason to throw up our hands and stop trying.

Noise is increased by people making unfounded statements and riffing on each other, based on what sounds good to them. That's conspiracy theory shit.

I am just stating that what Luke_Wolf said is plausible based on the evidence.

What evidence?

I don't have any real motives or objectives apart from engaging in a discussion for exchange/debate of information.

That's intellectually sloppy. If you don't mind putting out noise into the world, that's up to you. If you actually care about increasing information, then you need to be more diligent.

The f**k you think this is, some kind of holy war or some political party debate?

I think you're too smart to be this sloppy. Some people on this forum I've come to accept are basically hopeless, but I know you're better than this.

And to be clear I am not defending Luke_Wolf, he obviously was overconfident in what he was stating

He made a cascade of bad inferences and conclusions, based on an incorrect diagnosis of his problem. That's understandable. We were all noobs, once. One reason I challenged him was in the hope that he digs deeper, next time. Also, I hope he won't continue to spread so much misinformation about pipes sucking and streams being an anachronism.

but his conclusion on that specific point isn't entirely stupid either.

Most misinformation and pseudoscience has an air of reasonability about it. It's really setting the bar too low.

He may have said some other stupid stuff which I can't comment on (which is why I didn't), but then again everyone has said stupid shit so if you are going to dismiss him on that we shouldn't be selective about it

His initial post made two basic claims, which I challenged separately. He opted to mount a defense only on the second point, which was about stdout redirects. I did not prejudice one based on the other. I was prepared to discuss each, separately.