I have just noticed that command line utilities such as ls (/bin/ls), touch (/usr/bin/touch), cat (/bin/cat), etc. are very slow when I run them from Terminal or iTerm on my MacBook. For example:

  • ls'ing while in an empty directory takes 1 second (it also takes 1 second in a non-empty directory, both with lots of files or with a few files);

  • touch'ing a new file takes 1 second (it also takes 1 second to touch an existing file);

  • cat'ing an empty file takes 1 second (there is also a 1 second lag before anything happens when I cat a non-empty file).

I have tried to diagnose this in many ways but to no avail. I do not think this is a filesystem issue, since:

  • I have run Disk Utility and it reports no problems.

  • Everything seems to be working just fine in Finder, e.g. directory contents are shown instantaneously in Finder.

  • I installed GNU coreutils using Homebrew and tried using gls, gtouch, gcat, etc., and all of the operations I listed above happen instantaneously when run with the GNU version instead.

Any ideas on what could be going on? Any ideas on how to fix this?

EDIT: When I reboot the computer, or try a different user, these issues go away temporarily, but after a few minutes they seem to reappear again. Another strange thing that I noticed:

$ time date
Wed Jan 28 10:07:11 PST 2015

real    0m0.151s
user    0m0.001s
sys     0m0.003s

$ time date
Wed Jan 28 10:07:13 PST 2015

real    0m0.029s
user    0m0.001s
sys     0m0.002s

$ time date
Wed Jan 28 10:07:16 PST 2015

real    0m1.005s
user    0m0.001s
sys     0m0.002s

$ time date
Wed Jan 28 10:07:18 PST 2015

real    0m1.005s
user    0m0.001s
sys     0m0.002s

This happens for all the utilities I've tried, mkdir, scp, sftp, more, cat, etc.: The first time I run it after a reboot, it's medium-slow. The second time I run it, it's sorta-fast. All subsequent times I run it, it's slow.

  • 2
    Can you run time ls, time touch foo etc. and copy/paste the result into your question?
    – nohillside
    Commented Jan 28, 2015 at 8:39
  • 2
    @patrix: For all the cases I've listed, the time output is very close to real 0m1.004s, user 0m0.002s, sys 0m0.002s, plus or minus ~0.001s. Commented Jan 28, 2015 at 8:45
  • (Whereas the GNU versions have real around 0m0.004s instead) Commented Jan 28, 2015 at 9:08
  • Does something odd show up in the log (visible through Console.app) when you run these commands? Commented Jan 28, 2015 at 18:46
  • @BartArondson -- Thank you for that suggestion!! It was via the log in Console.app that I was finally able to solve the mystery. Commented Feb 1, 2015 at 10:00

3 Answers 3


I actually figured out the issue today. It was caused by a piece of anti-malware software called Sourcefire AMP (Advanced Malware Protection). All of my issues went away after I disabled/uninstalled it.

I'm guessing that it was doing something like putting a delay on things in /bin, /usr/bin, etc. for "security reasons"... I'm guessing the GNU tools were not delayed because they weren't in the "blacklisted" directories.

  • 3
    Glad you figured it out. Feel free to accept your own answer - it may help others solving the same issue.
    – Scot
    Commented Jan 29, 2015 at 7:49
  • The www.sourcefire.com page isn’t working www.sourcefire.com is currently unable to handle this request. HTTP ERROR 503
    – Kuhan
    Commented Feb 27, 2017 at 4:19

The first thing I would check is that you don't have some odd $PATH - run timings of a file that doesn't exist and one that should be speedy:

Mac:~ bmike$ time /bin/ls /private/xyz
ls: /private/xyz: No such file or directory

real    0m0.004s
user    0m0.001s
sys     0m0.002s

Mac:~ bmike$ time /bin/ls /private/tmp
com.apple.launchd.q2QmVhsPCV    com.apple.launchd.zQ5EK6R6AZ

real    0m0.006s
user    0m0.002s
sys     0m0.003s

The next thing would be to check overall system business:

Mac:~ bmike$ vm_stat 5
Mach Virtual Memory Statistics: (page size of 4096 bytes)
    free   active   specul inactive throttle    wired  prgable   faults     copy    0fill reactive   purged file-backed anonymous cmprssed cmprssor  dcomprs   comprs  pageins  pageout  swapins swapouts
  306160  1168138    79266    53096        0   299239   613825 20971811   345367 15995721      237  2472732      203216   1097284   328691   190541   260034   646113   623838      285   286101   299172 
  305613  1172072    79345    53098        0   295915   618898     1191        1      680        0        0      203297   1101218   328691   190541        0        0        0        0        0        0 
  306163  1188285    79345    53088        0   279370   621180     1055        0      600        0        0      203287   1117431   328682   190541        9        0        0        0        0        0 
  306039  1186031    79345    53088        0   281598   621176      729        0      293        0        0      203287   1115177   328664   190541       18        0        0        0        0        0 
Mac:~ bmike$ iostat 5
          disk0       cpu     load average
    KB/t tps  MB/s  us sy id   1m   5m   15m
   31.31  12  0.35   9  4 86  1.32 1.41 1.43
    0.00   0  0.00   2  2 96  1.21 1.38 1.42
   18.40   1  0.02   5  2 93  1.20 1.38 1.42
   22.00   1  0.02   3  2 95  1.20 1.38 1.42

Then I would quit all applications and log out all users and reboot. If you have your Mac log you in, disable that in the system preferences so you can perform a safe log in after the reboot. (Hold the shift key immediately after pressing return if you type a password to log in to your user or hold shift right after selecting your user icon if you don't have a password.)

Repeat the measurements (and optionally timing the alternate gnu tools) to know if the issue is temporary or systematic.

  • 1
    Also log in as guest or a new user and repeat the timing
    – mmmmmm
    Commented Jan 28, 2015 at 10:23
  • time /bin/ls /non/existent/directory is slow. time /bin/ls /bin is slow. Commented Jan 28, 2015 at 18:06
  • I've updated my question with some more details... Commented Jan 28, 2015 at 18:14

Similar to what @bmike said, your $PATH might have something in it which causes the shell to delay before it finds the command you're trying to run. Besides the date command, time also should be explicitly named on the command line.

Try /usr/bin/time /bin/date and time date a few times in succession to see if there is any difference in the output. If so, then echo $PATH should give you a clue as to what's causing the delay.

  • time is both a shell (bash) built-in and a binary, might be better to stick to one in all cases.
    – nohillside
    Commented Jan 29, 2015 at 5:39
  • Interesting. I thought times was built-in, but not time. I can't make time stop working though, even after trashing my $PATH... so, you're probably correct. Nevertheless, comparing the output of times /bin/date and times date might be the best option overall because times is unambiguous afaict. (Interestingly, time date, times date, and /usr/bin/time date return three differently formatted outputs)
    – Kent
    Commented Jan 29, 2015 at 5:56
  • You can also use type time to find out where a command is coming from :-)
    – nohillside
    Commented Jan 29, 2015 at 8:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .