Parse bash аргумент внутри флага - PullRequest
1 голос
/ 09 марта 2020

Я хочу сделать анализатор аргументов внутри одного аргумента.

Вот мой лаунчер ./bin/kube/launch_market_quality_job.sh -e staging -j job_example

А вот мой скрипт.

while [ ${#} -ne 0 ]; do
  case "${1}" in
    --environment | -e)
      shift;
      export ONE_ENVIRON=${1};
      case $ONE_ENVIRON in
        staging)
          export REPOSITORY=dtr.grupobme.es/tca-qa/spark-driver
          ;;
        production)
          export REPOSITORY=dtr-prod.grupobme.es/tca-produccion/spark-driver
          ;;
        *)
          fail "You must provide the environment [staging|production]"
          ;;
      esac
      ;;
    --job | -j )
      shift;
      export JOB=${1}
      case $JOB in
          job_example_extra_args)
          case "${1}" in
          --name | -n )
          export $NAME=${1}
      [... extra args]
      ;;
    *)
      help
      exit
      ;;
  esac
  shift
done

Что я хочу сделать, это зависит от опции "--j | -job", это проанализировать еще две опции, в зависимости от того, выполняются ли задания, те или иные.

Например, обычное задание, называемое 'job_example' с предыдущим средством запуска это работает правильно.

Но если моя работа 'job_example_extra_args', мне нужен новый аргумент под названием 'name'.

`./bin/kube/launch_market_quality_job.sh -e staging -j job_example_extra_args --name "Jesus"`

Я не знаю, как правильно, если это 'job_example_extra_args ', я хочу получить флаг правильно, и если он не включен, сценарий должен завершиться с ошибкой или остановиться. Я хочу добавить опции флагов внутри флага --job, чтобы активировать его, если я хочу задание.

Ответы [ 2 ]

1 голос
/ 09 марта 2020

Вы можете встраивать дополнительный аргумент в основной анализ ("job"), вставляя полный анализ l oop в каждое альтернативное задание. Но это будет трудно поддерживать, поскольку логика, связанная с заданием c, отделена от реализации задания.

Возможно, лучшим решением будет создание аргумента-анализатора + средства запуска для каждого задания. Поскольку вы уже переместили проанализированные аргументы в сторону, вы можете просто создать соответствующий скрипт, используя команду .. (Многие оболочки допускают использование source в качестве синонима для ..) Обратите внимание, что если вы не укажете аргументы после имени файла в команде ., существующие аргументы не будут изменены, поэтому ваши необработанные аргументы будут просто переданы через. (Для оболочек Posix . может даже не принимать аргументы после имени файла.)

1 голос
/ 09 марта 2020

Я бы перехватил все аргументы и выполнил бы проверку после разбора всех аргументов, например:

unset ONE_ENVIRON JOB NAME
while [ ${#} -ne 0 ]; do
  case "${1}" in
    --job | -j )
      shift;
      export JOB=${1}
      ;;
  case "${1}" in
    --name | -n )
      shift
      export NAME=${1}
      ;;
  esac
  shift
done

if [ "$JOB" = job_example_extra_args ] && [ -z "$NAME" ]; then
  fail "You must provide a name for this job"
fi

Таким образом, не имеет значения, передаст ли пользователь аргумент --name NAME до или после --job JOBNAME аргумент. Все, что имеет значение, это то, что в какой-то момент был дан полный список необходимых аргументов.

Вы также можете сообщить об ошибке, если --name должен быть передан исключительно с заданием job_example_extra_args:

if [ "$JOB" != job_example_extra_args ] && [ -n "$NAME" ]; then
  fail "You must NOT provide a name for this job"
fi

PS. Я не показываю --environment|-e и * для ясности, но с ними все в порядке.

...