Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We are stuck with egrep and fgrep (unless you like beating people)

utcc.utoronto.ca

Post reply on HN
Print view View original

271–280 of 354 posts

Re: We are stuck with egrep and fgrep (unless you like beating people)

#271

Post by kazinator »

radford-neal wrote: post #107

I use fgrep all the time. Why should I spend time converting scripts, and retraining my fingers, and forever after taking longer to type grep -F? This is a breaking change that has no upside, only downside. It is idiocy. Just to elaborate, there must be many thousands (hundreds of thousands? millions?) of shell scripts out there that use fgrep. For no reason at all (whatever maintenance burden fgrep represents must b…

If your reason for using fgrep is that grep -F is more characters longer, the logical thing would be to have your own function or alias which is called just f or fg.

I stopped using egrep and fgrep in scripts ~25 years ago when I found out they weren't in the standard.

grep -F is only useful when the pattern contains regex characters that should be treated literally, and since the default regex language of grep is BRE, those characters are few.

If only one special character occurs you break even on character count if you use a backslash escape:

  fgrep 'a*c'
  grep 'a\*c'

Re: We are stuck with egrep and fgrep (unless you like beating people)

#272

Post by 3pt14159 »

acdha wrote: post #171
3pt14159 wrote: post #70

Earlier quoted context omitted.

The problem is that we don't just live on our own machines. We hop around to different boxes and just being able to type what you are used to matters. My dotfiles and other tools don't go or even work everywhere. We shouldn't change the oldest parts of our OSes without a really good reason.

I find this reasoning interesting since it's why I _stopped_ using egrep/fgrep around the turn of the century: because those aren't standard, it wasn't uncommon to find that you depended on some behaviour which wasn't available in the version installed on some random server but it worked when you used grep.

I switched to just grep, but it's still part of the same line of thinking. I really, really, really dislike it when something that used to be reliable changes or is removed. I understand and accept that things change, but when it's as simple as a symlink or what have you I really do not see the cost-benefit tradeoff for sunsetting something.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#273

Post by cryptonector »

hnlmorg wrote: post #265
cryptonector wrote: post #249

Earlier quoted context omitted.

Switching behavior according to argv[0] been used in Unix for decades. mv(1)/ln(1)/cp(1) historically are the same program, hardlinked.

Wasn’t rm also the same? I vaguely recall it being little more than ‘mv $1 /dev/null’ under the hood. But this might be something I’m misremembering.

Yes. I made a mistake, I think cp(1) was separate.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#274

Post by kazinator »

ComputerGuru wrote: post #71
koprulusector wrote: post #58

I’ve been using grep -E for a long time, I thought I remember it being from a warning from egrep or something.. can’t really remember for sure, though. Either way, I don’t see what the big deal is, just add an alias egrep='grep -E' If you’re worried about your non-interactive shell scripts, shopt -s expand_aliases; alias egrep='grep -E' and you can move on with your life. EDIT: I must’ve been warned by shellcheck EDI…

It’s a matter of principle. If you wrote a script yesterday (or a year ago) and didn’t include that line, you need to re-release it today. That’s stupid. Also, you’re being very sanctimonious about this but what if you didn’t see this HN story. Would you know to do that for the next script you distribute?

fgrep and egrep have been indicated as obsolescent by the Single Unix Specification and POSIX since the late 1980's.

The man page for GNU grep says:

  In addition, the variant programs egrep, fgrep and rgrep are  the  same
  as  grep -E,  grep -F,  and  grep -r, respectively.  These variants are
  deprecated, but are provided for backward compatibility.
"Deprecated" should be read as "maybe ain't gonna be around one day". "Use interactively, or in your personal setup, but don't put into shipping code".

So if you wrote a script yesterday with these things, you're just one of those people who don't look into specs or man pages.

The scripts of coders who don't read documentation are going to tend not to be portable or reliable anyway. That doesn't mean we should break things left and right to trip people up, but in this case the writing has been on the wall for a very long time.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#275

Post by samus »

Taywee wrote: post #258
hinkley wrote: post #235

Earlier quoted context omitted.

Different behavior based on argv[0] was first brought to my attention when I discovered that /bin/sh was a symlink on some Linux systems. Bash has a Bourne shell compatibility mode.

Busybox is the forefront example of this in my mind. Busybox is a single binary that provides a ton of POSIX utilities (including sh, awk, ls, cp, nc, rm, gzip, and about 300 other common ones), and these can be invoked with `busybox $command`, or a symlink may be made from the command name to the `busybox` binary to automatically do the same. Many embedded Linux systems just use busybox and a ton of symlinks to act…

GNU does it their way, and Busybox does their own way too. Both have valid reasons for how things are set up. For users friendlinesr it's important then that they are as consistent as possible with it.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#276

Post by MobiusHorizons »

roenxi wrote: post #12
kevincox wrote: post #2

What problem is this warning trying to solve? Are these two symlinks too much maintenance burden? Or is the check in the code hurting the code quality? Is the extra check at startup ruining performance? I'm usually in favour of having one way to do things but in this case, with this much legacy it just doesn't seem worth it.

This is free software. It is legitimate to consider convenience for the maintainers. If they don't want to maintain two symlinks then they are empowered to make that call. If anyone thinks it is a big enough problem that they want to fork the software they can, or the distros can maintain their own symlinks. But I think in this case the simple answer is if the maintainer doesn't want it in the source tarball then it…

What exactly do you imagine the maintenance being? egrep and fgrep are already shell scripts, and those scripts haven't been edited since 2015. If not needing to change something for 7 years counts as a maintenance burden, sign me up.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#277

Post by tmtvl »

LinuxBender wrote: post #59
Beltalowda wrote: post #22

Earlier quoted context omitted.

I betcha most people didn't even know they were considered "deprecated".

I learned about the deprecation from ShellCheck [1] that warns if using egrep instead of `grep -E`. That tool deprogrammed many of my bad habits. I had never seen any discussions about it otherwise. [1] - https://www.shellcheck.net/

That's a cool tool, it's neat seeing Haskell in the wild.

Unfortunately (or not?) I tend to use actual programming languages to make my tools rather than doing shell scripting, so I don't have anything interesting to put in there, but I'll keep a bookmark of it around.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#278

Post by kps »

hnlmorg wrote: post #146

There seems to be a lot of confusion in this discussion about what the change is and how egrep and fgrep work. These are not symlinks like some have suggested but rather shell scripts. You can see the exact commit diff here: https://git.savannah.gnu.org/gitweb/?p=grep.git;a=blobdiff;f... I remember around ~10 years ago being told "you should never use `egrep` because it is slower than `grep -E`." precisely because th…

> I remember around ~10 years ago being told "you should never use `egrep` because it is slower than `grep -E`."

I remember around 30 years ago reading that egrep was faster (the UNIX versions were entirely separate implementations, egrep of course being newer) and have used it ever since.

Re: We are stuck with egrep and fgrep (unless you like beating people)

#280

Post by fnordpiglet »

hnlmorg wrote: post #146

There seems to be a lot of confusion in this discussion about what the change is and how egrep and fgrep work. These are not symlinks like some have suggested but rather shell scripts. You can see the exact commit diff here: https://git.savannah.gnu.org/gitweb/?p=grep.git;a=blobdiff;f... I remember around ~10 years ago being told "you should never use `egrep` because it is slower than `grep -E`." precisely because th…

I am not sure I agree with the logic. On an absolute instruction count scale grep will often dwarf the instructions necessary for the higher level logic captured in the shell script. Insert appeal to andahls law here. Writing in some more optimal language often requires considerably more work, and if the marginal benefit of reducing a few forks is minuscule compared to grep performance, why would you do this?
Post reply on HN