Originally posted by coder
View Post
Announcement
Collapse
No announcement yet.
It's Past Time To Stop Using egrep & fgrep Commands, Per GNU grep 3.8
Collapse
X
-
- Likes 1
-
Originally posted by ssokolow View PostOf 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.
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
Code:alias egrep='grep -E' alias fgrep='grep -F'
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.
Comment
-
Originally posted by ssokolow View PostFunny 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".
- Likes 1
Comment
-
Originally posted by ssokolow View PostIf 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.Last edited by coder; 05 September 2022, 10:32 PM.
- Likes 1
Comment
-
Originally posted by coder View PostSource?- Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
- 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.
- 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.
- 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.
- 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.
- Likes 7
Comment
-
Originally posted by coder View PostInteresting, 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.
- Likes 2
Comment
-
Originally posted by oiaohm View PostThis 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.
Comment
-
Originally posted by coder View PostInteresting, 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 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.Last edited by mdedetrich; 06 September 2022, 07:19 AM.
Comment
-
Originally posted by mdedetrich View PostSure, 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.
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.
- Likes 2
Comment
-
Originally posted by ssokolow View PostThat'd work too. As long as it's not my responsibility to dig around and reverse API breakages.
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.
Comment
Comment