preach!
We are stuck with egrep and fgrep (unless you like beating people)
311–320 of 354 posts
Re: We are stuck with egrep and fgrep (unless you like beating people)
#312Re: We are stuck with egrep and fgrep (unless you like beating people)
#313I'm so confused by this change. fgrep and egrep are already just shell scripts that are almost just like aliasing grep -E and grep -F. Why is the GNU team suddenly so worried about these shell scripts?
If the maintenance of these scripts is so hard. They could just deprecate them entirely. It's pretty unlikely that they would stop working or become insecure anytime soon. And sysadmins would just source in the aliases into their shell environments anyway....
Re: We are stuck with egrep and fgrep (unless you like beating people)
#314> typing 'grep -F' is two more characters, one of them shifted
Adding in more special characters is also hostile to users who aren't based in a single English-speaking country and regularly have to deal with different keyboard layouts.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#315Earlier quoted context omitted.
It does output to STDERR an extra warning.
But that doesn't actually break your script, because backticks only capture stdout.
But it changes the behavior of the script in the UI. It can cause things like cron to send mail. It can cause other things wrapped around the script that are capturing both STDOUT and STDERR from the script to capture extra content. Any tool that's monitoring STDERR and expecting it to be empty may consider that an erroneous run, which may impact other scripted decisions. It's a breaking change in multiple circumstances, even if you don't consider extraneous warnings shown to a user manually running a script a breaking change.
Does that code look like something you'd log into a system and manually run on a regular basis? Does it maybe instead look like one layer of a legacy automation stack absorbed into other tools?
Re: We are stuck with egrep and fgrep (unless you like beating people)
#316GNU Grep manpage says: 7th Edition Unix had commands egrep and fgrep that were the counterparts of the modern ‘grep -E’ and ‘grep -F’. Although breaking up grep into three programs was perhaps useful on the small computers of the 1970s, egrep and fgrep were not standardized by POSIX and are no longer needed. In the current GNU implementation, egrep and fgrep issue a warning and then act like their modern counterparts…
somehow the opengroup removed egrep and fgrep from POSIX in 2018
https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu...
chroot, usefull for poor man's containment of 'stuff' also went out.
and they replaced tar with pax --- which uses a tar file format
one of the things I love in Unix is the slow pace of evolution in systems tools. relevant know how doesn't rot as fast as in other environments.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#317While we are discussing common command aliases, could we decide to make ll (= ls -l) a standard one? I have a hard time using a shell without it, and it's annoying to create the alias on all the machines I ssh to ^^
Re: We are stuck with egrep and fgrep (unless you like beating people)
#318Earlier quoted context omitted.
Bash actually has a POSIX compatibility mode. There is a great deal in POSIX that was not in Bourne, native arithmetic expressions being the first to come to mind, then new-style command substitution. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... All of the POSIX utility standards, including the grep variants, can be found in the URL's parent directory: https://pubs.opengroup.org/onlinepubs/96999197…
> Bash actually has a POSIX compatibility mode. It's partial. A short example is `date&>FILE`. [edited typo] On a POSIX shell, `date` will run in the background and the date will be written to stdout (`date&`) and `FILE` will be created or truncated (`>FILE`). Using `bash --posix`, the date will be written to `FILE`, since the incompatible bashism `&>` still takes priority.
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.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#319I got this obnoxious whine from egrep on FreeBSD after my latest update. This post made me look, and I had gnu grep install as a dependency for something. Once I removed it, sanity is back and the built-in BSD egrep doesn't whine. On FreeBSD, they are all the same: $ ls -li /usr/bin/egrep /usr/bin/fgrep /usr/bin/grep /usr/bin/rgrep 281835 -r-xr-xr-x 4 root wheel 30736 Sep 26 14:37 /usr/bin/egrep 281835 -r-xr-xr-x 4 r…
Thanks for sharing. I feel less silly for suggesting this now (as root): unalias grep && unalias egrep && cp "$(command -v grep)" "$(dirname "$(command -v grep)")/egrep
why no hard link?
Re: We are stuck with egrep and fgrep (unless you like beating people)
#320Earlier quoted context omitted.
> Bash actually has a POSIX compatibility mode. It's partial. A short example is `date&>FILE`. [edited typo] On a POSIX shell, `date` will run in the background and the date will be written to stdout (`date&`) and `FILE` will be created or truncated (`>FILE`). Using `bash --posix`, the date will be written to `FILE`, since the incompatible bashism `&>` still takes priority.
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.