[ CoyoteKG @ 20.06.2018. 11:51 ] @
Na drugim mestima sam to rešio tako što dodam >/dev/null ali ovde mi ne pomaže

U pitanju je SVN dump. Na nekom Windows serveru imam cygwin, a sa linuxovog servera koji mi sluzi za backup sam napisao ovu skriptu i cronom je pokrecem.

#!/bin/bash
TODAY=$(date +"%F")
DELETEOLD=$(date --date="-7 days" +"%Y-%m-%d")
mkdir /var/backup/VisualSVN/$TODAY/
repositories=`ssh bckp@78.47.xxx.xxx 'ls /cygdrive/c/SVN/Repositories/ | grep -Ev "(groups.conf|htpasswd|VisualSVN-GlobalWinAuthz.ini)"'`
for rep in $repositories; do
svnrdump dump --username bckp --password "nekipass" https://svn.xxx.xxx:8443/$rep | gzip > "/var/backup/VisualSVN/$TODAY/$TODAY-$rep.dump.gz"
done

YESTERDAY=$(date --date="-1 days" +"%Y-%m-%d")
rm -rf "/var/backup/VisualSVN/$DELETEOLD"


Problem je što mi na mail stigne cronjob rezultat sa par hiljada redova, i onda mi je nepregledno ako dobijem neki error mogu da ga ne primetim.

[ jonathan @ 20.06.2018. 13:05 ] @
Code:

bash-4.3$ svnrdump help dump
dump: usage: svnrdump dump URL [-r LOWER[:UPPER]]

Dump revisions LOWER to UPPER of repository at remote URL to stdout
in a 'dumpfile' portable format.  If only LOWER is given, dump that
one revision.

Valid options:
  -r [--revision] ARG      : specify revision number ARG (or X:Y range)
  -q [--quiet]             : no progress (only errors) to stderr
 .... itd ... itd ...


pp0z, Alek
[ CoyoteKG @ 20.06.2018. 13:43 ] @
hvala :)
[ Aleksandar Đokić @ 20.06.2018. 18:37 ] @
Ako stdout redirect?

2>&1 ili kako vec
[ CoyoteKG @ 21.06.2018. 09:40 ] @
ovo sto je jonathan napisao, je "korak pre", da uopste mi se svndump komanda "tiho" izvrsi. I to mi radi posao.

No i dalje mi nije jasno zasto mi stdout redirect nije radio u svakom slucaju.
Ako ja to dobro shvatam, ovo sto sam probao sa
skripta.sh >/dev/null
Bi trebalo output da posalje u "null device", i ne bi trebalo da vidim nikakav output na ekranu, osim u slucaju da postoji neki error.
A ako hoću da sakrijem i errore, što u ovom slučaju ne želim, onda bih dodao još i 2>&1 posle /dev/null
[ Burgos @ 21.06.2018. 11:55 ] @
Citat:
-q [--quiet] : no progress (only errors) to stderr


Izgleda da aplikacija podrazumevano šalje i progres na stderr (inače ne bi ni imao ovu opciju),
pa ti zato progres stiže na mejl. Da li se greške ili progres ili bilo šta pišu na stdout/stderr je samo stvar konvencije, programi su slobodni da rade šta god žele (pa da ti i zagorčaju život na ovaj način).
[ CoyoteKG @ 21.06.2018. 12:07 ] @
da jasno. Nisam znao da aplikacije mogu bilo sta da salju na stderr osim gresaka. Dakle ovde je problem bio to sto si citirao, da je bez ovog argumenta -q mi salje i progress na stderr, sto mi nema bas nekog smisla.
[ Aleksandar Đokić @ 21.06.2018. 14:34 ] @
Na Linuxu je kao sto verovatno znas sve "fajl". Postoje razliciti tipovi fajlova... pozaboravio sam sve ali link, char, pipe itd.

Kada se upravlja necim sto je predstavljeno kao fajl poziva se "open" funkcija koja vraca fd - file descriptor koji se dalje koristi (u ioctl npr).

Standard input, output i error su soketi, a imaju file descriptore 0,1,2 i zato mozes u bash-u na taj nacin da uradis redirekciju.

Mozda suvisno, al kad je vec tema o tome...
[ djoka_l @ 21.06.2018. 14:52 ] @
Citat:
CoyoteKG:
da jasno. Nisam znao da aplikacije mogu bilo sta da salju na stderr osim gresaka. Dakle ovde je problem bio to sto si citirao, da je bez ovog argumenta -q mi salje i progress na stderr, sto mi nema bas nekog smisla.


Ima puno smisla i to rade mnoge aplikacije. Uobičajeno je da se progres šalje na stderr, a log na stdout, da bi u slučaju da loguješ stdout imao na ekranu progres (čisto da znaš da ti program nešto radi).
[ CoyoteKG @ 21.06.2018. 15:03 ] @
jasno. Pa da, i onda lepo stave quiet argument kao u ovom slucaju, ako ne zelim da vidim da mi program nesto radi :)

Aleksandre, nista te nisam shvatio :D, ali pogledacu posle
[ Ivan Dimkovic @ 21.06.2018. 16:16 ] @
Citat:
CoyoteKG:
da jasno. Nisam znao da aplikacije mogu bilo sta da salju na stderr osim gresaka. Dakle ovde je problem bio to sto si citirao, da je bez ovog argumenta -q mi salje i progress na stderr, sto mi nema bas nekog smisla.


stderr je fajl kao i svaki drugi, aplikacija je slobodna da upisuje u njega sta god hoce.

Recimo u C-u mozes napisati:

Code:

fprintf(stderr, "sta god");


I to ce raditi.

[ djoka_l @ 21.06.2018. 18:51 ] @
Citat:
Aleksandar Đokić:
Na Linuxu je kao sto verovatno znas sve "fajl". Postoje razliciti tipovi fajlova... pozaboravio sam sve ali link, char, pipe itd.

Kada se upravlja necim sto je predstavljeno kao fajl poziva se "open" funkcija koja vraca fd - file descriptor koji se dalje koristi (u ioctl npr).

Standard input, output i error su soketi, a imaju file descriptore 0,1,2 i zato mozes u bash-u na taj nacin da uradis redirekciju.

Mozda suvisno, al kad je vec tema o tome...


Tipovi fajlova su regularni (-), folderi (d), karakter uređaji (c), blok uređaji (b), imenovani pipe (p), socket (s) i simbolički link (l). Hard linkovi nemaju poseban "tip", na *X sistemima i-node pokazuje na listu blokova koji pripadaju fajlu, ime fajla je hard link na i-node, a svaki fajl može imati više imena (linkova).

stdin, stdout i stderr nisu (obično) socketi, oni se nasleđuju od parent procesa, a ako je program pozvan iz shella, oni su najčešće deskriptori koji pokazuju na /dev/tty (koji je karakter uređaj).

Preusmeravanje se radi sa "|", a taj posao odrađuje shell. Startovanjem neke komande shell radi fork samog sebe, ako ima spajanja kroz pipe, otvara neimenovi pipe i uradi exec komande prethodno zamenjujući u svojoj kopiji stdout (ili sva tri standardna fajla) sa pipe.
[ Branimir Maksimovic @ 21.06.2018. 19:14 ] @
Da, stdout i stderr prikazuju na tty iz koga se startovao proces.
[ Aleksandar Đokić @ 21.06.2018. 22:18 ] @
@djoka_l

Citat:
stdin, stdout i stderr nisu (obično) socketi, oni se nasleđuju od parent procesa, a ako je program pozvan iz shella, oni su najčešće deskriptori koji pokazuju na /dev/tty (koji je karakter uređaj).

Preusmeravanje se radi sa "|", a taj posao odrađuje shell. Startovanjem neke komande shell radi fork samog sebe, ako ima spajanja kroz pipe, otvara neimenovi pipe i uradi exec komande prethodno zamenjujući u svojoj kopiji stdout (ili sva tri standardna fajla) sa pipe.


Hm da, nisu soketi, greska.

Ali se preusmeravanje radi i sa <,>, a "&" oznacava da je u pitanju deskriptor.

Citat:
Hard linkovi nemaju poseban "tip", na *X sistemima i-node pokazuje na listu blokova koji pripadaju fajlu, ime fajla je hard link na i-node, a svaki fajl može imati više imena (linkova).


Sta bese razlika izmedju soft i hard linka... neverovatno kako se pozaboravi.

Dva hardlinka imaju iste i-node-ove, a soft link pravi nove na iste blokove... kad se brise soft link brise se i fajl, a hard link ne?
Ili kad se obrise fajl, hardlink ostaje... strasno :).


Btw, sto se tice i-nodova i blokova postojali su tu neki direktni i indirektni blokovi, o cemu bese tu rec?







[ CoyoteKG @ 21.06.2018. 23:34 ] @
kad imas fajl i napravis hard link nad njim, pa zatim obrises taj originalni fajl, i dalje ces ga imati. Odnosno ja sam to zamislio kao dvoja vrata ka jednom fajlu, i da fajl inicijalno kad se kreira ima taj jedan hard link.
A soft link, je bukvalno kao shortcut u windowsu. Ako obrises originalni fajl, ostajes skroz bez njega, soft link nece raditi.

Uz pomoc hard linkova sam napravio inkrementalni backup zadnjih mesec dana nad fajlovima, i sljaka mi savrseno vec par godina.
To mi je medju prvim skriptama koje sam napisao. Doduse nisam puno.... Ali u to vreme nisam znao o linuxu skoro nista
[ djoka_l @ 22.06.2018. 07:02 ] @
Tačno, s tim da soft link može da pokazuje na drugi fajl sistem, dok hard link mora da bude na istom fajl sistemu. Bukvalno, hard link je zapis u direktorijumu (ime, i-node) dok je soft link fajl u kojem piše na koji fajl pokazuje. Kao .lnk na Win.
[ Aleksandar Đokić @ 22.06.2018. 12:26 ] @
Ok, kad se uradi "open" i dobije fajl deskriptor, taj fd u sustini sadrzi i inode-ove?

edit:

Wiki kaze ovako nesto:

Citat:
file descriptors index into a per-process file descriptor table maintained by the kernel, that in turn indexes into a system-wide table of files opened by all processes, called the file table. This table records the mode with which the file (or other resource) has been opened: for reading, writing, appending, and possibly other modes. It also indexes into a third table called the inode table that describes the actual underlying files
https://en.wikipedia.org/wiki/File_descriptor


Ok, kernel odrzava tabelu koji su fajlovi otvoreni po procesu ( file table ), i tabelu inode-ova gde se fajlovi nalaze.



Code:
struct fdtable {
    unsigned int max_fds;
    struct file __rcu **fd;      /* current fd array */
    unsigned long *close_on_exec;
    unsigned long *open_fds;
    struct rcu_head rcu;
};
https://elixir.bootlin.com/lin...ce/include/linux/fdtable.h#L24




[Ovu poruku je menjao Aleksandar Đokić dana 22.06.2018. u 13:36 GMT+1]