How to run /sbin or /usr/sbin native command

I've created a script with various switches for managing sqm. The script works fine when called like:
/usr/sbin/sqm -d ...or... /usr/sbin/test -d

But the script does nothing when called like:
sqm -d ...or... test -d

I've tried /sbin and /usr/sbin. Does anyone know what's missing for this to work?

Thank you

What is your path?
echo $PATH

1 Like

echo $PATH output shows:

Should work.
Verify with which sqm

1 Like

I've called it various names and rebooted. None work
Whats odd is that it knows the command is there otherwise it would respond:
-ash: example: not found

What does which sqm say?
What is the content of the file?

1 Like

Here's what's happening:

root@OpenWrt:~# test -d
root@OpenWrt:~# /sbin/test -d

 -disabling cake qos & wifi
1 Like

File contents are just bash script.

While ... do
and various functions

root@OpenWrt:~# which test

What is the content of the file?

1 Like

There is already a file named test in /usr/bin which has higher priority in the path.
Other than that I added a couple of echos in the beginning of your file and it was printed fine when calling it without full path.

echo "test"
usage="$(basename "$0") -- enable cake layer sqm qos
1 Like

Ok cool thanks. I'll try persist with it a bit further.
Thanks for confirming it works.

Edit: I renamed it 'cake' and now it works fine. Thanks @trendy


It's best to use type to identify the command, because which may return incorrect result:

# which test

# type test
test is a shell builtin

The binary and the shell builtin may have different version and support different syntax.

Thanks @vgaetera that works better.

I ended up finding it hiding in /rom/usr/bin/test

Looks like my bad luck choosing names that were already in use.

Thanks again guys

1 Like

If you need to run a BusyBox applet, there's a simpler way:

busybox test

This allows to call applets even without symlinks.

See also: Limit BusyBox applets to /bin and /sbin

1 Like
root@magiatiko:[~]#la /usr/bin/t*
lrwxrwxrwx    1 root     root          17 Jun 30 10:34 /usr/bin/tail -> ../../bin/busybox
lrwxrwxrwx    1 root     root          17 Jun 30 10:34 /usr/bin/tee -> ../../bin/busybox
lrwxrwxrwx    1 root     root          17 Jun 30 10:34 /usr/bin/test -> ../../bin/busybox
lrwxrwxrwx    1 root     root          17 Jun 30 10:34 /usr/bin/time -> ../../bin/busybox
lrwxrwxrwx    1 root     root          17 Jun 30 10:34 /usr/bin/top -> ../../bin/busybox
lrwxrwxrwx    1 root     root          17 Jun 30 10:34 /usr/bin/tr -> ../../bin/busybox
-rwxr-xr-x    1 root     root       48.7K Jun 30 10:34 /usr/bin/tvservice

test confirms what you say, however top and tr don't.

root@magiatiko:[~]#type tr
tr is /usr/bin/tr
root@magiatiko:[~]#which tr
root@magiatiko:[~]#type test
test is a shell builtin
root@magiatiko:[~]#type top
top is /usr/bin/top

Or wasn't that your point?

What I wanted to make sure is that there wasn't any other sqm file with higher priority in the PATH.

1 Like

Shell builtins should have the highest priority and override binaries in PATH.
Assuming that sqm is not compiled in the shell, using which is fine.

However, in general case which ignores shell builtins.
It may lead to an incorrect result, thus using type over which is preferable.

I got you, but why top or tr don't return type shell builtin then?

1 Like

This means they are not compiled into ash, but still may be parts of busybox:

# readlink -f $(type -p top)

# readlink -f $(type -p tr)

# opkg files busybox | grep -e /top$ -e /tr$