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

[ssokolow]

You made a specific, historical claim that:

the ... "many small programs that communicate over stdin/stdout with pipes in between" ... idea ... arose at the time because C was difficult to link to libraries.

Please cite at least one good source on that, or don't pull such BS out of your ass.

If it helps, Computerphile had an interview with Brian Kernighan as part of the series of UNIX specials (I think it was this one) where, as I remember, he got asked about shell pipelines and his characterization of it was more a "Hey, do you think we could do this to avoid the awkwardness of using temporary files for intermediate steps?" followed by a weekend of people getting really excited about finding new things they could do with such a low-friction, ad-hoc way to make one-shot/throwaway mixes of functionality.

[oiaohm]

Of course I could do that but, last I checked, the copy of dash symlinked to /bin/sh doesn't execute .bashrc to pick up those aliases. This is about API breakage and the Linux ecosystem's epidemic of platform API instability.

Wrong file correct file is. /etc/profile or ~/.profile

https://bash.cyberciti.biz/guide//etc/profile

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/alias.html

The reality here is the alias command and /etc/profile and ~/.profile are all part of the posix standard for a posix shell to support. Yes /etc/profile add

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

and you have done it globally for all posix shells. Yes this change is worth doing even if you still have the shell scripts for egrep and fgrep because this removed overhead of shell when you do egrep/fgrep from a posix shell.

Alias works with dash. The problem here you just did a bashish instead of generic posix solution.

I don't know how many distributions support /etc/profile.d/. Yes create /etc/profile.d/grep.sh put the two lines of alias in it and you are done. Yes no #! at start..

This is why I ask the question do any program that are not shell in fact use egrep and fgrep. Maybe instead of making up shell scripts for egrep and fgrep all that should happen is a grep.sh be added to /etc/profile.d directory with two alias.

[coder]

Funny thing about that. The original formulation of the UNIX philosophy says nothing about shell pipes or line-oriented plaintext formats. It just says "Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input."

That applies equally well to things like "Provide a --json flag or equivalent" and "Don't write GUI-only tools". Fundamentally, it's just about "be as accomodating as possible to people who want to automate/compose their tooling".

Source?

[coder]

If it helps, Computerphile had an interview with Brian Kernighan as part of the series of UNIX specials (I think it was this one) where, as I remember, he got asked about shell pipelines and his characterization of it was more a "Hey, do you think we could do this to avoid the awkwardness of using temporary files for intermediate steps?" followed by a weekend of people getting really excited about finding new things they could do with such a low-friction, ad-hoc way to make one-shot/throwaway mixes of functionality.

Interesting, but lots of good ideas were stumbled upon in a somewhat happenstance way. Usually, you can tell which are the good ideas, because they tend to stick around and get used, imitated, & extended.

[ssokolow]

Source?

1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

-- Bell System Technical Journal 57: 6. July-August 1978: UNIX Time-Sharing System: Forward. (McIlroy, M.D.; Pinson, E.N.; Tague, B.A.) p.4-5

• Write programs that do one thing and do it well.
• Write programs to work together.
• Write programs to handle text streams, because that is a universal interface.

-- Peter H. Salus, A Quarter-Century of Unix (1994) (ISBN-10: 0-201-54777-5) as quoted by Wikipedia.

[ssokolow]

Interesting, but lots of good ideas were stumbled upon in a somewhat happenstance way. Usually, you can tell which are the good ideas, because they tend to stick around and get used, imitated, & extended.

I'm not sure what the "but" is in response to. I was just giving some context.

[ssokolow]

This is why I ask the question do any program that are not shell in fact use egrep and fgrep. Maybe instead of making up shell scripts for egrep and fgrep all that should happen is a grep.sh be added to /etc/profile.d directory with two alias.

That'd work too. As long as it's not my responsibility to dig around and reverse API breakages.

[mdedetrich]

Interesting, but lots of good ideas were stumbled upon in a somewhat happenstance way. Usually, you can tell which are the good ideas, because they tend to stick around and get used, imitated, & extended.

Sure, but looking at it both historically and logically Luke_Wolf has a point, without a shell the whole "piping of one programs output into another programs input" would be very painful for both design and technical reasons in pure C for smaller "programs" and it is true that at that point in time linking in C was extremely primitive compared to today.

I also don't have a source to back up the claim, but if you can imagine what C was like back then then its not at all surprising if the reasoning back then was some deviation of this.

[coder]

Sure, but looking at it both historically and logically Luke_Wolf has a point, without a shell the whole "piping of one programs output into another programs input" would be very painful for both design and technical reasons in pure C for smaller "programs" and it is true that at that point in time linking in C was extremely primitive compared to today.

I also don't have a source to back up the claim, but if you can imagine what C was like back then then its not at all surprising if the reasoning back then was some deviation of this.

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

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.

[oiaohm]

That'd work too. As long as it's not my responsibility to dig around and reverse API breakages.

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. The unalias command allows removal of existing alias. So if fgrep and egrep only exist as alias a script developer wanting to find where fgrep or egrep has been used that is not ideal performance could just run unalias command to make it break if the alias route is taken.

I keep on asking this question:
Do any program that are not shell in fact use egrep and fgrep?

The reality here is when you look at the options todo egrep/fgrep
1) full binary this was removed 5+ years ago because it make no practical sense but was that way for over a decade.
2) shell script for egrep and fgrep this is how it has been for 5+ years but this has a shell instance overhead.
3) Use alias
4) don't support egrep and fgrep at all.

Of course alias options don't have to be part of the main package. Yes declaring alias do have performance cost but less than using extra shell instances.

Please also note the fine point here by posix standard using an alias is not using a command. So it might be time to stop using fgrep and egrep commands to move over to fgrep and egrep aliases.

So some of the upset here is part of the differences in language meanings.