Hacker News Reader

Comment by Annatar | Hacker News Reader

Real fgrep does not implement -r because that would be implementing tools within tools, which is against the UNIX®️ philosophy.

Try

/usr/bin/find . -depth -type f -print | /usr/bin/xargs -i /usr/bin/fgrep string '{}'

and run it several times so that the filesystem cache is primed.

View on HN

> Real fgrep does not implement -r

That's BS. The fgrep on my system – GNU grep 3.1 – provides recursive search (-r). What now, are you claiming that's not "real fgrep"? [1]

> that would be implementing tools within tools, which is against the UNIX®️ philosophy

Even more BS. Or are you telling me that "rm -r" is also against the "UNIX philosophy"?

> /usr/bin/find . -depth -type f -print | /usr/bin/xargs -i /usr/bin/fgrep string '{}'

Terrible, terrible advice. Cumbersome, error-prone, and slow as molasses. A quick test: Searching for 'asdfadsgf' in the Linux kernel repository takes 0.25 s using rg, 12 s using GNU fgrep -f, and 228 s (!) using your command.

You know, when your ideology results in the worst results of all, you should really reconsider your ideology.

[1] https://en.wikipedia.org/wiki/No_true_Scotsman

This is why Unix is great. It gives you enough tools to shoot yourself in the foot.

"Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things."

"What now, are you claiming that's not "real fgrep"?

GNU stands for GNU is not UNIX®️.

.. which falls over as soon as you have a file with a space in the name.

Edit: this highlights the big weakness in the "UNIX philosophy", in which the only record delimiter that's conventionally recognized in pipelines is the newline but the shell recognizes characters as filename delimiters that are also allowed in filenames. Causing a cascade of delimiter bugs. Sometimes you really do need a bit more structure to your data.

(The UNIX philosophy is best understood in contrast to what went before - the COBOL or JCL style where files had fixed records, in turn based on fixed-column punchcard layouts.)

It's easy to unsafely handle filenames. I've seen it at my job where we do a lot of bash scripting. However, there are good guides on doing it the right way. [0]

[0] https://mywiki.wooledge.org/BashPitfalls#for_f_in_.24.28ls_....

And that’s why PowerShell is awesome :)

Powershell falls over in the other direction: the objects flowing down the pipeline are "magic" and can't be serialised, or even necessarily inspected with normal tools. For most unix operations you can replace

    foo | sort

with

    foo > file
    sort < file

I like the idea of powershell, but every time I try to do something complicated with it I'm disappointed.

That is some serious BS. Objects can be serialized easily.

    $WhateverObject | Export-CliXml
    $WhateverObject = Import-CliXml whatever.xml

Most of the time `>` also work.

By the way, PowerShell serialization is by orders of magnitude better then anything *nix has to offer as you can use objects from other machine shell just like they exist on your local one.

> I like the idea of powershell, but every time I try to do something complicated with it I'm disappointed.

I did some very complicated things in PowerShell. For example, check out the script that maintains ~300 mainstream packages on Chocolatey up to date, all in few minutes with bunch of self maintenance features.

You need to learn it, simple as that.

https://gist.github.com/choco-bot/a14b1e5bfaf70839b338eb1ab7...

I suppose this is a good demonstration of the best way of getting a right answer being to post a wrong one, as I spent a long time trying to work out how to do this last time I needed it.

> .. which falls over as soon as you have a file with a space in the name.

Yeah, spaces are nasty. find has -print0 and xargs has -0 to handle this gracefully, but one needs to know to use it.

-print0 is a GNUism and isn't portable. As stated previously, replacing '{}' with "{}" will handle spaces and most metacharacters just fine.

All you have to do is replace the single with double quotation marks and my commands will handle spaces just fine.

rg searches my repo in under a second. Your command takes over a minute, with a warm cache. It also takes thirty seconds to type. And it doesn't work for files with a space in them. Even on single files rg is faster for me than fgrep. For example my tags file is 2GB large. rg takes 0.4 seconds to search it, fgrep takes 0.6 seconds.

Reply on news.ycombinator.com