NFS export s # v imeto

Znaete li kak moga da export-na direktoriya, koyato ima v imeto si diez? Kakto i da go vyveda, vse za nachalo na komentar go priema...

man exports

[snip]
Blank lines are ignored. A pound sign ("#") introduces a comment to
the end of the line. Entries may be continued across newlines using a
backslash. If an export name contains spaces it should be quoted using
double quotes. You can also specify spaces or other unusual character
in the export name USING A BACKSLASH FOLLOWED BY THE CHARACTER CODE
AS THREE OCTAL DIGITS.
[snip]

Осмичният код на # е 043, =>

/weird-dir-with-a-\043-in-the-name my.host(ro)

в /etc/exports би трябвало да свърши работа.


RTFM!
--sdg

Emi taka sym probval. Kato komentar si go parse-va.

Вярно, не става. Мамка му.


RTFM!
--sdg

На OpenBSD стана. Там # е начало на коментар само ако е първия символ от реда.
Пратих bug report на Debian -- да оправят parser-а на /etc/exports, или поне
документацията :-) Ако имаме късмет, ще си го оправят, и ще "повлекат крак"
за другите Linux дистрибуции.


RTFM!
--sdg

Opita li dali stawa s exportfs(8)?

Не става, или поне аз не успях да го "убедя".


RTFM!
--sdg

A kwo li shte stane ako prosto _ne_ polzwash direktorii s # w imeto, a?


Moje i da zwuchi malko krajno, ama za chij *** ti sa direktorii, koito sydyrjat #?


_________________________________

Patient: “Docter, it hurts when I do this.”
Doctor: “Don’t do that then.”

[линк]

_________________________________


Ta i az taka, kato ne moje, mahni #-to
_ _ _

Time is like a drug. Too much of it kills you.

Що пък да не мога да използвам каквото ми е кеф, с изключение на терминали/интервали в името? Включително и кирилица.

Искам да кажа, при положение, че говорим изцяло за синтаксис на парсера (99% съм сигурен, че в NFS като протокол можеш и \n да използваш в името), защо да се слагат изкуствени ограничения?

P.S. А къде е Снежанка тези дни?

... защото ще имаш и подобен проблем после при mount-ването. Не се знае дали няма да трябва да оправяш и парсера на /etc/fstab (т.е. mount -a). Ще имаш грижи и с всички други команди при работа с такава директория от shell. Почти съм сигурен, че и lsof ще се скапе (поне за & се скапва и казва cannot stat filesystem). Добрият стил изисква да не се използват символи, които трябва да се escape-ват, както и такива които трябва да се прекодират при преминаване от една ОС към друга (кирилица). Не че е невъзможно, просто е "грозно".

Митко

Abe to kefa da ti kaja e dosta raztegliwo ponyatie

Na tebe ako ti e kef, na nyakoj moje da mu se doplache posle. I men mi e kef da si naprawya email ДядоМраз@Лапландия.org, ami mi kazwat NYZ, ni moj

A Snejanka si e tuka pri mene


_ _ _

Time is like a drug. Too much of it kills you.

не добрия стил, а сигурния стил. Ако искаш да нямаш никакви проблеми, използваш само главни букви от A до Z и толкова.

Според мен добрият стил изисква да не се налагат изкуствени ограничения ... неприятното е, че тези ограничения _вече_ са наложени, както посочваш.

При монтирането няма да има проблем, защото във fstab # започва коментар, само ако е в началото на реда (игнорирайки интервали и табове).

Значи според теб е по-добре да не оправяме грешките, а да свикнем да ги заобикаляме? И то на всички възможни операционни системи? Добре че повечето програмисти не мислят като теб.

Добрият мениджър предвижда проблемите и ги избягва, а не хаби време и сили в решаването им ей-така, от любов към спорта. Предвижда също така и бъдещите проблеми, които биха могли да се появят през целия живот на продукта, който създава. Една система е толкова по-стабилна, колкото по-малко несигурни места има в нея (не непременно грешни, а просто несигурни). Това се нарича управление на риска.

В случая грешката е очевидна - парсера за осмичните кодове минава преди този за коментарите, или пък се вика рекурсивно. Но щом има една такава грешка, може да има и други, а може след 5 години да се появи отново някъде. Освен това няма общ стандарт дали # е коментар само когато е в началото на реда, само когато е след white space, или навсякъде. Половината парсери го интерпретират по един начин, другата половина - по друг. Например shell-овете го приемат като коментар навсякъде, с изключение на пренесените с \ редове. Следователно това е слабо място и е по-добре да се избягва. Поправянето на грешката не променя по никакъв начин необходимостта от управление на риска. И жалко, че повечето програмисти не мислят като мен, има какво да научат.

Митко

Мдаа, много философтване се изфилософства, никой не пожела да погледне кода. Никога не съм използвал NFS, но от мен да мине, пак ще си мърся ръцете вместо вас :)

Има бъг в кода на nfs-utils. Можеш да послушаш мениджъра-програмист и да си смениш името да директорията, или да оправиш проблема. Файла е support/nfs/export.c, функцията putexportent. Смени

if (iscntrl(esc) || esc == '"' || esc == '\\'|| isspace(esc))

с

if (iscntrl(esc) || esc == '"' || esc == '\\'|| esc == '#' || isspace(esc))

Ако искаш, можеш да изпратиш и patch на хората които поддържат nfs-utils -- мен ме мързи.

Въпрос на приоритети е. Ако за теб е важно и ти пречи да не можеш да сложиш # в името на ресурса, ще се погрижиш да го оправиш. Ако не ти пука - ще го избегнеш.

Според мен несъгласуването на интерпретацията на # си е проблем (макар и не много голям) и си струва да се реши. Просто за да не се налага непрекъснато да го мислиш и избягваш в бъдеще. Още повече в отворения код.

Всъщност, въпросът струва ли си да пишем качествен код ил не (до което всъщност се свежда проблема) е интересен и сега ще ходя да ритна кошера Програмисти, да видим какво ще излезе

Emi danke :-) Az vse pak se nadyavah da e RTFM problem :-)

Според мен е по-скоро въпрос на гледна точка. Митко защитава гледната точка на потребителя, който след като се сдобие с продукта може само да го използва и няма никакъв контрол върху него. От тази гледна точка, единственото което можеш да направиш е да избягваш дефектите. Моята гледна точка е на собственик на продукта, имащ възможност да прави промени. От нея, правилния вариант е да се оправи дефекта, или поне да се опише в документацията.

Когато се използва отворен софтуер и двете гледни точки са възможни. Би било по-добре ако повече хора се чувстваха "собственици", а не "потребители".

Аз не защитавам определена позиция, а определена философия - че не можеш да промениш света, а трябва да се съобразяваш с него. Светът се променя, но бавно, еволюционно.

Да се върнем на конкретната тема. Ще поправиш парсера в собствената си машина или в любимата си дистрибуция. Но в моята няма да е оправен по няколко причини - не възнамерявам да си сменям или ъпгрейдвам дистрибуцията в следващите 5 години и не чета форуми (имам инсталации правени преди 9 години, които все още работят). Някога ще ми се случи да използвам твоя софтуер, който разчита на поправения парсер и поради това няма да тръгне при мен. Но аз в този случай няма да изхвърля дистрибуцията си или сървъра си, а твоя софтуер и ще го заменя с друг, който не се е опитвал да промени света, а се е съобразил с него.

Накратко: няма нищо лошо да се поправи една грешка, но така или иначе през следващите десетилетия трябва да се съобразяваш с нейното съществуване върху милиони инсталации. На колко от тях си "собственик" и за колко дълго време?

Точно към отворения код трябва да се подхожда БЕЗ чувство за собственост, защото нямаш ни най-малка представа от кого, къде и при какви условия ще се ползва. Той трябва да е универсален, стабилен и надежден, и освен това да не изисква от потребителят му да го дописва или да си дописва операционната система. Това е негово право, но не трябва да му бъде задължение. Никой не е казвал, че светът е идеален и справедлив, нали?

Митко

Предпочитам следната философия: не мога да променя целия свят, но в моята област мога да влияя.

Особено ако софтуерът ми е значим. Като цяло, хората предпочитат да си оправят проблемите и постепенно ще се окаже, че той не работи единствено на машини, които не са пипвани от години.

Каквито машини са твърде малко, между другото, и ако ги има, значи вършат работата си перфектно без каквито и да е било промени, така че и да се съобразя, и да не се съобразя с препоръките ти, нов софтуер на тях просто няма да сложиш. Тоест, те не са потенциални платформи, с които да се съобразявам.

Ако все пак слагаш отвреме на време софтуер на тях, очевидно е, че ще слагаш и най-новите бъгфиксове. Говорим си за това, нали, не за нова функционалност, която да заплаши съществуващата услуга. Значи, ще си сложиш, дори без да знаеш, съответния бъгфикс и моят софтуер ще работи и при теб.

Мисленето ти е типично за бизнес решения, в който нямаш контрол или ти струва твърде скъпо поправката на бъгове. На колкото и места да има инсталиран отворен код обаче, при положение че поправката на грешките в него е безплатна, нормално е той да се подменя с най-новия build, изчистен от грешки. Потенциални изключения са embedded системи и места, в които собствениците не са наясно със системата си.

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

Да поясня: говоря за моите клиенти. Които са сериозни хора. Ако говорим за масовия пазар, там се предполага, че обновяването е террор инкогнита за потребителя и обикновено не е направено; в такъв случай просто трябва да се погрижиш да провериш версията на софтуера и да предложиш лесен начин за обновяване.