I created a shell script /usr/local/bin/suspend
with the following content:
#! /bin/sh
# Take an optional delay parameter
if [ "$#" -gt "0" ]; then
sleep "$1"
fi
# Put the system to sleep
dbus-send --system --print-reply --dest="org.freedesktop.Hal" \
/org/freedesktop/Hal/devices/computer \
org.freedesktop.Hal.Device.SystemPowerManagement.Suspend \
int32:0
If I chmod +x
and run the script by invoking it directly (e.g., just typing suspend
or /usr/local/bin/suspend
on the command line), nothing happens and the shell hangs—it doesn't even respond to Ctrl-C; I have to switch to a new shell and kill the bash
process (which has no apparent children).
The script works fine if I invoke it in any of the following ways:
- Using
sh /usr/local/bin/suspend
. - Using
. /usr/local/bin/suspend
. - Renaming it to
suspend.sh
and invoking/usr/local/bin/suspend.sh
(or justsuspend.sh
, since it's in thePATH
).
The last option is fine, but still I wonder: what exactly is wrong with not using the .sh
extension?
suspend
is a bash builtin,and as builtins take precedence, just typing
suspend
would behave exactly as you describe: the shell blocks until you kill it (if youkill -CONT
it, it resumes).That you're seeing this same behavior by invoking it with the path is either an experimental error, or a bug in the shell. I'd suspect the former before the latter.
If you want your command to supercede a builtin, you first have to disable the builtion:
You can then run your command like a normal command. Then, you re-enable the builtin
I'm surprised the builtin is invoked when you call your command with the full path.
To answer your question about the sh extension; it is actually the opposite, you should not be using it.
From #bash on Freenode.net