6 ms·
The blog makes two main points: 1) adding new error messages causes compatibility problems; 2) some people are used to typing "egrep". On the first point the a
by ufo 4y ago
The blog makes two main points: 1) adding new error messages causes compatibility problems; 2) some people are used to typing "egrep".
On the first point the author only gives hypothetical examples. I feel the argument might have been more compelling if we could see some concrete examples of things that break with GNU Grep 3.8.
As for the second point, I find it less convincing than the first one. If it's just the muscle memory then an alias would be an acceptable workaround. And I doubt that "everyone in the world" would want such an alias, as the author suggests.
- airza 4y agoIt seems pretty simple, piping bash commands into other bash commands and other text stream juggling is a pretty typical use of these commands and so changing what stream is output can change the behavior of consumers of the output of these functions. I haven’t done anything with fgrep and egrep before but piping grep into another grep for more complex classes of text search is something i use a lot.
- tuetuopay 4y agoIt's more than likely the warning will be printed to stderr, not out, so there will be no impact on the actual work done.
- mannykannot 4y agoAutomatically monitoring the stderr from cron jobs for unusual outputs is a prudent measure, and its plausible that this change will increase the burden of false positives (it certainly will not reduce it.)
- loloquwowndueo 4y agoBut if you’re monitoring the output it usually means you are in a position to fix problems which means you can likely update the script in question to use the new warning-less invocation.
- mannykannot 4y agoIf I had been woken up in the middle of the night or had a vacation interrupted on account of this, I would not be entertaining warm and grateful thoughts toward whoever thought it was a good idea.
- ziml77 4y agoWouldn't you test before upgrading packages in production? And usually you'd want to schedule any upgrades so that the next day or two has coverage from someone who can deal with any issues that arise.
- 0x0 4y agoWhat if a cron.monthly or cron.weekly script calls egrep? Congrats now you get a lot of noise from cron stderr emails in the distant future.
- bad416f1f5a2 4y agoI have yet to work at a place that didn’t have systems running mission-critical shell scripts with little to no SDLC on boxes that got periodic “yum update -y”s. There seems to be a difference in oversight of software we write & “the operating system”. Should we do better? Absolutely! Will this burn people if vendors don’t take care? Also absolutely!
- guhidalg 4y agoI don't know if I have sympathy for this argument. Your script ostensibly handles (at least logs) errors and warnings right? Do you exhaustively handle every single error and warning in a unique and different way or do you have a catchall "If non-0 return code then fail"? How does introducing new output to stderr affect that?
- P5fRxh5kUvp2th 4y agoIf you're being woken in the middle of the night over this then your testing infrastructure is crap. This is something that should be caught before it gets to that point SPECIFICALLY so you aren't getting woken up in the middle of the night.
- tuetuopay 4y agohence why I wrote "actual work done". your scripts will continue to produce the expected output. the side effects, otoh, will change indeed.
- cesarb 4y agoIt's not unusual in shell scripts to combine stderr with stdout by using "2>&1" or similar.
- int_19h 4y agoIt is, however, very unusual to do so and then try to parse the output. Aside from compilers, what other CLI tools make any guarantees wrt what they print to stderr?
- koprulusector 4y agoCan confirm: $ egrep '.' < <(grep --version) > /dev/null egrep: warning: egrep is obsolescent; using grep -E
- carapace 4y agoThe simple fact that you have to wonder about that question is the failure. Everything about this, even this comment I'm writing right now, is a waste of time.
- mannykannot 4y agoWith regard to the first point, the examples may be hypothetical, but they are also very plausible. When a change has little or no objective benefit, I feel the burden of demonstrating that it is harmless falls on those making the change. As has been pointed out elsewhere, this is free software and the maintainers are free to do whatever they like. That does not stop others having an opinion about it, especially when it is in the form of constructive criticism.
- ufo 4y agoSure, but it would still be nice to have at least one such example. Looking at the rest of the discussion thread here on HN as of now it's still only hypotheticals.
- mannykannot 4y agoIt would be even nicer to see convincing evidence that it is not going to be a problem.
- teddyh 4y agoYou can’t prove a negative.
- mannykannot 4y agoThere is no largest prime.
- teddyh 4y agoUsing that model, we can prove conclusively that, since a behavior has changed (a warning printed), it might cause problems. Therefore, we cannot prove that it cannot cause problems. What we would really like, though, is an actual problem shown to exist. Just like in mathematics; it’s one thing to prove that it’s impossible to prove something could not exist, but another thing entirely to show it existing.
- ajross 4y ago> On the first point the author only gives hypothetical examples I have scripts everywhere, some of them 20 years old or more, that use fgrep. For years and years it was a "best practice" thing if you were checking for a fixed string (so that you didn't accidentally match on a "." or whatever by forgetting it was a regex).
- teddyh 4y agoYou have two options: The first option is to simply replace "fgrep" with "grep -F" everywhere in all your scripts, which is correct but is more work than your other option, which is to add your own "fgrep" script somewhere in your path. Any of these options seem reasonable to me.
- ajross 4y agoOK, are you going to call up all my former employers to tell them to audit the scripts I wrote for them in the late 90's? I really don't think people understand the impact here. It's not it's just a bunch of angry geriatric graybeards yelling at the modern world. It's that there is decades of uncounted, unrecognized, untraceable software written using these old conventions that are suddenly changing. It's just a terrible idea. Linux cares about conforming to syscall interfaces for binaries compiled 20 years ago, but somehow you think it's OK to break scripts that have worked fine for 50 (fifty!) years?
- teddyh 4y agoEither a system is frozen and static, in which case it will not receive this version of GNU grep, and there is no problem. On the other hand, if a system receives updates, the system needs both minor and major changes all the time, to keep up with its ever-changing environment. This is the jungle in which we live. Linux syscalls are important to keep, since it’s hard to change a compiled binary. But it’s easy to change a shell script. And don’t exaggerate. This won’t, in all likelihood, “break” your scripts.
- 4y ago
- cestith 4y agoThe shell happens to be a programming tool and not just an interactive command interpreter. There are whole books on how to write shell scripts portably across various Unix-y platforms. Many of the examples in those books will now throw warnings on systems using the GNU tools.
- bitofhope 4y agoIf a book on writing portable shell scripts across *nix platforms depends on commands not specified by POSIX, I don't think those books are doing their job very well.
- cestith 4y agoPOSIX.2 wasn't a standard until 1992. Perhaps it's the standard at fault for specifying the -E and -F flags rather than specifying the tools that existed in v7 in 1979. Authors and publishers didn't just pause for 13 years to wait and see.