Запустить скрипт на нескольких оболочках?

Тем временем я купил и протестировал некоторые устройства. Мой выбор был высоко вдохновлен списком, предложенным @Renat. Здесь, я компилирую свои результаты.

Неисправность AVM

Маленький вариант Палки Fritz Wlan AVM N поддерживает только 2,4 ГГц, в то время как большой имеет многополосную поддержку с 2,4 и 5 ГГц. Оба полагаются на carl9170 модуль драйвера. Используемый в качестве клиентов, они - оба катастрофа. Они регулярно отказывают. Ядро перезапускает их в меньше затем секунде, но повторно подключение является необходимым и трудоемким. Соединения в реальном времени невозможны, уже не говоря о вещах как SSH. Кроме того, проблема, кажется, накапливает. Чем дольше я использовал палки, тем более частый они действительно отказывали, приводя к палке который работавший несколько минут над максимумом. Настраивая параметры модуля, nohwcrypt и noht для сокращения нагрузки на оборудование устройства вызвал только временную поправку.

Тестируя многополосный в режиме точки доступа, однако, это работало безупречное. Потоковая передача видео и sftp передача файлов работали с полными 300 Мбит/с.

Ссылка TP

Со Ссылкой TP у меня снова был выбор между двухдиапазонным вариантом TL-WDN3200 и 2,4 ГГц только TL-WN821N. Первые потребности драйвер из дерева, который будет скомпилирован, таким образом, я сразу пропустил к модели единственной полосы. TL-WN821N использует ath9k_htc модуль, включенный в ядро Linux. даже имеет немного более высокую скорость передачи и качество соединения, чем модели Fritz, протестированные по двум этажам и некоторым стенам. Это также отказывает намного меньше, чем они, только несколько раз день. Но когда это делает, это компенсирует свою производительность путем замораживания значительных частей сетевой подсистемы. Каждый syscall, который пытается получить доступ к сетевому устройству (включая обратную петлю, на которую полагаются много Решений IPC) остановы и возврат привычки, пока устройство не отключается или модуль ядра, удален. Я пожертвовал его некоторому пользователю Windows, где это делает свою работу как клиент с тех пор.

Buffalo

Наконец, я испытал Buffalo WLI-UC-G300HP. Хотя это маркировано 300 Мбит/с также, это работает немного медленнее, чем вышеупомянутые. Качество соединения все еще хорошо всюду по некоторым стенам и этажам, особенно при использовании его небольшой корректируемой антенны, которой можно также махать далеко полностью, когда пространство является ограниченным. Я использую его в течение нескольких месяцев теперь и очень удовлетворен.

Его единственный дефект - то, что никакой драйвер автоматически не чувствует себя ответственным за это устройство. На самом деле это может использоваться с хорошо протестированным rt2800usb модулем. Существует две возможности преподавать это к ядру.

В Runtime

Проблема как корень

modprobe rt2800usb
echo 0411 01a8 > /sys/bus/usb/drivers/rt2800usb/new_id

Первая строка вставляет модуль. Второй говорит устройство и идентификатор продукта к драйверу. Эти числа могут быть найдены через lsusb, но должны быть те данные для WLI-UC-G300HP. Затем драйвер принимает управление модулем. Это могло быть сделано персистентным с правилом udev. Я, с моей стороны, выбираю другой метод

Компиляция ядра

При создании ядра сами так или иначе можно просто применить следующий патч.

diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 098613e..2ded919 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -953,6 +953,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
        { USB_DEVICE(0x0411, 0x016f) },
        { USB_DEVICE(0x0411, 0x01a2) },
        { USB_DEVICE(0x0411, 0x01ee) },
+       { USB_DEVICE(0x0411, 0x01a8) },
        /* Corega */
        { USB_DEVICE(0x07aa, 0x002f) },
        { USB_DEVICE(0x07aa, 0x003c) },

Это добавляет идентификаторы к внутренней базе данных модуля так, чтобы это было внутренне мотивировано для управления устройством.

4
08.08.2014, 22:33
5 ответов

Вероятно, было бы проще иметь два отдельных варианта сценария. Так как это короткая версия, возможно, не стоит добавлять дополнительный код, чтобы справиться с различиями между двумя форматами, как предлагал jw013. С другой стороны, если у вас есть более крупный сценарий, вероятно, было бы легче иметь один и заставить скрипт выполнять различные команды в зависимости от того, где он работает от.

.
2
27.01.2020, 20:52

Я бы поработал над тем, чтобы посмотреть, действительно ли у вас есть одна версия с командой, которая работает на обеих системах.

У меня была проблема с моим .bashrc файлом, который я храню в моем репозитории дотфайлов. Я хочу, чтобы он работал как на OSX, так и на Ubuntu, и для этого мне пришлось изменить несколько команд. В данном случае, в основном, речь шла о том, какие переключатели работали для определенной команды или как была написана тестовая команда. Я решил каждую проблему, найдя способ делать любую команду в форме, которая бы работала на обеих ОС

, я попробовал "два разных файла" и "два разных раздела в зависимости от ОС", и нашел их неудобство в обслуживании.

0
27.01.2020, 20:52

Самый простой способ - использовать одну и ту же оболочку на обеих системах. То, что одна оболочка предустановлена (нет такой вещи, как "оболочка по умолчанию" для скриптов, оболочка - это то, о чём говорит строка shebang), не означает, что вы не можете установить другие. Вы можете установить bash на AIX (например, из toolbox) или ksh93 для Linux (с помощью менеджера пакетов вашего дистрибутива: установите пакет ksh).

Если вы выберете ksh, остерегайтесь, что /usr/bin/ksh на AIX - это ksh88. Нет никакой версии ksh88 для Linux, только ksh93, которая доступна в виде /usr/bin/ksh93 на AIX.

Проще, если одна и та же оболочка устанавливается в одном и том же месте на обеих системах (символическая ссылка - это хорошо), так что вы можете использовать один и тот же путь в линии shebang. Если иметь одно и то же место слишком сложно, вы можете использовать что-то вроде #!/usr/bin/env bash, при условии, что вы убедитесь, что bash находится в PATH на обеих системах. Это может быть полезно, если вам нужно установить bash или ksh в ваш домашний каталог, потому что у вас нет прав root.

Если вы действительно не можете установить одну и ту же оболочку на обе машины - предположительно, потому что есть какое-то глупое правило соответствия, которое только усложняет жизнь людей, но слишком зациклено, чтобы опрокинуть - у вас есть несколько возможностей.

  • Используйте #!/bin/sh в качестве линии Shebang и программы на пересечении того, что предлагают ваши системы. Все современные unix-системы предоставляют /оболочку POSIX в виде /bin/sh. На AIX, /bin/sh является ksh88. На Red Hat, /bin/sh - это баш (который ведет себя немного по-другому при вызове как sh). Обратите внимание, что на некоторых других операционных системах (например, на многих дистрибутивах Linux) /bin/sh представляет собой оболочку меньшего размера, которая может иметь не больше возможностей POSIX.
  • Начните свои скрипты с некоторого кода boilerplate, который ищет лучшую оболочку и выполняет ее.

    #!/bin/sh
    если [ -n "$BASH" ]; тогда...
     ...код совместимости...
    тип elif откуда >/dev/null 2>/dev/null; затем
     ... код совместимости с кш ...
    тип elif ksh93 >/dev/null 2>/dev/null; затем
     exec ksh93 "$0" "$@"
    тип elif ksh >/dev/null 2>/dev/null; затем
     exec ksh "$0" "$@"
    тип elif мкш >/dev/null 2>/dev/null; затем
     exec mksh "$0" "$@"
    тип elif bash >/dev/null 2>/dev/null; затем
     exec bash "$0" "$@"
    другое
     эхо 1>&2 "Не могу найти кш или баш, прерывание"
     выход 125
    
    

В любом случае, пересечение ksh88 и bash предоставляет некоторые полезные функции, выходящие за рамки POSIX, но вам может понадобиться небольшой код совместимости. В частности:

  • Присвоение массива в ksh88 использует set -A. См. переменная присваивания в различных средах ksh
  • Локальные переменные объявлены набором -A.
  • Ksh88 не имеет ${VAR/PATTERN/REPLACEMENT}, $'...' или FIGNORE. В ней есть [[...]].
  • Чтобы включить @(...) и другие расширенные кШ паттерны в bash, запустите shopt -s extglob.
3
27.01.2020, 20:52

ответ Gilles является (по моему скромному мнению), блестящим (как всегда), но так как вы не выбрали его или сглаживать-голосование он, возможно, вы находите, что он также усложнил. Таким образом, вот несколько (простых) точек, которые могли бы или не могли бы быть полезными, и могут помочь вам постараться не поддерживать два отдельных сценария, которые могли превратиться в безумие для большого сценария, который должен сохраняться за длительный промежуток времени.

1) машины AIX могли бы иметь удар установленный даже при том, что это не оболочка по умолчанию для интерактивного использования. (Машины AIX, с которыми я работаю, действительно имеют удар установленный, но я не знаю, прибыл ли он, тот способ системных администраторов добавил его. Я предполагаю, что это прибыло в него, так как все наши системные администраторы ksh наркоманы.) И я готов держать пари, что машины RHEL имеют установленный ksh. Проверить это, потому что, если можно использовать ту же оболочку на обеих машинах, она сохранит вас партия из стычки.

2), Если вы не знаете, где оболочка будет установленной, постарайтесь не помещать ее путь непосредственно в строку хижины. Вместо этого вставить путь к env и исполнимое имя оболочки позже, как так:

#!/usr/bin/env bash

Это должно работа над обеими машинами, но необходимо будет протестировать ее, чтобы быть уверенными. (Местоположение для env является, предположительно, более стандартным, чем местоположение для удар или большинство других вещей.)

, После того как вы используете ту же оболочку на обеих машинах, проблема могла бы быть решена тут же. Но если нет...

3) можно взломать определенный для платформы код в функции, которые вы получаете в основной сценарий. Это означает, что, хотя сценарий мог бы иметь партии из мест, где вещи работают по-другому в зависимости от того, работает ли он на AIX или RHEL, вы не должны неоднократно проверять платформу. Просто сделайте это однажды и получите соответствующие функции:

case $OS in
    "AIX")
            source aix_functions;;
    "Linux")
            source redhat_functions;;
    "*")
            echo "Exiting. The OS type is not found.";;
esac

Теперь можно использовать любые функции, которые вы получили, на всем протяжении вашего сценария, никогда не имея необходимость иметь другой чехол оператор для различения платформы:

do_something_platform_specific "$SOME_ARGUMENT" "$SOME_OTHER_ARGUMENT"
0
27.01.2020, 20:52

У меня было похожее требование - мне нужно было использовать KSH93 на AIX 5.3 для поддержки ассоциативных массивов. Поэтому я настроил скрипт, чтобы начать второй экземпляр, используя ksh93. Я также добавил защиту, чтобы сохранить его от того, чтобы отвести себя снова и снова.

#!/bin/ksh

scr=$0
safe=$1
echo "Check OS to determine if ksh93 is needed..."
if ( `typeset -A testvar > /dev/null 2>&1` ); then
  echo "Associative array functions supported."
else
  echo "Associative array functions NOT supported. Starting second instance with ksh93..."
  if [ "$safe" -eq 1 ]; then
    echo "SECOND INSTANCE ALREADY STARTED!"
    exit 1
  else
    echo "BEGIN SECOND INSTANCE USING KSH93"
    /bin/ksh93 $scr 1
    exit 0
  fi
fi
1
27.01.2020, 20:52

Теги

Похожие вопросы