LINUX.ORG.RU

История изменений

Исправление den73, (текущая версия) :

Ну и что доказывает пример на Powershell? Объекты есть, сериализация вложенных структур как-то прошла мимо данного примера. Т.е. я не вижу, как этот пример мог бы обосновать ненужность чего-то подобного JSON или S-выражениям в языках типа shell или tcl.

Я читал одну из апологий за tcl, что вот можно написать некий конфиг: 

hosts {
  ip 127.0.0.1
  name www.ya.ru
}
И, добавив пару команд, сделать этот конфиг исполняемым. Но ведь ясно, что это наколенная поделка, поскольку такой способ чтения конфига страдает от внедрения вредоносного кода, и бороться с этим требует неких усилий. Которые по умолчанию забудутся и в итоге останется дыра. Кроме того, невозможно статически (без риска произвольных побочных эффектов) сказать, что этот конфиг хотя бы грамматически корректен, что вместо ip не написали ir.

По сравнению с этим, JSON не позволяет ничего исполнять и его можно валидировать. В том же лиспе элементарно можно управлять тем, является ли конфиг исполняемым или в него даже нельзя внедрить никакого исполнения *read-eval* nil .

Кроме этого, ни tcl, ни баш не предлагают встроенного (без наколенных парсеров) способа создавать конфиги. Именно поэтому в мире JS все конфиги могли бы быть в JSON, если бы там были допустимы комментарии. Так-то многие *.js, с теми же последствиями для уязвимости. Только в лиспе толково - можно делать конфиги s-выражениями.

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

Исправление den73, :

Ну и что доказывает пример на Powershell? Объекты есть, сериализация вложенных структур как-то прошла мимо данного примера. Т.е. я не вижу, как этот пример мог бы обосновать ненужность чего-то подобного JSON или S-выражениям в языках типа shell или tcl.

Я читал одну из апологий за tcl, что вот можно написать некий конфиг: 

hosts {
  ip 127.0.0.1
  name www.ya.ru
}
И, добавив пару команд, сделать этот конфиг исполняемым. Но ведь ясно, что это наколенная поделка, поскольку такой способ чтения конфига страдает от внедрения вредоносного кода, и бороться с этим требует неких усилий. Которые по умолчанию забудутся и в итоге останется дыра. По сравнению с этим, JSON не позволяет ничего исполнять. В том же лиспе элементарно можно управлять тем, является ли конфиг исполняемым или в него даже нельзя внедрить никакого исполнения *read-eval* nil .

Кроме этого, ни tcl, ни баш не предлагают встроенного (без наколенных парсеров) способа создавать конфиги. Именно поэтому в мире JS все конфиги могли бы быть в JSON, если бы там были допустимы комментарии. Так-то многие *.js, с теми же последствиями для уязвимости. Только в лиспе толково - можно делать конфиги s-выражениями.

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

Исправление den73, :

Ну и что доказывает пример на Powershell? Объекты есть, сериализация вложенных структур как-то прошла мимо данного примера. Т.е. я не вижу, как этот пример мог бы обосновать ненужность чего-то подобного JSON или S-выражениям в языках типа shell или tcl.

Я читал одну из апологий за tcl, что вот можно написать некий конфиг: 

hosts {
  ip 127.0.0.1
  name www.ya.ru
}
[/quote]
И, добавив пару команд, сделать этот конфиг исполняемым. Но ведь ясно, что это наколенная поделка, поскольку такой способ чтения конфига страдает от внедрения вредоносного кода, и бороться с этим требует неких усилий. Которые по умолчанию забудутся и в итоге останется дыра. По сравнению с этим, JSON не позволяет ничего исполнять. В том же лиспе элементарно можно управлять тем, является ли конфиг исполняемым или в него даже нельзя внедрить никакого исполнения *read-eval* nil . 

Кроме этого, ни tcl, ни баш не предлагают встроенного (без наколенных парсеров) способа создавать конфиги. Именно поэтому в мире JS все конфиги могли бы быть в JSON, если бы там были допустимы комментарии. Так-то многие *.js, с теми же последствиями для уязвимости. Только в лиспе толково - можно делать конфиги s-выражениями. 

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

Исходная версия den73, :

Ну и что доказывает пример на Powershell? Объекты есть, сериализация вложенных структур как-то прошла мимо данного примера. Т.е. я не вижу, как этот пример мог бы обосновать ненужность чего-то подобного JSON или S-выражениям в языках типа shell или tcl.

Я читал одну из апологий за tcl, что вот можно написать некий конфиг:

hosts { ip 127.0.0.1 name http://www.ya.ru }

И, добавив пару команд, сделать этот конфиг исполняемым. Но ведь ясно, что это наколенная поделка, поскольку такой способ чтения конфига страдает от внедрения вредоносного кода, и бороться с этим требует неких усилий. Которые по умолчанию забудутся и в итоге останется дыра. По сравнению с этим, JSON не позволяет ничего исполнять. В том же лиспе элементарно можно управлять тем, является ли конфиг исполняемым или в него даже нельзя внедрить никакого исполнения *read-eval* nil .

Кроме этого, ни tcl, ни баш не предлагают встроенного (без наколенных парсеров) способа создавать конфиги. Именно поэтому в мире JS все конфиги могли бы быть в JSON, если бы там были допустимы комментарии. Так-то многие *.js, с теми же последствиями для уязвимости. Только в лиспе толково - можно делать конфиги s-выражениями.

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