При использовании
if [ $(tmux has -t junk) ]
выполняется проверка выходных данных команды tmux имеет -t junk
, но не возвращаемое значение.
Так как он всегда печатает один, как в первом случае, это означает, что команда tmux имеет -t junk
не печатает ничего на стандартном выходе.
Так что в первом случае
if [ $(tmux has -t junk) ]
оценивается как
if [ ]
-121--290985-
Как уже упоминалось , если [$ (tmux имеет -t junk)]
расширяется до , если []
, что приводит к значению false.
Можно использовать:
if tmux has -t junk; then
echo OK
else
echo ERR
fi
Или если требуется более короткий:
tmux has -t junk || echo ERR
или
tmux has -t junk && echo OK || echo ERR
Вы также можете отменить его, если это более подходит, как в:
! tmux has -t junk || echo OK
! tmux has -t junk && echo ERR || echo OK
etc.
Edit:
Также не то, что если команда создает выходные данные, вы можете перенаправить это
вывод в черную дыру /dev/null
как в
if my_cmd >/dev/null; then echo OK else; echo ERR; fi
Если команда вызывает текстовую ошибку, возможно, потребуется перенаправить стандарт ошибка, а также:
if my_cmd >/dev/null 2>&1; then echo OK else; echo ERR; fi
Это, что следует, вы можете уже знать хорошо, но добавить его немного больше полнота.
Как уже упоминалось: $?
- единственный способ получить возвращаемое значение программы.
Некоторые программы отличаются от возвращаемых и могут иметь довольно явное значение.
Таким образом, например:
mycmd
ecode=$?
case "$ecode" in
0) echo "Success";;
1) echo "Operation not permitted";;
2) echo "No such file or directory";;
esac
При этом можно предпринять соответствующие действия по конкретным ошибкам.
Если у вас установлен MySQL, вы можете сделать это, например, с помощью perror :
for i in {0..50}; do perror $i; done
# And
for i in {1000..1050}; do perror $i; done
, чтобы почувствовать это.
См. также этот ответ , связанный со специфическими ошибками ОС, которые также связаны с документами открытых групп Номера ошибок и errno.h .
Или посмотрите на SQLite и его расширенные .
-121--290984-
Именно по этой причине мое ранее опубликованное сообщение в значительной степени касается инструментов, которые всегда должны быть доступны на хосте Solaris. (ваша проблема решена с помощью GNU find
). Если бы такие инструменты были доступны по умолчанию, вы бы не имели вопрос в первую очередь.: -)
Вы можете прочитать больше об этом здесь .
Поэтому просто используйте GNU find!!
Просмотр системных вызовов, выполняемых acpi
на моей Ubuntu:
~ strace -e open,chdir acpi
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
chdir("/sys/class") = 0
chdir("power_supply") = 0
open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("BAT0/current_now", O_RDONLY) = -1 ENOENT (No such file or directory)
open("BAT0/power_now", O_RDONLY) = 4
open("BAT0/charge_now", O_RDONLY) = -1 ENOENT (No such file or directory)
open("BAT0/energy_now", O_RDONLY) = 4
open("BAT0/voltage_now", O_RDONLY) = 4
...
Похоже, считывается информация из /sys/class/power_supply/*
.
Поскольку функциональность предоставлена в /sys/class/power_supply/*
и поскольку ядро Debian собрано безCONFIG_ACPI_PROCFS_POWER
:
$ grep CONFIG_ACPI_PROCFS_POWER /boot/config-$(uname -r)
# CONFIG_ACPI_PROCFS_POWER is not set
Вы больше ничего не увидите в/proc/acpi/battery/*