回答:
cronを使用するのは、より良い標準的な方法であるためです。少なくとも、これが定期的に実行されるものであれば（1分以内にパッチを当てたものだけではありません）。cronよりクリーンで標準的な方法です。また、ターミナルから切り離されたシェルを実行するため、より良いです-偶発的な終了や他のプロセスへの依存関係の問題はありません。
リソースについて：CPU：両方のプロセスがスリープします-スリープすると、CPUを浪費しません。cron物事をチェックするために頻繁に目覚めますが、とにかくそれを行います（あなたのプロセスのためにこれ以上はありません）。そして、これはごくわずかな負荷であり、ほとんどのデーモンは時々起動します。メモリー：cronこのプロセスに関係なく実行されている可能性が高いため、オーバーヘッドはまったくありません。ただし、cronはスクリプトが呼び出されたときにのみシェルを開始しますが、スクリプトはメモリに読み込まれたままです（シェル変数ですべてを読み込む場合を除き、環境でのbashプロセス-数キロバイト）。
全体として、リソースについては重要ではありません。
既にいくつかの良い回答cronとsleepパフォーマンスがありますが、何らかの機能比較を追加したいと思います。
プロcron：
プロsleep：
cronはある種のトリガーまたは他のトリガーよりも効率的なトリガーを使用しますか？
私は見てきたcat /proc/`pidof crond`/stack。数回連続して印刷したのでcrond、hrtimer_nanosleepでスリープしているだけです。
>cat /proc/`pidof crond`/stack
[<ffffffff810a0614>] hrtimer_nanosleep+0xc4/0x180
[<ffffffff810a073e>] sys_nanosleep+0x6e/0x80
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffffsleep ユーティリティは同じシステムコールを使用します。
>sleep 100 &
[1] 12761
>cat /proc/12761/stack
[<ffffffff810a0614>] hrtimer_nanosleep+0xc4/0x180
[<ffffffff810a073e>] sys_nanosleep+0x6e/0x80
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff私は両方のユーティリティ（crond＆sleep）のCPU使用率が低くなければならないと仮定し、模倣cronする必要がある場合は明確に使用できますsleep。
更新。crondの活動を観察することをお勧めします
strace -p `pidof crond`探している主な違いは、cron常に実行されていないことです。で説明したようにman cron：
cron then wakes up every minute, examining all stored crontabs, check‐
ing each command to see if it should be run in the current minute.
When executing commands, any output is mailed to the owner of the
crontab (or to the user named in the MAILTO environment variable in the
crontab, if such exists). The children copies of cron running these
processes have their name coerced to uppercase, as will be seen in the
syslog and ps output.つまり、cron1分間に1回だけ起動され、実行する必要があるかどうかをテストします。一方、スリープアプローチでは、実際のsleepコマンド、シェル、ターミナル、およびwhile（または何でも）ループを同時に実行する必要があります。
同じ数のプロセスを起動していたとしても、cronより良いでしょう。これは、仕事に非常に優れている傾向のある人々によって正確に書かれています。単純なシェルループよりも優れた仕事をすることになっています。
違いは、スリープする必要のあるスクリプトを追加すると、スリープ状態になり、次の実行まで閉じられるスケジュールされたスクリプトを起動して実行する単一のプロセス（cron）ではなく、待機するプロセスが増えることです。Cronは、他のスクリプトを時間どおりに実行することに特化した1つのプロセスを許可します。さらに、cronは、何かを実行する時間、曜日または月、特定の時間、または5分ごとなどを比較的自由にスケジュールできます
*これをもう一度見ただけで、cronのもう1つの利点が思い浮かびました。定期的に実行されるすべてのスクリプトは1つの場所にあり、いつ、どのくらいの頻度で実行されるかをそこから簡単に確認できます。それ以外の場合は、個々のスクリプトを確認する必要があります。
既に十分な情報に基づいた回答がありsleepますが、を使用すると、たとえば他の変数の関数として、さまざまな時間プロセスをフリーズすることができます。
残っているバッテリーの割合を確認するスクリプトを作成していて、notify-send事前に定義されたクリティカルレベルを下回っている場合sleep、バッテリーを毎回確認する代わりに、現在のバッテリーレベルの関数である時間の割合でスクリプトを作成できます最後にチェックしたときに80％だったとわかっていても、cronを使用して1〜2分。
Battery_notify.sh
#!/bin/bash
CRIT=15
while true; do
# current battery level
BAT_LEVEL=`acpi -b |grep -Eo "[0-9]+%"|grep -Eo "[0-9]+"`
interval=$((($BAT_LEVEL -$CRIT) * 120)) # loose estimate of backup time for each percentage of battery charge.
# Is AC plugged in?
state=`acpi -b |grep -Eo "[A-Za-z]+harging"`
#only notify if not Plugged in
if [ "$state" = "Discharging" ] ; then
# is battery below CRIT level?
if [ $BAT_LEVEL -le $CRIT ]; then
aplay ~/apert.wav &
notify-send "Battery-Low!!!" -i /home/bibek/batt.png -t 900
sleep 100 # nag me each 100 secs untill I plug the thing
else
sleep $interval
fi
else
# if plugged in sleep
if [ $BAT_LEVEL -le $CRIT ]; then
sleep $interval
else
# to check if the AC is unplugged before battery gains charge above CRIT.
sleep 100
fi
fi
done