Шаблон именования дерева устройств nvmem

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

Цитаты сначала идентифицируются при токенизации, которая производит слова. Они склеивают слова так, что abc"spaces here"xyzсоставляет одно «слово».

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

Параметры раскрываются без учета двойных кавычек. Позже, однако, происходит процесс разделения полей, который восходит к первой токенизации. И снова кавычки предотвращают разделение и снова сохраняются.

Расширение имени пути ("подстановка" )происходит после этого разбиения. Сохраненные кавычки предотвращают это :операторы подстановки внутри кавычек не распознаются.

Наконец, кавычки удаляются на последнем этапе, который называется «удаление кавычек». Конечно,только оригинальные кавычки!

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

Люди, использующие ad hoc концепции, такие как «контекст списка», должны формализовать свое мышление до такой степени, чтобы оно могло предоставить полную альтернативную спецификацию для всей обработки, которая эквивалентна (производящей одно и то же. результаты ). И затем, избегайте смешения концепций между параллельными планами :, используйте то или иное объяснение. «Контекст списка» или «контекст строки» имеет смысл в теории расширения оболочки, в которой они четко определены, а этапы обработки организованы вокруг этих концепций.

Если я угадал, то "контекст списка" относится к идее, что оболочка работает со списком размеченных слов, таким как список из двух -слов {foo} {abc" x "def}. Кавычки не являются частью второго слова :, его содержание на самом деле abc x def; это семантические кавычки, которые предотвращают разделение на пробелы. Внутри этих кавычек у нас есть «контекст строки».

Однако возможной реализацией этих шагов расширения является не фактическое наличие кавычек, которые идентифицируются как исходные кавычки, а некоторая структура данных списка, так что {foo} {abc" x "def}является, скажем, список списков, в которых части в кавычках идентифицируются как различные типы узлов (, а кавычки отсутствуют ). Используя нотацию Лиспа, это может быть:

(("foo") ;; one-element word
 ("abc" (:dq-str " x ") "def")) ;; three-element word

Узлы без метки — это обычный текст, :dq-str— область с двойными -кавычками. Другой тип может быть :sq-strдля одного элемента в кавычках.

Расширение может пройти по этой структуре, а затем выполнять разные действия в зависимости от того, просматривает ли оно строковый объект, :dq-strвыражение или что-то еще.Расширение файла и разделение полей будут подавлены как в :dq-str, так и в :sq-str. Но расширение параметра происходит внутри :dq-str. «Удаление кавычек» тогда будет соответствовать последнему проходу, который берет части и связывает строки, сглаживая внутреннюю структуру списка и теряя символы, указывающие тип, что приводит к:

("foo"
 "abc x def") ;; plain string list, usable as command arguments

Теперь обратите внимание, что во втором пункте мы имеем ("abc" (:dq-str " x ") "def"). Первый и последний элементы развернуты :, они являются прямыми элементами списка, и поэтому мы можем сказать, что они находятся в «контексте списка». Принимая во внимание, что средний " x "заключен в выражение :dq-str, так что это «(контекст строки с двойными кавычками )».

Что означает «список» в «контексте списка», можно только догадываться без четко определенной модели, такой как эта. Это главный список слов? Или список фрагментов, представляющих одно слово?