Czy ktoś wie, czy możemy powiedzieć set +xw bashu bez drukowania:
set -x
command
set +x
ślady
+ command
+ set +x
ale powinien po prostu wydrukować
+ command
Bash to wersja 4.1.10 (4). Od jakiegoś czasu mnie to niepokoi - wyjście jest zaśmiecone bezużytecznymi set +xwierszami, przez co narzędzie śledzenia nie jest tak przydatne, jak mogłoby być.
Odpowiedzi:
Miałem ten sam problem i udało mi się znaleźć rozwiązanie, które nie używa podpowłoki:
set -x
command
{ set +x; } 2>/dev/null
set +xto takie udane polecenie
command, ta odmiana jest rozwiązanie: { STATUS=$?; set +x; } 2>/dev/null. Następnie $STATUSw wolnym czasie sprawdź kolejne linie.
{ set +x; } 2>&-. To całkowicie zamyka fd 2, zamiast wskazywać na / dev / null. Niektóre programy nie radzą sobie tak dobrze, gdy próbują drukować na stderr, dlatego / dev / null jest ogólnie dobrym stylem; ale set -xśledzenie muszli radzi sobie z tym dobrze, więc działa tutaj idealnie i sprawia, że inkantacja jest nieco krótsza.
Możesz użyć podpowłoki. Po wyjściu z podpowłoki ustawienie xzostanie utracone:
( set -x ; command )
( set -x \n command \n )nic gorszego niż set -x \n command \n set +x.
cd: nie zmienia bieżącego katalogu w powłoce nadrzędnej.
Niedawno zhakowałem rozwiązanie tego problemu, kiedy to mnie zdenerwowało:
shopt -s expand_aliases
_xtrace() {
case $1 in
on) set -x ;;
off) set +x ;;
esac
}
alias xtrace='{ _xtrace $(cat); } 2>/dev/null <<<'
Pozwala to włączać i wyłączać xtrace, jak poniżej, gdzie loguję, jak argumenty są przypisywane do zmiennych:
xtrace on
ARG1=$1
ARG2=$2
xtrace off
Otrzymasz wynik, który wygląda następująco:
$ ./script.sh one two
+ ARG1=one
+ ARG2=two
/dev/stdinczęści). Zastrzeżenie polega na tym, że włączenie rozszerzania aliasów w skryptach może mieć niepożądane skutki uboczne.
/dev/stdin. Nie znam żadnych konkretnych skutków ubocznych, ponieważ nieinteraktywne środowisko nie powinno ładować żadnych plików, które definiują aliasy. Jakie mogą wystąpić skutki uboczne?
set +xo wiele trudniej (jeśli nie niemożliwe) jest pójść na kompromis. Ale to wciąż dobre i proste rozwiązanie - chyba najlepsze do tej pory.
Jest to kombinacja kilku pomysłów, które mogą obejmować blok kodu i zachować status wyjścia.
#!/bin/bash
shopt -s expand_aliases
alias trace_on='set -x'
alias trace_off='{ PREV_STATUS=$? ; set +x; } 2>/dev/null; (exit $PREV_STATUS)'
trace_on
echo hello
trace_off
echo "status: $?"
trace_on
(exit 56)
trace_off
echo "status: $?"
Po wykonaniu:
$ ./test.sh
+ echo hello
hello
status: 0
+ exit 56
status: 56
()wokół exitnie jest to konieczne. Ok. Może to jest paranoikiem, ale jeśli ten kod jest używany w ogóle masz dobry wektora ataku: zmiana definicji trace_onoraz trace_offi wstrzyknąć kod, który wczytuje wykonywanych poleceń. Jeśli używasz tylko takich „narzędzi”, jest to pouczające, ale jeśli kod jest używany z innymi, musisz rozważyć, czy zalety takich niestandardowych funkcji przeważają nad wadami. Osobiście się z { set +x; } 2>/dev/nulltym zdecydowałem, ponieważ ta konstrukcja jest powszechnie rozumiana i również nie zmienia statusu wyjścia.
()całego exit 56; tylko po to, abym mógł wykazać, że status wyjścia podprocesu był dostępny w skrypcie bash; bez parenów nie stałby się podprocesem, a skrypt zakończyłby pracę w tym momencie ze statusem = 65.
script.sh 2>&1 | grep -v 'set +x'