@spbpython

Страница 2 из 785
Aleksandr
14.03.2016
16:59:34
Ок. При этом cat a/b/c/foo.txt работает?

Если нет, то я не понимаю.

Serge
14.03.2016
17:00:08
потому что x есть и r есть

работает

Google
Aleksandr
14.03.2016
17:00:30
Вот. При этом rm -fr не делается?

Странно )

Serge
14.03.2016
17:00:37
сфигали?

ладно, там надо d еще сделать

Aleksandr
14.03.2016
17:01:05
Ну вроде как если можно сделать traverse через a и b то почему я не могу удалить в c все, при том что оно мне принадлежит

Serge
14.03.2016
17:01:10
я тебя обманываю же

нельзя удалить c, потому что нет w в b

Aleksandr
14.03.2016
17:01:52
Связь?

Serge
14.03.2016
17:01:59
чтобы удалить что-то, нужно w в его каталоге

Aleksandr
14.03.2016
17:02:09
На уровень выше? Да ладно

Serge
14.03.2016
17:02:20
потому что удаление c = изменение списка файлов в b

Aleksandr
14.03.2016
17:02:37
А файла? )

Serge
14.03.2016
17:02:46
а какая разница?

Google
Aleksandr
14.03.2016
17:03:02
Ок, т.е. если я не обладаю w правом на директорию я не могу в ней ничего удалить

Это ... Хм

Звучит странно, но обхясняет почему не работает rm -rf . По крайней мере почему он далеко не зайдет объяняет

Serge
14.03.2016
17:04:29
$ mkdir a $ touch a/b $ chmod -w a $ rm a/b rm: cannot remove ‘a/b’: Permission denied

Aleksandr
14.03.2016
17:04:55
unexpected

Serge
14.03.2016
17:05:31
более того $ chmod +w a $ chmod -w a/b $ rm a/b rm: remove write-protected regular empty file ‘a/b’? y $ ls a/b ls: cannot access a/b: No such file or directory

Aleksandr
14.03.2016
17:05:31
Но действительно так )

Serge
14.03.2016
17:07:45
там в линуксовой рассылке в файликах лежит pdf-ка руководство системного администратора, весьма рекомендую;)

всем привет! :)

вот интересно, это товарищи осмысленно пришли или RBTB...

Dmitry
14.03.2016
17:47:08
ты именно эту рекомендуешь?

если да, то почитаю

Serge
14.03.2016
17:47:20
да

это библия

Dmitry
14.03.2016
17:47:34
ок, спасибо :)

Pavel
14.03.2016
17:50:43
Привет. ) Я живой и осмысленный. )

Dmitry
14.03.2016
17:54:40
привет :)

That Guy
14.03.2016
23:34:24
я бы убивал за конфиги на json
Что не так с конфигами на json?

Кстати, есть ещё протобаф, если хочется валидацию

Google
Aleksandr
15.03.2016
00:12:23
Протобаф для конфигов?..

Dmitry
15.03.2016
05:55:54
и json и протобаф это транспорт

никаких конфигов на них быть не должно

Serge
15.03.2016
06:28:14
Что не так с конфигами на json?
Надо не путать хранилище настроек и конфиг. Конфиг - это одновременно хранилище настроек и интерфейс для их редактирования. Так вот, строгие форматы хороши для первого и плохи для второго.

Pavel
15.03.2016
08:51:17
Меня сейчас, наверное, закидают камнями, но все выглядит как острая нехватка опыта использования ini-файлов, начиная парсингом числовых значений и списков адресов вручную. Если у вас конфиг в json, то вы просто в меру ленивы, чтобы не писать велосипед. И пока формат отлично парсится и легко редактируется человеком (кто-нибудь испытывает сложности?) - не вижу никаких проблем. И мне кажется, что позиция вида "json это транспорт" резко ограничивает свои собственные способности.

Ну протобаф совершенно нечеловекочитаем, с ним вопросов нет. )

Dmitry
15.03.2016
08:59:07
У нас ребята то и дело допускают ошибки в json

Serge
15.03.2016
08:59:17
Попробуй написать список из объектов, внутри которых иногда бывают списки и объекты руками

Обязательные кавычки, жесткий формат булов, жесткие требования к запятым.

Иногда, неожиданное восприятие форматов

А еще попробуй его валидировать

Схему еще ладно, может типы. А вот дефолты прописать? А их как раз умеет ConfigParser, потому что его для этого писали

Ну и еще попробуйте переносить куски конфига на json, особенно, если трогаете последние значения или выделяете кусок в отдельный конфиг

Pavel
15.03.2016
09:03:43
Доводить конфиги до такого уровня вложенности - что-то странное вне зависимости от формата, в котором его хранить. И все наши выборки кошек заведомо нерепрезентативны. Когда появляется необходимость задать что-то чуть-чуть проще ароматного значения, начинаются вопросы "а как же это в конфиге хранится".

*атомарного

Pavel
15.03.2016
09:05:01
Чаще всего - так, как задумал разработчик. )

Serge
15.03.2016
09:05:36
Блин, ну попробуйте пожить с конфигом на json с несколькими параллельными инсталляциями и сборкой конфигов из кусочков ансиблом

Чаще всего - так, как задумал разработчик. )
Нет, так как спеке ini формата написано

Google
Serge
15.03.2016
09:06:39
Там вариантов не один и все работают одновременно и все интуитивные, их можно просто писать, скорее всего угадаешь

Pavel
15.03.2016
09:08:30
Нет, так как спеке ini формата написано
Спека очень бедная. Она умеет только примитивные значения.

Из ConfigParser прилетает тупо строчка. Как ее распарсил разработчик - загадка.

Pavel
15.03.2016
09:10:19
Блин, ну попробуйте пожить с конфигом на json с несколькими параллельными инсталляциями и сборкой конфигов из кусочков ансиблом
И снова моя оговорка, что сложность конфигов и формат - таки разные вещи. ) Можно сделать плоский json конфиг.

Dmitry
15.03.2016
09:10:44
можно использовать кошку в роли собаки

Admin


Dmitry
15.03.2016
09:10:53
(но зачем?..)

Pavel
15.03.2016
09:11:26
Так я и начал с объяснения, зачем. :)

Aleksandr
15.03.2016
09:12:55
В yaml vs toml можно так же накосячить. Вопросы типа dict vs list.

Поэтому не вижу смысла кидать особый камень в сторону json

Serge
15.03.2016
09:13:23
вот я решаю до фига devops задач каждый день, я вам точно скажу, что с json-конфигами гемор шо пипец. если вам не хватает ini, используйте yaml, пожалуйста, и пусть будет зависимость

Dmitry
15.03.2016
09:13:37
ещё же есть xml

Serge
15.03.2016
09:13:43
Aleksandr
15.03.2016
09:13:43
Дима, не надо

Dmitry
15.03.2016
09:13:51
?

Aleksandr
15.03.2016
09:14:10
Тебя точно так же закидают за yaml

Pavel
15.03.2016
09:14:10
Yaml - надмножество Json. Поэтому, позиция не совсем понятна

Serge
15.03.2016
09:14:19
ну, вот, по опыту, люди и автоматичка лучше живут с xml, чем с json, серьезно

Pavel
15.03.2016
09:14:35
И снова. Ни один формат не обязывает использовать его так, чтобы убивать.

Google
Aleksandr
15.03.2016
09:14:40
Мне непонятен этот опыт. По-моему запутатьсяво вложенностях xml гораздо проще

А в yaml спутать лист и дикт. Как пример docker-compose

Pavel
15.03.2016
09:15:43
У вас есть инструменты - используйте их разумно, не впадая в крайности. И если говорить о собственном опыте, то я наелся ini-файлов.

Aleksandr
15.03.2016
09:17:11
ini через ConfigParser неудобно редактировать. list(inventory['uk_kvm'].keys())[-1]

Вот это мне неудобно

Serge
15.03.2016
09:17:16
Yaml - надмножество Json. Поэтому, позиция не совсем понятна
а ты забудь об этом и сравни их глазами человека, которому их сапортить надо

ini через ConfigParser неудобно редактировать. list(inventory['uk_kvm'].keys())[-1]
а его надо руками редактировать, если ты используешь автоматическое хранилище, то его можно сделать отдельно, кроссплатворменными средствами

Pavel
15.03.2016
09:19:24
Саппортил. Yaml - ад. Ini - преисподняя.

Aleksandr
15.03.2016
09:19:34
Зачем? Я просто буду использовать yaml/json.

Serge
15.03.2016
09:19:55
есть какая-то фигня, которая использует реестр и xdg dirs на винде/линухе соотвественно

это хранилище средствами ос, которое поддерживает системный и пользовательские конфиги, что правильно

а ini - это способ записать параметры запуска. т.е. некий боле удобный способ, чем писать в коммандной строке

а всякие json/yaml вы можете использовать как вам нравится, но это будет тоже, что использовать для этого sqlite или mongo или любое персистанс хранилище

Саппортил. Yaml - ад. Ini - преисподняя.
да? а ты пробовал json через tee или sed при деплое редактировать?;)

тот же ансибл умеет дополнить ini нужным значением, это просто и удобно, json пересоздавать надо и перевалидировать

ну и ini - это еще и ограничение. если ты можешь его написать руками - значит пока у тебя всё хорошо

Serge
15.03.2016
09:24:52
вот, например, монго - был ini, стало много значений, стал yaml, потому что это как бы иерархический ini

Страница 2 из 785