Názory k článku Programovací jazyky z vývojářského pekla++

Ale i Fortran má (měl) krásné mouchy. Jednou z nich je, že ve Fortranu se nedeklaruje u parametrů procedur, jestli jsou vstupní nebo výstupní a kompilátor ani nemá žádnou možnost, jak to kontrolovat. Takže je možné zavolat proceduru, která používá parametr jako výstupní, a předat jí konstantu. A pokud jste takto proceduře, která vracela 2, předali jako parametr konstantu 1, tak od té doby všechny konstanty 1 v programu měly ve skutečnosti hodnotu 2. Asi si dovedete představit, jak dobře se podobné chyby hledaly.

Stroj času není třeba, do minulosti můžeme cestovat na jedno kliknutí. V DOSBoxu se dá nabootovat image diskety a je o zábavu postaráno. Po netu se toho válí, třeba jako bootdisky nebo JS emulátor PC-XT ;-)

Svět není jenom UNIX. Například CP/M i VMS používaly zařízení s dvojtečkou, řekněme A:, NUL: nebo SYS$SYSDEVICE:. Na VMS jste mohl mít cestu k souboru typu SYS$SYSDEVICE:[U­SER.DOCS]PHOTO­.JPG;5. Jediné co na tom překvapí je to že to uživatelé Unixů považují za zvláštní, zatímco /dev/hda, hjkl-esc a escapování v shellu jim přijdou přirozené koncepty :)

Zajímaly by mě ale ty "prapodivné" příznaky u souborů. Co konkrétně máte na mysli?

Atribut FILE_ATTRIBUTE_HID­DEN říká, že se soubor či adresář nemá prezentovat uživateli v běžném výpisu souborů. Na Unixech děláte totéž pokud jméno souboru či adresáře začíná tečkou. Atribut mi osobně připadá vhodnější.

Atribut FILE_ATTRIBUTE_RE­ADONLY dělá zjevné, soubor nelze smazat nebo zapsat. Na FAT jiné permissions nebyly, protože single-user.

Atribut FILE_ATTRIBUTE_SYS­TEM označuje soubory, které (exkluzivně) využívá systém. Například swap file.

Atribut FILE_ATTRIBUTE_AR­CHIVE je celkem praktický pro zálohy. Když soubor vytvoříte nebo modifikujete, flag se nastaví. Když soubor odzálohujete, vynuluje se. Při inkrementální záloze stačí zálohovat to co má nastavený FILE_ATTRIBUTE_AR­CHIVE. Čas modifikace by teoreticky šlo použít také, ale neřekne vám to co bylo už zkopírované pokud proces přerušíte.

Jenze tak je to u nich se vsim :-) Na prvni pohled to vypada jednoduse ("nastavime tady priznak a je to"), jenze v praxi se teprve ukaze, jak je to nedomyslene a musi se to patchovat a patchovat.

Příkaz DELTREE byl zaveden proto aby existoval rozumný způsob, jak smazat podstrom bez ohledu na cokoliv, včetně atributu FILE_ATTRIBUTE_RE­ADONLY. Ona ta utilita může atribut FILE_ATTRIBUTE_RE­ADONLY změnit stejně jako uživatel.

FILE_ATTRIBUTE_AR­CHIVE je super řešení pro jednoduché scénáře. Datum+čas modifikace se také dá použít, s tím že na FAT má přesnost jen dvě sekundy (a dá se změnit přes API, v DOSu i triviálně přímým přístupem na disk). Checksumy jsou trochu nešťastné, protože vyžadují přečtení celého souboru.

Na tech VMSovejch cestach mi az tak divnyho nic neprijde, trochu me tam prekvapila kdysi ta verze, to je neco navic. hjkl je celkem logickej pristup v dobe terminalu bez kurzorovejch klaves. Shell bez escapovani nemuze plnohodnotne fungovat, bavit se muzem o tom, kolik escapovacich zpusobu v jenom jazyce ma smysl.

Jak se systemem zarizeni a konvencemi pro FS tim souvisi hjkl-esc?

Btw takove A: nebo NUL: si muzu udelat taky symlinkem, naopak to moc nepujde.

On i MS-DOS měl příkaz mount. Tedy ne, že by někdy fungoval...

Jen nekdo, kdo naprosto ztratil smysl pro realitu (cti "MS") mohl jmena zarizeni naveky rezervovat. Pro ty, kdo se s timto fenomenem nesetkali:

1) v DOSu se sice jmena zarizeni nekdy pisou s dvojteckou na konci NUL: ale ve skutecnosti je ta dvojtecka nadbytecna, takze staci jen NUL
2) konsekvene - neni mozne, nezavisle na adresari, vytvorit soubor stejneho jmena, nikde
3) jmena zarizeni se postupne pridavala a ubirala, takze se lucebnik mohl dockat neprijemneho prekvapeni

(jo a vyuzivalo to ruzne malware, ktere nejakym primym zapisem mohlo vytvorit napriklad adresar, do ktereho uzivatel nemohl atd.)

Souhlas že je trochu nešťastné, že rezervovaná jména zařízení fungují i bez dvojtečky. Vytvoření souboru stejného jména je ale nepravděpodobné, protože soubory v DOSu (i Windows) mají typicky příponu. A rezervovaná jména zařízení jsou jen CON, PRN, AUX, NUL, COMx a LPTx, kde x je 1-9. Nevím jestli byla všechna už v DOSu 1.0, ale nepřipadá mi, že by šlo o nějaké divoké změny.

Ad vyuzivalo to ruzne malware, ktere nejakym primym zapisem mohlo vytvorit napriklad adresar, do ktereho uzivatel nemohl atd. - do takového adresáře se samozřejmě lze dostat. Není to triviální, ale když si vytvoříte na Linuxu adresář se znaky 0x0d a 0x7f, tak se s ním také budete tak trochu prát. Ještě víc se pobavíte, když ve jménu bude "správná" terminálová (ANSI/xterm) sekvence.

AUX zmizel v propadlišti dějin, společně s CLOCK, který se vyskytoval jenom v některých verzích.

No, v Unixu stačí ls -b, případně find . a hned víte, co se děje. A díky skvělýmu escapeování v shellu není žádnný problém s takto pojmenovanými soubory pracovat. V MS-DOSu, pokud vám někdo podobný soubor vytvořil, jste neměl jinou šanci, jak s tím manipulovat (či jen zjistit, že to tam je), než si napsat program (opravdoví programátoři samozřejmě napsali rovnou strojový kód v debugu) a to těžko udělá běžný uživatel.

No vidis, ono jich je vic:
CON, PRN, AUX, CLOCK$, NUL
COM1, COM2, COM3, COM4
LPT1, LPT2, LPT3, LPT4
KEYBD$, SCREEN$ (pro jistotu jen nekde a nekdy)
CONFIG$ (opet jen nekde a nekdy)

Ty kousky s dolarem jsou názvy konkrétních driverů, které v DOSu mohou a nemusí existovat. Nejsou to rezervované názvy souborů.

Ad jde i o adresáře - souhlas, tam je to trochu nepříjemnost

Ad navíc se tato věc dostala i do Windows (tam tedy mimochodem pro NTFS přidali dalších asi deset speciálních a rezervovaných názvů - Windows mají z důvodu zpětné kompatibility ty samé rezervované názvy jako DOS.

Ad do těchto rezervovaných se není problém strefit při práci v úplně odlišné oblasti - existuje řada stringů, které nelze použít jako název adresáře. Pokud píšete aplikaci, je dobré si přečíst dokumentaci. A ta hovoří celkem jasně:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

Super, přesně takovou odpověď jsem čekal :-) Takže máme sice řešení na dvě věci (protože jsme při opisování z CP/M a potom z shellu moc nepřemýšleli, vic / versus -), ale tím, že se tyto issues (nic jiného to není) napíšou někam do dokumentace se to jakoby vyřeší a blbci jsou uživatelé nebo vývojáři. Díky, to už stačilo, zcela přesně to vystihuje pohled MS na svět SW :-)

Ad při opisování z CP/M a potom z shellu moc nepřemýšleli, vic / versus - - to máte na mysli tu legendu že MS opsal / jako oddělovač parametrů z CP/M, a kvůli tomu musel jako oddělovač adresářů vybrat \? Myslím že je to nesmysl. Svět není jenom Unix. Koukněte se na formáty cesty použité v různých OS:
SYS$SYSDEVICE:[U­SER.DOCS]PHOTO­.JPG;5 -- oddělovač adresářů je '.'
%sysname#modu­le1>SubDir>Anot­herDir -- oddělovač adresářů je '>'
Macintosh HD:Documents:Letter -- oddělovač adresářů je ':'

Mimochodem ve Windows můžete jako oddělovač adresářů klidně použít /, protože API ho přeloží na \.

Ohledně rezervovaných jmen souborů: je to prostě legacy. Na Unixech máte podobné historie celý nákladní vlak. Včetně toho že na RAIDu nejde vytvořit 16 partition (ale žádná utilita neřekne proč - až v "dokumentaci" kernelu se člověk dočte o major a minor number), jména souborů mohou obsahovat netištitelné znaky a terminálové sekvence, klíčenky s unixovými FS jsou bez roota nepoužitelné díky permissions, potom třeba celé to harakiri okolo terminálů, drsné travesty show jménem X11, fakt že POSIX neobsahuje API ani pro základní operace se službami/daemons a správu síťových zařízení apod. A uživatel je ve všech těchto případech na posledním místě, jak je na Unixech dobrým zvykem :)

"Ad při opisování z CP/M a potom z shellu moc nepřemýšleli, vic / versus - - to máte na mysli tu legendu že MS opsal / jako oddělovač parametrů z CP/M, a kvůli tomu musel jako oddělovač adresářů vybrat \? Myslím že je to nesmysl."

No a proto napriklad služba v CP/M pro tisk řetězce vypadá takto:
- číslo callu: 9
- adresa řetězce: v DE (registrový pár)
- řetězec ukončen znakem $

Podobná služba v DOSu:
- číslo callu: 9
- adresa řetězce: DS:DX (jsme na zcela odlišném CPU, takže proto)
- řetězec ukončen znakem $

No na to, že se jedná o jiné systémy na kompletně odlišnou architekturu se tedy MS trefil móc pěkně :-)
Ty náhody...

Tu legendu o / a \ jsem se dozvěděl někdy začátkem devadesátých let, kdy to byla ještě celkem čerstvá zpráva. O major a minor number jsem četl v dokumentaci M$-DOSu. Harakiri okolo terminálů jsem nezaznamenal. X11 je geniální věc z osmdesátých let, dnes trochu antika. Windows jsou geniální věc ze sedmdesátých let, pravěk. POSIX obsahuje všechno co je potřeba, tuhle jsi vychvaloval Widle že ho také splňují. Kde tam máš démony?

Mimochodem, jsi vtipný jak Petr Novotný týden před smrtí.

Coz 0x0d nebo 0x7f, to celkem jde. Velkej problem dela 0x00, ale to bude asi ve vetsine OS pouzivajicich klasicky C retezce. Jedinej jinej znak u kteryho aspon podle moji zkusenosti v UNIXu nejede vlak je "/", opravte me, pokud se mylim.

Je to tak. Struktura adresáře je (nebo aspoň byla) posloupnost záznamů (inode, name) kde name je ukunčené NUL, takže uvnitř NUL být nemůže (není tam žádný escapeovací mechanismus).

A lomítko je už ve voláních jádra interpretováno jako oddělovač adresářů, opět bez možnosti escapeovat.

Takže pokud do adresáře propašujete NUL, tak ho rozbijete. Pokud tam propašujete lomítko, tak vytvoříte nepřístupný záznam.

NUL jde do jména propašovat jen na filesystémech, které používají řetězce s délkou. Většina linuxových FS ovšem používá klasické céčkové zero-terminated stringy (buď ve specifikaci, nebo v implementaci).
Lomítko i NUL ale neprojde přes volání jádra, takže jediný způsob jak to tam dostat, je bez vědomí jádra (přímý přístup na disk, nebo v jiném operačním systému). Tam kde se takové znaky dají čekat, to kód filesystému v linuxovém kernelu typicky nějak řeší. (Většinou ty znaky nahradí nečím jiným).