The simple custom shell

26.10.2021 16:25 | Přečteno: 1723× | C | poslední úprava: 26.10.2021 17:56

As the comment to that.

#include <stdio.h>

#include <stdlib.h>
#include <sys/types.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <string.h>
#include <unistd.h>

static char **enviroment;

void command_info()
{
	pid_t pid;
	int status;
	char *parameters[]={"uname", "-a", NULL};
	
	pid=fork();
	if(pid == 0)
	{
		execve("/bin/uname", parameters, enviroment);
		perror("execve");
	}
	else
		wait(&status);
}

int loop()
{
	char buffer[1000];
	
	memset(buffer, 0, 1000);
	
	fgets(buffer, 1000, stdin);
	
	if(strncmp(buffer, "help", 4) == 0)
	{
		puts("Commands: help info exit");
		return 0;
	}
	
	if(strncmp(buffer, "info", 4) == 0)
	{
		command_info();
		
		return 0;
	}
	
	if(strncmp(buffer, "exit", 4) == 0)
	{
		return 1;
	}
	
	return 0;
}

int main(int argc, char **argv, char **env)
{
	enviroment=env;
	
	while(1)
		if(loop()==1)
			break;
	
	return 0;
}

       

Komentáře

[Mayhem]

Co s tim jako? Stringy natvrdo, jejich delky natvrdo, uchylny coding style (nepouzivani zavorek dokonce i u cyklu)...

[debianův fanoušek]

Haters gona hate.

[Rustêj]

To neni hejt ale konstruktivni kritika. Program bezi v nekonecne smycce - zly pattern. Dva krat includuje stejne hacko :) Memset s bufferem? To je potencialni dira a memleak. Proste smazat a prepsat do Rustu bude nejlepsi.

[KKK]

Rust je meme.

[turboPackal]

Pro mne za mne at je i tahounem okamurovy kampane. Kdyz je lepsi jak C, hlavne v sprave pameti tak co resis ?

[KKK]

Rusthead fanatiky.

[turboRaku]

Rust fanatici neexistuji, jsou proste slechta a na c-plebs hledi s despektem. Fanatici jsou Perliste, ti dokazou deseti extatickymi zpusoby ospevovat nejdokonalejsi jazyk na zemi, ktery je tak dokonaly ze na nej uz 10 let nikdo nesahnul ale bude jeste jeden ultimatni zvany Raku. Ale az v roce 2048.

[Mayhem]

Javistum je jedno, becauseWeKnowWeAreBetter(We.THE_BEST);

[Svētlo]

Blbost. Javiste jsou vesmes rozumni lide a vedi, ze java neni zadny zazrak. Ale da se s ni hezky vydelat tak jsou pragmaticti. Pres den javuji v korporatu a vecer rustuji open source Inu uz i Linus jde s dobou a casti kernelu se zacnou delat v rustu.

[Michal Kubeček]

Memset s bufferem? To je potencialni dira a memleak.

Mohl byste tuhle myšlenku nějak objasnit? Samozřejmě by čistší bylo

        memset(buffer, 0, sizeof(buffer));

nebo raději rovnou

        char buff[BUFF_LEN] = {};

nebo

        char buff[BUFF_LEN] = "";

ale jak z inicializace lokální proměnné uděláte memleak, to bych si docela rád poslechl.

Asi je to profesionální deformace, ale spíš mi vadí ten samotný nápad mít takhle velkou proměnnou na stacku.

[johnyK]

mít takhle velkou proměnnou na stacku.

napr. u funkce, ktera pise do logu a jako parametr dostane vetsi text se s ti neco udelat musi.

Co pouzivate potom. Static, malloc, extern ?

Ja pouzivam static uvnitr funkce a priznam se, ze jsem vlastne nikdy nezkousel, kde se to uklada , ja jsem si myslel, ze tyhle permanentni veci by mely skoncit v datovem segmentu, ale jisty si vlastne nejsem. Vi to nekdo na 100%? Co pouzit kdy?

[Michal Kubeček]

Záleží na konkrétní situaci, ale většinou bych upřednostnil dynamickou alokaci, tj. malloc() apod. V jádře je vzhledem k velikosti stacku tlak na šetření hodně velký, ale ani v userspace není dobré si představovat, že je stack nekonečný. Resource limit na velikost stacku (ulimit -s) sice bývá něco jako 8 MB, ale to je pro všechny thready dohromady, takže u multithreadových programů běžně používám stack o velikosti 64 KB nebo dokonce 16 KB - a pak už si rozmyslíte, jestli tak velkou část zaplácnout nějakým bufferem.

[Rustêj]

Kdyz uz bastlis v Ccku tak si neco precti o alokaci pameti, jedine dynamicka je bezpecna. I staticka je delana pres pointry a kdyz ti tam nekdo natriska 1000 emoji tak ani Kernighan s Richiem nebudou vedet kam ta pamet ustreli kamarade. Dej na mou radu, prepis to do Rustu a tohle resit pak nemusis.

[johnyK]

kdyz se v nejake funkci misto stovek lokalnich definec nejakych bufferu udelaji malloc-y, a ta funkce se milionkrat vyvola, tak to ma dve vyhody:

- je mozne si jit udelat kafe, protoze to trochu trva

- to kafe je mozno si ohrat hned na tom procesoru

Kdyz se navic ty malloc-y trochu parametrizujou, tak je mozno takovy program nasadit jako memtest utilitu ...

at zije Rust a vsechny moderni programy

P.S. jeste takovou PERLicku:

my dodavame programy do firmy, ktera se nachazi v obci Rust a kolega kdysi delal nekolik excelovych zpracovani pro mestsky urad v obci Perl. Je zajimave, ze pro radu programu existuje obec, ktera se zrovna tak jmenuje

[jiwopene]

my dodavame programy do firmy, ktera se nachazi v obci Rust a kolega kdysi delal nekolik excelovych zpracovani pro mestsky urad v obci Perl. Je zajimave, ze pro radu programu existuje obec, ktera se zrovna tak jmenuje

+ ještě Kotlin a Java.

Lua, Saint-Python, Cobol, Fortran, Scala, C++, Ruby, …

[Rustêj]

S necim si to pletes. Jak malloc tak memset ma svou alokacni rezii, ktera je (z hlediska OS) temer stejna. Tebou popisovany pripad je blbost uz sama o sobe, nikdo by to takhle nedelal a pouzil by globalnejsi store. A v Perlu jim vypust pythona

[Heron]

Když je tu tolik Rustařů, nechcete o tom napsat nějaký motivační / bootovací článek? Používám golang, jsem s ním spokojený, dokonce už jsem si zvykl na hroznou syntax, ale tak nějak cítím, že vlastně chci rust, ale s jednoduchostí golangu / pythonu.

Golang je super v několika věcech. Jedna statická binárka. Crosscompilace v základu (vůbec ty tools jsou navržené dobře). Na widlích pomocí dvou příkazů udělám binárky pro freebsd i linux. Velmi snadný koncept paralelizace. Kanály jsou tak nějak přesně to, co chci. Statické a silné typování. Rád vytvářím specifické typy a k nim metody (i když syntaxe func receiver je teda hrozná). Automatická správa paměti.

Teď odvrácená strana. Výkon rustu je 3x větší (což je mi vlastně jedno, před dvěma lety jsem to měl v pythonu), ale proč si ho nevzít. Rust má skvělý borrow checker. Resp. celý systém varování kompilátoru. Tohle mne zaskočilo asi nejvíc, golang má statickou silnou kontrolu a přes to mu zjevné věci unikají. Nějak jsem se tomu vyhnul, ale jednou to přijde. (Ve skutečnosti největší problém, na který jsem na počátku narážel bylo to, kdo a kdy má uzavírat channel. Někde jsem viděl, že rust compiler dokáže detekovat deadlock už během kompilace.)

Největší problém rustu vidím v komplikované cross compilation. Možná se to pohlo, nemám čas to sledovat. Vůbec nevím, jak je to se standardní knihovnou. Vždy se, pokud je to možné, vyhýbám externím závislostem. Jasně, driver pro databázi tak nějak potřebujete vždy. Knihovnu pro escape sekvence pro barvičky v terminálu importovat nechci. (To si ji raději napíšu sám.)

Potom syntax. Moc se mi nelíbí to označování mut, move, (borrow) apod. Podle mého názoru by si to měl vyřešit compiler. V golangu je garabge collector, všechno se by default kopíruje (bohužel i pointery) a kdo chce, může používat reference (ale zase, každou proměnnou označovat hvězdičkou... prostě ta syntax je divná).

[jiwopene]

Co se týče cross-kompilace, tak mám s Rustem celkem dobré zkušenosti (asi letošní březen) – nainstaloval jsem toolchain (kompilátor + std + …), zkompiloval pro armv7 (na amd64) a fungovalo to.

Jinak jsem v opačné situaci – používám Rust, ale neustále si říkám, že bych měl zkusit Golang.

S move s Vámi soublasím – to by měl řešit spíš kompilátor. Na druhou stranu, proti let mut/mut nic nemám (pořád hezčí než const v C++) – alespoň si v tom musím udělat jasno předem. (Kotlin má val (jako let) a var (jako let mut) a tam mě to spíš obtěžuje, zčásti protože si tato klíčová slova jsou tak podobná, že se snadno spletou.)

[Heron]

Ano, ten koncept, že je všechno immutable a je nutné označit mutable se mi líbí víc, než naopak psát const a potom na to někde zapomenout.

[Martin Tůma]

Asi je to profesionální deformace, ale spíš mi vadí ten samotný nápad mít takhle velkou proměnnou na stacku.

Mě teda spíš vadí to, že má takhle velkej buffer, když do něj čte maximálně 4 byty... Víc commandů za sebou to neumí, zbytek načteného bufferu stejně zahazuje. Kdyby tam měl odpovídající - 4 bytovej buffer - tak si ho dovedu na stacku klidně představit i v kernelu . Celkově bych to nazval jako "céčko od ne-céčkaře" (vyloženě z toho čiší neznalost základních principů, jako co je v C string a jak je reprezentovaný, co je stream a jak funguje standardní vstup, ...). Nějak takhle asi vypadaj moje programy v pythonu .

[vlastikroot]

Asi je to profesionální deformace, ale spíš mi vadí ten samotný nápad mít takhle velkou proměnnou na stacku.

Podle me 1000 bytu je mala promena, pokud se bavime o platforme, kde nejmensi velikost pridelene pameti na stack je jedna stranka (takze da se rict kazda platforma s MMU). Pokud uz je stack naalokovany, je to nejefektivnejsi metoda, jak ziskat docasnou pamet - jen se navysi stack pointer (proto ma alloca obcas svuj smysl, treba kod llvm je toho plny).

[Michal Kubeček]

Podle me 1000 bytu je mala promena, pokud se bavime o platforme, kde nejmensi velikost pridelene pameti na stack je jedna stranka (takze da se rict kazda platforma s MMU).

A taková proměnná vám zabere čtvrtinu té stránky, to je docela dost, aby se nad tím vývojář aspoň řádně zamyslel. Nemluvě o tom, že v civilizovaném programu těch 1000 nebude natvrdo zadrátovaná konstanta, čímž se problém posouvá na novou úroveň. (Viz např. čistka VLA v jádře pár let zpátky.)

proto ma alloca obcas svuj smysl, treba kod llvm je toho plny

Snad jsou aspoň trochu prozíravější než autor resolveru v glibc, který také miluje alloca(), ale bohužel má malou představivost ohledně toho, jak velká může být odpověď nebo kolik IPv6 adres může host používat, takže ten zásobník tu a tam přeteče…

[vlastikroot]

To jakoze ten glibc resolver dokaze vyzrat ten defaultni nekolikamegovy stack ? Nebo se jedna o nejaky nedefaultni runtime?

[Michal Kubeček]

V tom případě, který jsem řešil, to stačilo to na přetečení stacku v nějaké javové aplikaci. Velikost byla IIRC 256 KB a podle všeho to byl default, nijak s jeho velikostí nehýbali.

[z_sk]

Co s tim jako?

Reakce na tohle: https://www.abclinuxu.cz/poradna/linux/show/473630

[🇹🇬]

jaktože to jakoby má jenom 23 zobrazení ale už 12 hlasů :D

[z_sk]

Zo začiatku bol v náhľade o blogu aj kód, teraz už nie je.

[🇹🇬]

ok tudlectu výmluvu žeru ;D ;D

[Bherzet]

A (skoro) všechny pozitivní. Od té doby průměr klesá.

[_]

Zbytečné:

while(1)
        if(loop()==1)
            break;

Stačí naspat:

while(loop() != 1)

nebo == 0, ale to může mít jiný význam v závislosti na tom, jaké hodnoty vracíš.

[🇹🇬]

while(!loop());

[Mayhem]

Hlavne pouzivani cisel jako pravdivostnich mi prijde prasarna v dobe, kdy mame stdbool.h. Take vracet cislo je prasarna, kdyz v stdlib mame EXIT_*..

[bul]

EXIT* jsou jen konstanty pro cisla :) Nekdo ma pamet na vyrazy, nekdo zas na cisla. Ve vysledne binarce to bude stejne.

[Mayhem]

Ja vim, ale radeji vidim true/false a EXIT_* nez return 0/1, while(1), atd. Pro citelnost kodu mi to prijde zasadni. O globalni promenne, literalech natvrdo, delkach na tvrdo, zavorkach, mega polech na stacku, atd. radeji pomlcim. Pak ma to cecko nejak vypadat, kdyz zacatecnici vidi toto a povazuji to za normu.

[Mayhem]

Na druhou stranu, nechci hanet autora kodu. Pokud mu jeho dilo plni ucel a nepada, pak je vsechno v poradku. Priste uz napise kod jiste citelneji.

[sojovy uherak]

Ale my nehanime autora. My delame code review tomu paskvilu co vyprodukoval, to je rozdil

[Aleš Kapica]

… radeji vidim true/false a EXIT_* nez return 0/1, while(1), atd.

Souhlasím. Mám také raději „ukecanější” kód ze kterého je jasné co se kdy děje, než rébusy, u kterých lze návratovou hodnotu snadno zaměnit. Číselné hodnoty využívám jako návratovou hodnotu jen tam, kde potřebuji odchytnout konkrétní místo.