7 ms·

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 -ty

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.

adwn 7y ago
> 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 https://en.wikipedia.org/wiki/No_true_Scotsman
- robohoe 7y ago
  This is why Unix is great. It gives you enough tools to shoot yourself in the foot.
  - yjftsjthsd-h 7y ago
    "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things."
  - deleted 7y ago
    [deleted]
- Annatar 7y ago
  "What now, are you claiming that's not "real fgrep"? GNU stands for GNU is not UNIX®️.
pjc50 7y ago
.. 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.)
- sxldier 7y ago
  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_.2A.mp3.29 https://mywiki.wooledge.org/BashPitfalls#for_f_in_.24.28ls_....
- felixfbecker 7y ago
  And that’s why PowerShell is awesome :)
  - pjc50 7y ago
    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.
    - majkinetor 7y ago
      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/a14b1e5bfaf70839b338eb1ab7f8226f https://gist.github.com/choco-bot/a14b1e5bfaf70839b338eb1ab7...
adrianN 7y ago
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.

adwn 7y ago

> 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 https://en.wikipedia.org/wiki/No_true_Scotsman

robohoe 7y ago
This is why Unix is great. It gives you enough tools to shoot yourself in the foot.
- yjftsjthsd-h 7y ago
  "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things."
- deleted 7y ago
  [deleted]
Annatar 7y ago
"What now, are you claiming that's not "real fgrep"? GNU stands for GNU is not UNIX®️.

pjc50 7y ago

.. 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.)

sxldier 7y ago
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_.2A.mp3.29 https://mywiki.wooledge.org/BashPitfalls#for_f_in_.24.28ls_....
felixfbecker 7y ago
And that’s why PowerShell is awesome :)
- pjc50 7y ago
  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.
  - majkinetor 7y ago
    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/a14b1e5bfaf70839b338eb1ab7f8226f https://gist.github.com/choco-bot/a14b1e5bfaf70839b338eb1ab7...

adrianN 7y ago

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.