Когда пробелы вокруг знака = запрещены?

9

Я знаю, что в ~ / .bashrc нельзя ставить пробелы вокруг =знаков в присваивании:

$ tail -n2 ~/.bashrc 
alias a="echo 'You hit a!'"
alias b = "echo 'You hit b!'"

$ a
You hit a!

$ b
b: command not found

Я рассматриваю конфигурационный файл MySQL, /etc/my.cnfи я нашел это:

tmpdir=/mnt/ramdisk
key_buffer_size = 1024M
innodb_buffer_pool_size = 512M
query_cache_size=16M

Как я могу убедиться, что пробелы вокруг =знаков не являются проблемой?

Обратите внимание, что этот вопрос относится не только к /etc/my.cnfфайлу, но и к файлам конфигурации * NIX в целом. Я в первую очередь склоняюсь к RTFM, но на самом деле man mysqlне упоминаю об этой проблеме, и если мне нужно будет охотиться онлайн в каждом случае, я никогда никуда не пойду. Есть ли соглашение или простой способ проверить? Как видно, несколько человек отредактировали этот файл (разные условные обозначения для =знаков), и я не могу ни заставить их всех использовать пробелы, ни сойти с ума, проверяя все, что может быть настроено, а может и не быть правильным.

РЕДАКТИРОВАТЬ: Мое намерение состоит в том, чтобы убедиться, что в настоящее время настроенные файлы сделаны правильно При настройке файлов я всегда согласен с тем, что содержит сопровождающий пакет.

dotancohen
источник
2
Не существует такой вещи как «* NIX config files вообще». Если я хочу разрешить пробелы в моем конфигурационном файле, я напишу свою программу, чтобы разрешить их. Если я хочу, чтобы в моем конфигурационном файле вместо знаков равенства использовались двоеточия или каналы, я напишу свою программу для их использования. Bash не требует пробелов. Mysql позволяет им.
hymie

Ответы:

3

Я отвечу на это в более общем виде - немного рассмотрев весь « опыт обучения Unix ».

В вашем примере вы используете два инструмента и видите, что язык похож. Просто непонятно, когда использовать что именно. Конечно, вы можете ожидать четкой структуры , поэтому просите нас объяснить это.
Случай с пространством вокруг =только и пример - есть много подобных, но бот-вполне случаев.
В этом должна быть логика, верно ?!

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

Это означает, что инструменты полностью независимы , технически. Логическое отношение , что я думаю , что вы ожидаете , просто не существует .

Очевидное сходство языков, которые вы видите, не является частью реализации программы . Сходство существует, потому что разработчики договорились, как это сделать, когда они записали это для конкретной программы. Но люди могут согласиться только частично .

Отношение вы видите , это культурная вещь - это ни часть реализации , ни в определении языка .



Итак, теперь, когда мы изучили теорию, что делать на практике?

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

Если у вас есть два инструмента, которые не используют один и тот же язык конфигурации (например, оба сценария bash), знание деталей синтаксиса одного не очень помогает в понимании другого;
Так что, действительно, вам придется искать детали самостоятельно . Убедитесь, что вы знаете, где вы найдете справочную документацию для каждого.

С другой стороны, есть некоторая последовательность, в которой вы этого не ожидали: в контексте одного инструмента (или различных инструментов, использующих один и тот же язык), вы можете быть достаточно уверены, что синтаксис последовательный.
В вашем mysqlпримере это означает, что вы можете предполагать, что все строки имеют одинаковое правило. Таким образом, правило «пространство до и после того, как =это не имеет значения ».

Существуют большие различия в том, насколько трудно выучить или использовать язык конфигурации или сценариев инструмента.
Это может быть что-то вроде « Список значений foo в cmd-foo.conf, по одному на строку.».
Это может быть полноценный язык сценариев, который также используется в других местах. Тогда у вас есть мощный инструмент для написания конфигурации - и в некоторых случаях это просто замечательно, в других вам это действительно нужно.
Сложные инструменты или большие семейства связанных инструментов иногда просто используют очень сложный специальный синтаксис файла конфигурации - (некоторые известные примеры - sendmailи vim).
Другие используют общий сценарийязык как базовый, и расширить этот язык для удовлетворения особых потребностей , иногда сложными способами, насколько позволяет язык. Это был бы очень специфический случай предметно-ориентированного языка ( DSL ) .

Volker Siegel
источник
Принято, так как это ответ, который больше всего отвечает на этот вопрос с точки зрения вопроса. Спасибо!
dotancohen
20

Bash будет интерпретировать строку с текстом, за которым следует a, =как присваивание переменной, но она будет интерпретировать строку с текстом, за которой следует пробел, как команду с аргументом.

var=assignment против command =argument

Скрипты Bash работают по принципу, что все в скрипте выглядит так, как будто вы ввели его в командную строку.

В файлах конфигурации, которые не интерпретируются bash(или другой оболочкой), он будет определяться анализатором, который используется для чтения файла конфигурации. Некоторые парсеры будут занимать пробелы, некоторые - нет. Это зависит от приложения в этом случае. Лично я согласен с тем соглашением, которое использовался в файле конфигурации по умолчанию.

Лоренс
источник
Спасибо. Я беспокоюсь о том, как проверить существующие файлы, которые сейчас и в будущем могут быть сконфигурированы другими начинающими типами devops. При настройке файлов я сам согласен с тем, что содержит сопровождающий пакет, как вы предлагаете. Я отредактировал вопрос, чтобы уточнить.
Dotancohen
1
Я предполагаю, что если вы проверяете существующие файлы, я бы проверил документацию по продукту и использовал это в качестве примера. Предполагая, что у вас есть документация, а это не пользовательское приложение. Если бы это было пользовательское приложение, я бы придерживался того, что уже было там. «Если это не сломано, не исправляйте это»
Лоуренс
К сожалению, некоторые из них являются мели. Вот почему я спрашиваю!
Dotancohen
В оболочках никогда не используйте пробелы вокруг равных. Во всем, что не является оболочкой, всегда используйте пробелы. Вы можете проверять существующие файлы, используя grep: 'grep "[^] = [^]" / etc / *', чтобы найти файлы с = без пробелов.
Крис
2
@dotancohen (1.) Для любого файла конфигурации должен быть хотя бы один параметр, который будет довольно легко проверить, если он не работает. Независимо от того, разрешает ли конфигурационный файл пробелы или нет, он должен делать это постоянно. (2.) Вы всегда можете загрузить приложение и проверить настройки по умолчанию, с которыми оно поставляется. (3.) Вы всегда можете вообще пропустить пробелы. a = bможет не всегда быть приемлемым, но a=bвсегда должно работать.
Двухразрядный алхимик
4

.bashrc - это не что иное, как файл конфигурации для bash, как my.cnf, php.ini, httpd.conf или launchd plist. Каждый из них имеет свой собственный синтаксис, начиная от присваивания bash без пробелов до супа тега XML для launchd (есть также двоичная версия: -O)

Твердых соглашений нет, и вы уже открыли основную директиву Unix: прочитайте The Fine Manual.

Павел
источник
1
.bashrcэто не файл конфигурации для bash. .bashrcэто сценарий оболочки , который Баш запускается каждый раз , когда начинается процесс Баша. Он может использоваться для настройки bash, но также может использоваться и для других целей: это скрипт, а не файл конфигурации.
Джош
3

Некоторые программы предлагают проверку файла конфигурации, например:

postfix check

В противном случае вы можете получить исходные файлы конфигурации из репозиториев и сравнить их с diff с текущим.

user78568
источник
На самом деле, похоже, что это действительно решает основную проблему. Спасибо!
Dotancohen
2

Пробелы вокруг =знака всегда являются проблемой, когда вы делаете назначение в bash. Здесь нет исключений, вы должны удалить все пробелы вокруг, =если вы хотите получить допустимое простое назначение (без расширения, без арифметики, без назначения массива) в bash.

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

Например mysql, в своем скрипте инициализации /etc/init.d/mysqldон имеет синтаксический анализатор для my.cnf:

# Try to find basedir in /etc/my.cnf
  conf=/etc/my.cnf
  print_defaults=
  if test -r $conf
  then
    subpat='^[^=]*basedir[^=]*=\(.*\)$'
    dirs=`sed -e "/$subpat/!d" -e 's//\1/' $conf`
    for d in $dirs
    do
      d=`echo $d | sed -e 's/[  ]//g'`
      if test -x "$d/bin/my_print_defaults"
      then
        print_defaults="$d/bin/my_print_defaults"
        break
      fi
      if test -x "$d/bin/mysql_print_defaults"
      then
        print_defaults="$d/bin/mysql_print_defaults"
        break
      fi
    done
  fi
cuonglm
источник
Есть исключение в (( var = 12 ))или var=( value )или $((var = 12))или${var[foo = 12]}
Стефан Chazelas
@ StéphaneChazelas: Не об этих случаях в этом вопросе, добавить информацию. Спасибо.
Cuonglm