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

[ssokolow]

That makes absolutely no sense.

It's about "If this compiled/ran yesterday, I want it to work in 5 years if I haven't touched it"... the underlying philosophy of the Rust ecosystem.

[ssokolow]

Static linking brings another set of problems. Thing to remember all your common posix shell scripts support alias option. So removed egrep or fgrep you add line or 2 to the shell script as a lazy fix to redirect to grep command.

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.

Heck, for my "shell scripts" written in Rust, I use the static-linking musl-libc targets so I don't even have to worry about building them on the oldest glibc I may want to copy the binaries over to.

[coder]

I much prefer having:

* Program execution and exit code handling that isn't a giant footgun

Not sure what you mean by that.

What I meant is that shell scripts make it trivial to condition something on whether a or not program succeeds.

* Whitespace/quote handling optimized for code, rather than interactive use (Yes, I'm also one of those people who hates Haskell's currying-based braceless syntax)
* try/except, rather than trap
* Performance not hamstrung by having to fork/exec far too often and repeatedly incur the subprocess's startup overhead (Just today, I rewrote a shell script into Python because invoking flatpak info -m once per package was making it take 6 or 7 seconds. Now, it takes 1 second to start Python and then completes instantly by speaking directly to libflatpak.)
* Support for nested arrays (Another thing the rewrite benefited from. I can do {'from': ['to1', 'to2']} )
* File manipulation that doesn't require cutting together two or three subcommands with their own DSLs.

These points suggest we don't disagree by much. Most of my shell scripts are quite simple and contain almost nothing where someone would think it would be simpler to read or maintain in a different language.

On this point, I believe the authors of The UNIX-HATERS Handbook were correct and shell script is trash for anything longer than three or four lines compared to the languages that were on the horizon when that book was released.

No, that's quite extreme. 30-40 lines isn't a bad length. However, 300-400 lines would be a lot.

As for going from Python to Rust, "if it compiles, it usually Just Works™" is a real thing and I find spending the effort up-front more satisfying.

Yeah, that's definitely one of Python's weaknesses. I wonder if there are some decent static analysis tools for Python.

One nice thing about shell scripts is that you can scrape a series of commands out of your history and throw them into a script, as a starting point for automating something you just did. Or, interactively experiment with commands, as you develop a new script or edit an existing one.

[Mr.Elendig]

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.

This is a non-issue. If you want to use bash, call bash and not sh.

[kylew77]

Or use a more "boring" OS like BSD. The advantage is that it almost never sees this kind of annoying changes. Though a disadvantage is it probably wouldn't ever have convenience wrappers like fgrep and egrep in the first place.

OpenBSD: https://man.openbsd.org/egrep
NetBSD: https://man.netbsd.org/egrep.1
FreeBSD: https://www.freebsd.org/cgi/man.cgi?...t&format=ascii

All 3 leading *BSD OSes seem to have egrep and fgrep.

[ssokolow]

Not sure what you mean by that.

Things like how easy it is to wind up with the wrong value in $? because you didn't sleep well.

What I meant is that shell scripts make it trivial to condition something on whether a or not program succeeds.

subprocess.check_call(['foo', 'bar', 'baz']) in Python if you want an exception or subprocess.call(['foo', 'bar', 'baz']) if you want it to return a numeric exit code without raising an exception on failure. Comes with a convenient cwd=... keyword argument for things like running tar or zip from the desired working directory without changing the host's script's global working directory. You can from subprocess import call or even from subprocess import check_call as c to make it concise.

std:rocess::Command::new("echo").args(["foo", "bar", "baz"]).status()?.success() in Rust. (The ? does a checked exception-esque early return on "failed to exec" and the .success() is a guaranteed-to-be-portable abstraction over how the platform expects programs to signal success/failure on exit. You can use std:rocess::Command; or even write a quick little macro (hygienic and token-based) to condense things further.

For example, something like this if you don't care about distinguishing "couldn't exec" from "returned failure".

...and that's before I start evangelizing things like Serde and Rayon.

No, that's quite extreme. 30-40 lines isn't a bad length. However, 300-400 lines would be a lot.

Fair. One can argue over logical vs. physical lines and I'd be OK saying 10-20.

Yeah, that's definitely one of Python's weaknesses. I wonder if there are some decent static analysis tools for Python.

I have my Vim configured to run Flake8, PyLint, and MyPy (the latter is a Typescript-esque gradual typing validator which relies on Python's built-in support for type annotations, even if it doesn't do anything with them itself), but it's more the dependency ecosystem that gets to me.

With Rust, once a dependency is on Crates.io, that version can't change and, if the dependency is in your Cargo.lock (auto-generated as part of normal operation), then you'll still be able to download that version even if the upstream developers yank it. It takes direct intervention by the Crates.io admins to remove a crate entirely, and that's reserved for things like "this crate is distributing copyrighted materials that the author doesn't have a license to distribute". Likewise, the language itself has very high standards for "if it built today, it'll build tomorrow". Standards that Python doesn't meet with things like their plans to remove the deprecated asyncore module from the standard library in 3.12.

[kpedersen]

All 3 leading *BSD OSes seem to have egrep and fgrep.

Good spot. I had a look into this and it does indeed go a bit deeper.

fgrep, egrep were removed from POSIX 2017 (https://pubs.opengroup.org/onlinepub...cu_chap04.html)

The justification seems to be:

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.

I was going to suggest that at least BSD guys won't need to worry about their removal. They are in there for good. However, POSIX 2017 is SUSv4 (Although the BSDs mostly follow SUS, it tends to be an older spec). Sooo ultimately the future can't be predicted in this case.

[ssokolow]

This is a non-issue. If you want to use bash, call bash and not sh.

1. At best, it's bad form to have your rcfiles modify how non-interactive shells behave before you hit the "Is this interactive?" guard. At worst, they don't get sourced at all.
2. I'm talking about scripts written by other people which break unexpectedly... possibly part-way through changing things because who is diligent enough to check for the existence of stuff that was POSIX standard at the time the script was written before starting to do work?

[rclark]

Anything more than doing a few inline commands in a bash script (like calling rsync repeatedly for example), I just write it in python. Much more intuitive (and readable) than bash syntax for anything more complex than that. Also just as flexible as the source is the executable (Rust, or C, or any compiled language doesn't meet this criteria). One of things I did in Windows land for my company, it convert all the batch files calling vb scripts in excel and such to python. Greatly simplified the processes as all in one place. And 'much' more maintainable (and turns out more reliable too).

[ATLief]

Ikr, why not just set an alias in bashrc? Seems so much simpler

If you’re going for the same portability as shell scripts, you should really be using /etc/profile(.d/custom) so that it’ll also work in other Bourne-based shells like Zsh.

But shell aliases have a major drawback: they won’t work in scripts by default (because scripts don’t automatically expand aliases). And I bet a lot of scripts use egrep and fgrep. If you want things to work seamlessly as they did before, you’re stuck making clunky wrapper scripts.

Really there should just be symlinks to grep and have it check $0 like systemctl does with shutdown and reboot. But that might be too practical for GNU.