Як прочитати весь скрипт оболонки перед його виконанням?

Зазвичай, якщо ви редагуєте підказку, усі запущені сценарії схильні до помилок.

Наскільки я зрозумів, bash (інші оболонки теж?) Читає сценарій поступово, тому якщо ви змінили файл сценарію зовні, він почне читати неправильні речі. Чи є спосіб запобігти це?

Приклад:

sleep 20

echo test

Якщо ви виконаєте цей скрипт, bash прочитає перший рядок (скажімо, 10 байт) і перейде до сну. Коли він відновиться, у скрипті може бути різний вміст, починаючи з 10-го байти. Я можу бути в середині рядка в новому сценарії. Таким чином запущений сценарій буде порушений.

Так, оболонки, і bashзокрема, уважно читають файл по одному рядку, тому він працює так само, як коли ви його інтерактивно використовуєте.

Ви помітите, що коли файл не є вигідним (як труба), bashнавіть читає один байт за один раз, щоб бути впевненим, що він не читає минулого \nсимволу. Коли файл є шукаючим, він оптимізується, читаючи повні блоки за один раз, але звертайтеся до того, як після\n .

Це означає, що ви можете робити такі речі:

bash << \EOF
read var
var's content
echo "$var"
EOF

Або пишіть сценарії, які самі оновлюються. Що ви б не змогли зробити, якби це не дало вам гарантії.

Зараз рідко ви хочете робити такі речі, і, як ви з’ясували, ця функція, як правило, заважає частіше, ніж це корисно.

Щоб уникнути цього, ви можете спробувати переконатися, що ви не змінюєте файл на місці (наприклад, модифікуйте копію та перемістіть її на місце (наприклад, sed -iабоperl -pi й деякі редактори роблять, наприклад)).

Або ви можете написати свій сценарій так:

{
  sleep 20
  echo test
}; exit

(зауважте, що важливо, щоб exitбути на тій же лінії, що і} , що і ви, хоча ви можете також поставити його всередині брекетів безпосередньо перед закриттям).

або:

main() {
  sleep 20
  echo test
}
main "$@"; exit

Оболонці потрібно буде прочитати сценарій до моменту exit перед цим нічого не почнуть робити. Це гарантує, що оболонка більше не буде прочитана зі сценарію.

Це означає, що весь сценарій буде зберігатися в пам'яті.

Це також може вплинути на розбір сценарію.

Наприклад, у bash:

export LC_ALL=fr_FR.UTF-8
echo $'St\ue9phane'

Виведе, що U + 00E9, закодовані в UTF-8. Однак якщо змінити його на:

{
  export LC_ALL=fr_FR.UTF-8
  echo $'St\ue9phane'
}

\ue9Буде розширено в кодуванні , яка була в дії в той час, коли команда була розібрана , який в цьому випадку , перш ніжexport команда буде виконана.

Також зауважте, що якщо sourceака. команда , з деякими оболонками, у вас виникнуть такі самі проблеми для файлів, що розміщуються.

Це не той випадок, bashхоча sourceкоманда якої читає файл повністю перед його інтерпретацією. Якщо писати bashконкретно, ви можете реально використати це, додавши на початку сценарію:

if [[ ! $already_sourced ]]; then
  already_sourced=1
  source "$0"; exit
fi

(Я б не покладався на це, хоча, як ви можете собі уявити, майбутні версії bashможуть змінити таку поведінку, яку в даний час можна розглядати як обмеження (bash і AT&T ksh - єдині оболонки, схожі на POSIX, які поводяться так, наскільки це можливо) і already_sourcedтрюк трохи крихкий, оскільки передбачає, що змінної немає в середовищі, не кажучи вже про те, що вона впливає на вміст змінної BASH_SOURCE)

Вам просто потрібно видалити файл (тобто скопіювати його, видалити, перейменувати копію назад у вихідне ім’я). Насправді багато редакторів можуть бути налаштовані зробити це за вас. Коли ви редагуєте файл і зберігаєте до нього змінений буфер, замість того, щоб перезаписати файл, він перейменовує старий файл, створить новий і додасть новий вміст у новий файл. Отже, будь-який запущений сценарій повинен продовжуватися без проблем.

Використовуючи просту систему управління версіями, на зразок RCS, яка легко доступна для vim та emacs, ви отримуєте подвійну перевагу наявності історії змін, і система замовлення повинна за замовчуванням видалити поточний файл і відтворити його з правильними режимами. (Звичайно, остерігайтеся жорсткого зв’язування таких файлів).

Найпростіше рішення:

{
  ... your code ...

  exit
}

Таким чином, bash прочитає весь {}блок перед його виконанням, а exitдиректива гарантує, що нічого не буде прочитано поза блоком коду.

Якщо ви не хочете "виконувати" скрипт, а скоріше "джерело" його, вам потрібно інше рішення. Це має працювати тоді:

{
  ... your code ...

  return 2>/dev/null || exit
}

Або якщо ви хочете безпосередньо контролювати код виходу:

{
  ... your code ...

  ret="$?";return "$ret" 2>/dev/null || exit "$ret"
}

Вуаля! Цей сценарій безпечно для редагування, джерела та виконання. Ви все ще повинні бути впевнені, що ви не змінюєте його протягом тих мілісекунд, коли він спочатку читається.

Доказ концепції. Ось сценарій, який змінює себе:

cat <<EOF >/tmp/scr
#!/bin/bash
sed  s/[k]ept/changed/  /tmp/scr > /tmp/scr2

# this next line overwites the on disk copy of the script
cat /tmp/scr2 > /tmp/scr
# this line ends up changed.
echo script content kept
EOF
chmod u+x /tmp/scr
/tmp/scr

ми бачимо друковану версію

Це відбувається тому, що завантаження bash зберігає ручку файлу для відкриття до сценарію, тому зміни у файлі будуть помічені негайно.

Якщо ви не хочете оновлювати копію пам'яті, від’єднайте оригінальний файл та замініть його.

Один із способів зробити це - за допомогою sed -i.

sed -i '' filename

доказ концепції

cat <<EOF >/tmp/scr
#!/bin/bash
sed  s/[k]ept/changed/  /tmp/scr > /tmp/scr2

# this next line unlinks the original and creates a new copy.
sed -i ''  /tmp/scr

# now overwriting it has no immediate effect
cat /tmp/scr2 > /tmp/scr
echo script content kept
EOF

chmod u+x /tmp/scr
/tmp/scr

Якщо ви використовуєте редактор для зміни сценарію, увімкнення функції "зберігати резервну копію" може бути все необхідне, щоб редактор написав змінену версію в новий файл замість того, щоб перезаписати існуючий.

Загортання сценарію в блок {}, ймовірно, найкращий варіант, але вимагає зміни сценаріїв.

F=$(mktemp) && cp test.sh $F && bash $F; rm $F;

був би другим найкращим варіантом (якщо припустити tmpfs ) недоліком є ​​те, що він розбиває $ 0, якщо ваші сценарії використовують це.

використання чогось подібного F=test.sh; tail -n $(cat "$F" | wc -l) "$F" | bashє менш ідеальним, оскільки він повинен зберігати весь файл у пам’яті та розбиває 0 доларів.

Слід уникати дотику до оригінального файлу, щоб останнє змінене час не було порушено читання блоків та жорстких посилань. таким чином ви можете залишити редактор відкритим під час роботи файлу, і rsync не зайвим буде перевіряти суму файлу на функцію резервного копіювання та жорстких посилань, як очікувалося.

заміна файлу на редагування працюватиме, але є менш надійною, оскільки це не підлягає застосуванню для інших сценаріїв / користувачів /, або можна забути. І знову це порушило б міцні зв’язки.