Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user.catalan > #6502 > unrolled thread
| Started by | orestes@riseup.net |
|---|---|
| First post | 2020-12-19 19:50 +0100 |
| Last post | 2020-12-20 15:40 +0100 |
| Articles | 13 — 10 participants |
Back to article view | Back to linux.debian.user.catalan
Problemes amb automysqlbackup combinat amb un "locale" en català orestes@riseup.net - 2020-12-19 19:50 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català Narcis Garcia <debianlists@actiu.net> - 2020-12-19 20:00 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català Eloi <entfe001@gmail.com> - 2020-12-19 21:00 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català Toni Mas Soler <antomassol@gmail.com> - 2020-12-20 04:00 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català Ernest Adrogué <nr9@posteo.de> - 2020-12-20 10:10 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català Joan Montané <jmontane@gmail.com> - 2020-12-20 10:50 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català Ernest Adrogué <nr9@posteo.de> - 2020-12-20 11:10 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català Josep Lladonosa <jlladono@gmail.com> - 2020-12-20 12:00 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català Joan Montané <jmontane@gmail.com> - 2020-12-20 12:30 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català Eloi <entfe001@gmail.com> - 2020-12-20 13:40 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català julio <jamoros@correu.escoladeltreball.org> - 2020-12-20 14:10 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català Orestes Mas <orestes@riseup.net> - 2020-12-20 14:20 +0100
Re: Problemes amb automysqlbackup combinat amb un "locale" en català Orestes Mas <orestes@tsc.upc.edu> - 2020-12-20 15:40 +0100
| From | orestes@riseup.net |
|---|---|
| Date | 2020-12-19 19:50 +0100 |
| Subject | Problemes amb automysqlbackup combinat amb un "locale" en català |
| Message-ID | <BnPsJ-hI-5@gated-at.bofh.it> |
Benvolguda llista, a veure si em podeu ajudar en una cosa:
Uso automysqlbackup per fer les còpies de seguretat d'una base de dades.
Tot funciona correctament excepte els backups mensuals, atès que tinc el
locale del sistema en català i la majoria de mesos tenen un espai en el
nom, cosa que fa que el backup falli. Com a mostra, aquest és el llistat
del directori on van a parar els backups mensuals:
root@circuits:/home/automysqlbackup/monthly/moodle# ll
total 26052
-rw------- 1 root root 12393310 d’ag. 1 06:25
moodle_2020-08-01_06h25m.d’agost.moodle.sql.gz
-rw------- 1 root root 0 de set. 1 06:25
moodle_2020-09-01_06h25m.de
-rw------- 1 root root 14282383 d’oct. 1 06:25
moodle_2020-10-01_06h25m.d’octubre.moodle.sql.gz
-rw------- 1 root root 0 de nov. 1 06:25
moodle_2020-11-01_06h25m.de
-rw------- 1 root root 0 de des. 1 06:25
moodle_2020-12-01_06h25m.de
Veieu? Només s'han creat bé els d'agost i octubre perquè aquests mesos
l'article va apostrofat i no hi ha espais en blanc en el nom.
Fent una mica de recerca he pogut deduir l'origen del problema i fins i
tot sabria solucionar-lo, però voldria saber si hi ha alguna manera
millor de la que jo penso. M'explico:
"automysqlbackup" és un script situat a /usr/sbin. Les línies rellevants
d'aquest script són les següents:
----------------------------
DATE=`date +%Y-%m-%d_%Hh%Mm` # Datestamp e.g
2002-09-21
DOW=`date +%A` # Day of
the week e.g. Monday
DNOW=`date +%u` # Day number of
the week 1 to 7 where 1 represents Monday
DOM=`date +%d` # Date
of the Month e.g. 27
M=`date +%B` # Month
e.g January
W=`date +%V` # Week
Number e.g 37
----------------------------
...
----------------------------
# Monthly Full Backup of all Databases
(...)
dbdump "$MDB" "$BACKUPDIR/monthly/$MDB/${MDB}_$DATE.$M.$MDB.sql"
----------------------------
O sigui que usa "dbdump" (que és una funció definida en un altre lloc de
l'script i acaba usant "mysqldump") amb un nom de fitxer que expandeix
la variable "$M", la qual és el resultat de "date +%B" que, en un
sistema amb locale en català donarà "de desembre" si l'executeu avui,
per exemple.
Tal i com ho veig jo, podria fer el següent:
1) Canviar el "locale" del sistema, el problema és que és un servidor
que córre un Moodle i si canvio el locale del sistema hi ha algunes
cosetes del moodle que surten en anglès.
2) Canviar l'script del automysqlbackup per tal que no posi el nom del
mes, el posi sense espai o alguna cosa semblant. El problema que hi veig
és que ho hauria de refer en cada actualització del automysqlbackup. No
em sembla una bona idea.
3) Potser podria fer un terme mig i crear una configuració "local" del
automysqlbackup, que no es veuria sobreescrita en actualitzar el paquet,
i que forcés un "locale" anglès en executar-se. Potser és la millor
manera però, ni que sigui per curiositat, hi ha alguna manera
d'arreglar-ho preservant el nom del mes en català? Com ho faríeu
vosaltres?
Gràcies!
Orestes.
[toc] | [next] | [standalone]
| From | Narcis Garcia <debianlists@actiu.net> |
|---|---|
| Date | 2020-12-19 20:00 +0100 |
| Message-ID | <BnPCq-l5-9@gated-at.bofh.it> |
| In reply to | #6502 |
Jo ho faig amb admidb, i programo les còpies a /etc/cron.daily/...
Narcis Garcia
__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 19/12/20 a les 19:48, orestes@riseup.net ha escrit:
> Benvolguda llista, a veure si em podeu ajudar en una cosa:
>
> Uso automysqlbackup per fer les còpies de seguretat d'una base de dades.
> Tot funciona correctament excepte els backups mensuals, atès que tinc el
> locale del sistema en català i la majoria de mesos tenen un espai en el
> nom, cosa que fa que el backup falli. Com a mostra, aquest és el llistat
> del directori on van a parar els backups mensuals:
>
> root@circuits:/home/automysqlbackup/monthly/moodle# ll
> total 26052
> -rw------- 1 root root 12393310 d’ag. 1 06:25
> moodle_2020-08-01_06h25m.d’agost.moodle.sql.gz
> -rw------- 1 root root 0 de set. 1 06:25
> moodle_2020-09-01_06h25m.de
> -rw------- 1 root root 14282383 d’oct. 1 06:25
> moodle_2020-10-01_06h25m.d’octubre.moodle.sql.gz
> -rw------- 1 root root 0 de nov. 1 06:25
> moodle_2020-11-01_06h25m.de
> -rw------- 1 root root 0 de des. 1 06:25
> moodle_2020-12-01_06h25m.de
>
> Veieu? Només s'han creat bé els d'agost i octubre perquè aquests mesos
> l'article va apostrofat i no hi ha espais en blanc en el nom.
>
> Fent una mica de recerca he pogut deduir l'origen del problema i fins i
> tot sabria solucionar-lo, però voldria saber si hi ha alguna manera
> millor de la que jo penso. M'explico:
>
> "automysqlbackup" és un script situat a /usr/sbin. Les línies rellevants
> d'aquest script són les següents:
>
> ----------------------------
> DATE=`date +%Y-%m-%d_%Hh%Mm` # Datestamp e.g
> 2002-09-21
> DOW=`date +%A` # Day of
> the week e.g. Monday
> DNOW=`date +%u` # Day number of
> the week 1 to 7 where 1 represents Monday
> DOM=`date +%d` # Date
> of the Month e.g. 27
> M=`date +%B` # Month
> e.g January
> W=`date +%V` # Week
> Number e.g 37
> ----------------------------
> ...
> ----------------------------
> # Monthly Full Backup of all Databases
> (...)
> dbdump "$MDB" "$BACKUPDIR/monthly/$MDB/${MDB}_$DATE.$M.$MDB.sql"
> ----------------------------
>
> O sigui que usa "dbdump" (que és una funció definida en un altre lloc de
> l'script i acaba usant "mysqldump") amb un nom de fitxer que expandeix
> la variable "$M", la qual és el resultat de "date +%B" que, en un
> sistema amb locale en català donarà "de desembre" si l'executeu avui,
> per exemple.
>
> Tal i com ho veig jo, podria fer el següent:
>
> 1) Canviar el "locale" del sistema, el problema és que és un servidor
> que córre un Moodle i si canvio el locale del sistema hi ha algunes
> cosetes del moodle que surten en anglès.
>
> 2) Canviar l'script del automysqlbackup per tal que no posi el nom del
> mes, el posi sense espai o alguna cosa semblant. El problema que hi veig
> és que ho hauria de refer en cada actualització del automysqlbackup. No
> em sembla una bona idea.
>
> 3) Potser podria fer un terme mig i crear una configuració "local" del
> automysqlbackup, que no es veuria sobreescrita en actualitzar el paquet,
> i que forcés un "locale" anglès en executar-se. Potser és la millor
> manera però, ni que sigui per curiositat, hi ha alguna manera
> d'arreglar-ho preservant el nom del mes en català? Com ho faríeu
> vosaltres?
>
> Gràcies!
>
> Orestes.
>
[toc] | [prev] | [next] | [standalone]
| From | Eloi <entfe001@gmail.com> |
|---|---|
| Date | 2020-12-19 21:00 +0100 |
| Message-ID | <BnQyt-Tm-3@gated-at.bofh.it> |
| In reply to | #6502 |
Comento entre solucions i retallo part del missatge
El 19/12/20 a les 19:48, orestes@riseup.net ha escrit:
> Benvolguda llista, a veure si em podeu ajudar en una cosa:
>
> [...]
>
> Fent una mica de recerca he pogut deduir l'origen del problema i fins i
> tot sabria solucionar-lo, però voldria saber si hi ha alguna manera
> millor de la que jo penso. M'explico:
>
> "automysqlbackup" és un script situat a /usr/sbin. Les línies rellevants
> d'aquest script són les següents:
>
> ----------------------------
> DATE=`date +%Y-%m-%d_%Hh%Mm` # Datestamp e.g
> 2002-09-21
> DOW=`date +%A` # Day of
> the week e.g. Monday
> DNOW=`date +%u` # Day number of
> the week 1 to 7 where 1 represents Monday
> DOM=`date +%d` # Date
> of the Month e.g. 27
> M=`date +%B` # Month
> e.g January
> W=`date +%V` # Week
> Number e.g 37
> ----------------------------
> ...
> ----------------------------
> # Monthly Full Backup of all Databases
> (...)
> dbdump "$MDB" "$BACKUPDIR/monthly/$MDB/${MDB}_$DATE.$M.$MDB.sql"
> ----------------------------
>
> O sigui que usa "dbdump" (que és una funció definida en un altre lloc de
> l'script i acaba usant "mysqldump") amb un nom de fitxer que expandeix
> la variable "$M", la qual és el resultat de "date +%B" que, en un
> sistema amb locale en català donarà "de desembre" si l'executeu avui,
> per exemple.
Crec que part del problema pot venir, precisament, d'aquesta la funció
dbdump (no uso mysql i no ho puc verificar). Tenir espais en blanc a
noms de fitxer, tot i que en general és bona pràctica evitar-los, no
hauria de ser un problema sempre i quan s'escapin correctament les
variables. En aquest sentit, l'ús de les cometes dobles és correcte en
aquest punt, i el nom del fitxer (així com el del directori) haurien de
ser tolerants.
Em fa la fila que, en algun lloc de la funció shell dbdump, hi haurà un
$2 en lloc d'un "$2" a l'hora d'escriure el fitxer de sortida. A menys
que se sàpiga del cert que no hi haurà espais en blanc o que precisament
interessi que els espais impliquin una separació d'elements, tota
referència a una variable de shell jo la posaria entre cometes dobles
(compte, que les simples signifiquen quelcom ben diferent!)
> Tal i com ho veig jo, podria fer el següent:
>
> 1) Canviar el "locale" del sistema, el problema és que és un servidor
> que córre un Moodle i si canvio el locale del sistema hi ha algunes
> cosetes del moodle que surten en anglès.
No necessites canviar el locale del sistema, només el del propi shell,
ja sigui cridant-lo passant com a prefix:
LC_ALL=C automysqlbackup
En general, per a scripts de backups que usen dates no és mala idea,
especialment si s'usen noms literals de mes o del dia de la setmana,
cosa que personalment evito perquè pots acabar amb una col·lecció de
còpies amb noms inconsistents entre elles si s'han generat amb locales
diferents
> 2) Canviar l'script del automysqlbackup per tal que no posi el nom del
> mes, el posi sense espai o alguna cosa semblant. El problema que hi veig
> és que ho hauria de refer en cada actualització del automysqlbackup. No
> em sembla una bona idea.
Jo obriria un bug, precisament per evitar el que deia en en paràgraf
anterior
> 3) Potser podria fer un terme mig i crear una configuració "local" del
> automysqlbackup, que no es veuria sobreescrita en actualitzar el paquet,
> i que forcés un "locale" anglès en executar-se. Potser és la millor
> manera però, ni que sigui per curiositat, hi ha alguna manera
> d'arreglar-ho preservant el nom del mes en català? Com ho faríeu
> vosaltres?
Pots crear un shell on preparis configuracions, com la del locale, i fer
servir aquest script. Fins i tot podries arribar a donar-li el mateix
nom i posar-lo en una ubicació amb major prioritat al path (cosa que
personalment no m'agrada), sempre que l'script es cridi sense ruta absoluta.
En el teu cas podria ser una cosa tan simple com això:
#!/bin/sh
export LC_ALL=C
automysqlbackup "$@"
Pel que fa a poder mantenir els noms dels mesos en català, una altra
alternativa seria tocar el teu locale (no en tinc experiència ni sabria
dir fins a quin punt és realment viable i/o prudent) i modificar els
mesos per tal que s'escriguin sense l'article, és a dir, "maig" en lloc
de "de maig".
> Gràcies!
>
> Orestes.
>
[toc] | [prev] | [next] | [standalone]
| From | Toni Mas Soler <antomassol@gmail.com> |
|---|---|
| Date | 2020-12-20 04:00 +0100 |
| Message-ID | <BnX6V-4Yj-1@gated-at.bofh.it> |
| In reply to | #6504 |
[Multipart message — attachments visible in raw view] — view raw
Doncs jo ho entenc com un bug del propi locale. Voleu dir que som l'única
llengua que es troba en aquesta situació?
Com a primer plantejament caldria considerar la correcció del locale per
tal que un date +%B retorni el mes sense preposició.
En 2n terme, com diu l'Eloi, té tota la pinta que l'script es podria
millorar.
La opció menys intrusiva pero encara prou generalista, donat que veig que
l'script no fa servei noms absoluts del programa date, crec que seria:
- crear un wrapper local per a la comanda date que:
- si el pare és aquest script de backup en qüestió li assignes un locale
que sàpigues que funcioni.
- Si no, res
- seguidament, s'invoca el programa date habitual
Amb una bona configuració del PATH, entenc que hauria de funcionar.
El ds., 19 des. 2020, 20.57, Eloi <entfe001@gmail.com> va escriure:
> Comento entre solucions i retallo part del missatge
>
> El 19/12/20 a les 19:48, orestes@riseup.net ha escrit:
> > Benvolguda llista, a veure si em podeu ajudar en una cosa:
> >
> > [...]
> >
> > Fent una mica de recerca he pogut deduir l'origen del problema i fins i
> > tot sabria solucionar-lo, però voldria saber si hi ha alguna manera
> > millor de la que jo penso. M'explico:
> >
> > "automysqlbackup" és un script situat a /usr/sbin. Les línies rellevants
> > d'aquest script són les següents:
> >
> > ----------------------------
> > DATE=`date +%Y-%m-%d_%Hh%Mm` # Datestamp e.g
> > 2002-09-21
> > DOW=`date +%A` # Day of
> > the week e.g. Monday
> > DNOW=`date +%u` # Day number of
> > the week 1 to 7 where 1 represents Monday
> > DOM=`date +%d` # Date
> > of the Month e.g. 27
> > M=`date +%B` # Month
> > e.g January
> > W=`date +%V` # Week
> > Number e.g 37
> > ----------------------------
> > ...
> > ----------------------------
> > # Monthly Full Backup of all Databases
> > (...)
> > dbdump "$MDB" "$BACKUPDIR/monthly/$MDB/${MDB}_$DATE.$M.$MDB.sql"
> > ----------------------------
> >
> > O sigui que usa "dbdump" (que és una funció definida en un altre lloc de
> > l'script i acaba usant "mysqldump") amb un nom de fitxer que expandeix
> > la variable "$M", la qual és el resultat de "date +%B" que, en un
> > sistema amb locale en català donarà "de desembre" si l'executeu avui,
> > per exemple.
>
> Crec que part del problema pot venir, precisament, d'aquesta la funció
> dbdump (no uso mysql i no ho puc verificar). Tenir espais en blanc a
> noms de fitxer, tot i que en general és bona pràctica evitar-los, no
> hauria de ser un problema sempre i quan s'escapin correctament les
> variables. En aquest sentit, l'ús de les cometes dobles és correcte en
> aquest punt, i el nom del fitxer (així com el del directori) haurien de
> ser tolerants.
>
> Em fa la fila que, en algun lloc de la funció shell dbdump, hi haurà un
> $2 en lloc d'un "$2" a l'hora d'escriure el fitxer de sortida. A menys
> que se sàpiga del cert que no hi haurà espais en blanc o que precisament
> interessi que els espais impliquin una separació d'elements, tota
> referència a una variable de shell jo la posaria entre cometes dobles
> (compte, que les simples signifiquen quelcom ben diferent!)
>
> > Tal i com ho veig jo, podria fer el següent:
> >
> > 1) Canviar el "locale" del sistema, el problema és que és un servidor
> > que córre un Moodle i si canvio el locale del sistema hi ha algunes
> > cosetes del moodle que surten en anglès.
>
> No necessites canviar el locale del sistema, només el del propi shell,
> ja sigui cridant-lo passant com a prefix:
>
> LC_ALL=C automysqlbackup
>
> En general, per a scripts de backups que usen dates no és mala idea,
> especialment si s'usen noms literals de mes o del dia de la setmana,
> cosa que personalment evito perquè pots acabar amb una col·lecció de
> còpies amb noms inconsistents entre elles si s'han generat amb locales
> diferents
>
> > 2) Canviar l'script del automysqlbackup per tal que no posi el nom del
> > mes, el posi sense espai o alguna cosa semblant. El problema que hi veig
> > és que ho hauria de refer en cada actualització del automysqlbackup. No
> > em sembla una bona idea.
> Jo obriria un bug, precisament per evitar el que deia en en paràgraf
> anterior
> > 3) Potser podria fer un terme mig i crear una configuració "local" del
> > automysqlbackup, que no es veuria sobreescrita en actualitzar el paquet,
> > i que forcés un "locale" anglès en executar-se. Potser és la millor
> > manera però, ni que sigui per curiositat, hi ha alguna manera
> > d'arreglar-ho preservant el nom del mes en català? Com ho faríeu
> > vosaltres?
>
> Pots crear un shell on preparis configuracions, com la del locale, i fer
> servir aquest script. Fins i tot podries arribar a donar-li el mateix
> nom i posar-lo en una ubicació amb major prioritat al path (cosa que
> personalment no m'agrada), sempre que l'script es cridi sense ruta
> absoluta.
>
> En el teu cas podria ser una cosa tan simple com això:
>
> #!/bin/sh
> export LC_ALL=C
> automysqlbackup "$@"
>
> Pel que fa a poder mantenir els noms dels mesos en català, una altra
> alternativa seria tocar el teu locale (no en tinc experiència ni sabria
> dir fins a quin punt és realment viable i/o prudent) i modificar els
> mesos per tal que s'escriguin sense l'article, és a dir, "maig" en lloc
> de "de maig".
>
> > Gràcies!
> >
> > Orestes.
> >
>
>
[toc] | [prev] | [next] | [standalone]
| From | Ernest Adrogué <nr9@posteo.de> |
|---|---|
| Date | 2020-12-20 10:10 +0100 |
| Message-ID | <Bo2T0-iT-3@gated-at.bofh.it> |
| In reply to | #6505 |
2020-12-20, 03:51 (+0100); Toni Mas Soler escriu: > Doncs jo ho entenc com un bug del propi locale. Voleu dir que som l'única > llengua que es troba en aquesta situació? > > Com a primer plantejament caldria considerar la correcció del locale per > tal que un date +%B retorni el mes sense preposició. Exacte, el problema és el local ca_ES. Mireu aquest fil de fa 2 anys: https://lists.debian.org/debian-user-catalan/2018/10/msg00000.html Pel que sembla, des de Softcatalà, van promoure un canvi al local ca_ES, que és el que provoca que ara apareguin els mesos amb preposició en llocs on no hi ha d'haver preposició. Ni el francès [1], ni el castellà [2], ni l'italià [3], que utilitzen els mesos igual que el català, han fet cap canvi similar en els respectius locals [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/fr_FR;h=a18c514f1921fed0049d3b769c95c9e0f864fb2f;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c [2] https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/es_ES;h=aa919a26267fd6311b71d7aeb81655e55787b4df;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c [3] https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/fr_FR;h=a18c514f1921fed0049d3b769c95c9e0f864fb2f;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c Jo ja fa temps vaig canviar el local a "C" perquè no podia soportar més els llistats de 'ls -l' amb els noms dels mesos equivocats. Salutacions.
[toc] | [prev] | [next] | [standalone]
| From | Joan Montané <jmontane@gmail.com> |
|---|---|
| Date | 2020-12-20 10:50 +0100 |
| Message-ID | <Bo3vH-vP-1@gated-at.bofh.it> |
| In reply to | #6506 |
[Multipart message — attachments visible in raw view] — view raw
Missatge de Ernest Adrogué <nr9@posteo.de> del dia dg., 20 de des. 2020 a les 10:07: > 2020-12-20, 03:51 (+0100); Toni Mas Soler escriu: > > Doncs jo ho entenc com un bug del propi locale. Voleu dir que som l'única > > llengua que es troba en aquesta situació? > > > > Com a primer plantejament caldria considerar la correcció del locale per > > tal que un date +%B retorni el mes sense preposició. > > Exacte, el problema és el local ca_ES. Mireu aquest fil de fa 2 anys: > > https://lists.debian.org/debian-user-catalan/2018/10/msg00000.html > > Pel que sembla, des de Softcatalà, van promoure un canvi al local ca_ES, > que és el que provoca que ara apareguin els mesos amb preposició en > llocs on no hi ha d'haver preposició. Ni el francès [1], ni el castellà > [2], ni l'italià [3], que utilitzen els mesos igual que el català, han > fet cap canvi similar en els respectius locals > > [1] > https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/fr_FR;h=a18c514f1921fed0049d3b769c95c9e0f864fb2f;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c > > [2] > https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/es_ES;h=aa919a26267fd6311b71d7aeb81655e55787b4df;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c > > [3] > https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/fr_FR;h=a18c514f1921fed0049d3b769c95c9e0f864fb2f;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c > > Jo ja fa temps vaig canviar el local a "C" perquè no podia soportar més > els llistats de 'ls -l' amb els noms dels mesos equivocats. > Hola, Anem a pams, que potser s'estan barrejant temes. Els canvis a la glibc es van per fer coincidir els formats de data amb el CLDR. Objectivament, aquests canvis permeten escriure les dates correctament. És a dir, la iniciativa original no va ser des de Softcatalà, però sí a la glibc. En castellà no apostrofen els mesos, per això en el format de data tenen "hardcoded" la preposició "de". En francès no usen la preposició "de" en les dates (sospito que en el seu dia van triar fer-ho així per a evitar el problema de l'apostrofació) En bash, cal canviar de locale ni res. Només cal usar "%OB" (lletra o majúscula) en el format de date perquè usi el format sense proposició. Hauria de funcionar en tots els locales. P.ex: date -d "2018/04/01" +"%OB" retorna "abril" (sense preposició). El tema dels mesos incorrectes a "ls -l" no està directament relacionat amb això. És un altre problema que se suposa ja està corregit i tard o d'hora arribarà tothom [1] Salutacions, Joan Montané Més informació: https://rluzynski.fedorapeople.org/slides/2017-01-27-DevConf.cz/GenitiveMonths-updated.pdf I, en concret per al català: https://www.softcatala.org/projectes/abril/ [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963513
[toc] | [prev] | [next] | [standalone]
| From | Ernest Adrogué <nr9@posteo.de> |
|---|---|
| Date | 2020-12-20 11:10 +0100 |
| Message-ID | <Bo3P4-RO-15@gated-at.bofh.it> |
| In reply to | #6507 |
2020-12-20, 10:40 (+0100); Joan Montané escriu: > Anem a pams, que potser s'estan barrejant temes. > > Els canvis a la glibc es van per fer coincidir els formats de data amb el > CLDR. Objectivament, aquests canvis permeten escriure les dates > correctament. És a dir, la iniciativa original no va ser des de Softcatalà, > però sí a la glibc. > En castellà no apostrofen els mesos, per això en el format de data tenen > "hardcoded" la preposició "de". > En francès no usen la preposició "de" en les dates (sospito que en el seu > dia van triar fer-ho així per a evitar el problema de l'apostrofació) > > En bash, cal canviar de locale ni res. Només cal usar "%OB" (lletra o > majúscula) en el format de date perquè usi el format sense proposició. > Hauria de funcionar en tots els locales. P.ex: date -d "2018/04/01" +"%OB" > retorna "abril" (sense preposició). > > El tema dels mesos incorrectes a "ls -l" no està directament relacionat amb > això. És un altre problema que se suposa ja està corregit i tard o d'hora > arribarà tothom [1] Gràcies per l'aclariment.
[toc] | [prev] | [next] | [standalone]
| From | Josep Lladonosa <jlladono@gmail.com> |
|---|---|
| Date | 2020-12-20 12:00 +0100 |
| Message-ID | <Bo4Bs-182-7@gated-at.bofh.it> |
| In reply to | #6508 |
[Multipart message — attachments visible in raw view] — view raw
Hola, Sembla que ja està encaminada la solució però volia aportar la meva opinió: Per a mi és un "bug" d'aquest script ja que no hauria de suposar que les dates no tinguin espais si s'han d'usar en nom de fitxer ja que un nom de fitxer pot contenir-ne, d'espais. Potser es pot reportar un bug al creador del script i fins i tot fer una proposta per resoldre'l, "escapant" el nom de fitxer. Salutacions, Josep On Sun, 20 Dec 2020 at 11:07, Ernest Adrogué <nr9@posteo.de> wrote: > 2020-12-20, 10:40 (+0100); Joan Montané escriu: > > Anem a pams, que potser s'estan barrejant temes. > > > > Els canvis a la glibc es van per fer coincidir els formats de data amb el > > CLDR. Objectivament, aquests canvis permeten escriure les dates > > correctament. És a dir, la iniciativa original no va ser des de > Softcatalà, > > però sí a la glibc. > > En castellà no apostrofen els mesos, per això en el format de data tenen > > "hardcoded" la preposició "de". > > En francès no usen la preposició "de" en les dates (sospito que en el seu > > dia van triar fer-ho així per a evitar el problema de l'apostrofació) > > > > En bash, cal canviar de locale ni res. Només cal usar "%OB" (lletra o > > majúscula) en el format de date perquè usi el format sense proposició. > > Hauria de funcionar en tots els locales. P.ex: date -d "2018/04/01" > +"%OB" > > retorna "abril" (sense preposició). > > > > El tema dels mesos incorrectes a "ls -l" no està directament relacionat > amb > > això. És un altre problema que se suposa ja està corregit i tard o d'hora > > arribarà tothom [1] > > Gràcies per l'aclariment. > > -- -- Salutacions...Josep --
[toc] | [prev] | [next] | [standalone]
| From | Joan Montané <jmontane@gmail.com> |
|---|---|
| Date | 2020-12-20 12:30 +0100 |
| Message-ID | <Bo54u-1xI-5@gated-at.bofh.it> |
| In reply to | #6509 |
[Multipart message — attachments visible in raw view] — view raw
Missatge de Josep Lladonosa <jlladono@gmail.com> del dia dg., 20 de des. 2020 a les 11:56: > Hola, > > Sembla que ja està encaminada la solució però volia aportar la meva opinió: > > Per a mi és un "bug" d'aquest script ja que no hauria de suposar que les > dates no tinguin espais si s'han d'usar en nom de fitxer ja que un nom de > fitxer pot contenir-ne, d'espais. > > Potser es pot reportar un bug al creador del script i fins i tot fer una > proposta per resoldre'l, "escapant" el nom de fitxer. > > Efectivament, en el cas particular que ens ocupa hi ha dues coses que coincideixen, i fan aparèixer el problema: 1. En algunes llengües, la variable que conté el nom del mes conté un espai. És el cas de català si s'usa el format %B per a tots els mesos menys abril, agost i octubre. 2. L'script no escapa els possibles espais de les variables i si hi ha espais, aleshores l'script no fa el que se suposa que ha de fer. L'error és a 2 (no es pot assumir alegrement que una variable no té espais). El problema es podria rodejar usant "%OB" a l'script per a extraure els noms de mesos (totes les llengües que he mirat retornen els mesos sense espai), però això segueix sense garantir que les cadenes no tindran espais, i el problema descrit a 2 podria tornar a reproduir-se. La solució bona és escapar els espais de les variables, amb les cometes dobles. Com diu el Josep, el millor és obrir un bug a automysqlbackup i, idealment, aportar-hi la solució. Salut! Joan Montané PS: encara gràcies que amb %B "d'abril", "d'agost" i "d'octubre" usen l'apòstrof tipogràfic, perquè sospito que si usessin l'apòstrof recte, l'script també hauria tingut problemes en aquests mesos.
[toc] | [prev] | [next] | [standalone]
| From | Eloi <entfe001@gmail.com> |
|---|---|
| Date | 2020-12-20 13:40 +0100 |
| Message-ID | <Bo6ae-2b3-9@gated-at.bofh.it> |
| In reply to | #6510 |
[Multipart message — attachments visible in raw view] — view raw
El 20/12/20 a les 12:27, Joan Montané ha escrit: > > > Missatge de Josep Lladonosa <jlladono@gmail.com > <mailto:jlladono@gmail.com>> del dia dg., 20 de des. 2020 a les 11:56: > > Hola, > > Sembla que ja està encaminada la solució però volia aportar la > meva opinió: > > Per a mi és un "bug" d'aquest script ja que no hauria de suposar > que les dates no tinguin espais si s'han d'usar en nom de fitxer > ja que un nom de fitxer pot contenir-ne, d'espais. > > Potser es pot reportar un bug al creador del script i fins i tot > fer una proposta per resoldre'l, "escapant" el nom de fitxer. > > > Efectivament, en el cas particular que ens ocupa hi ha dues coses que > coincideixen, i fan aparèixer el problema: > > 1. En algunes llengües, la variable que conté el nom del mes conté un > espai. És el cas de català si s'usa el format %B per a tots els mesos > menys abril, agost i octubre. > 2. L'script no escapa els possibles espais de les variables i si hi ha > espais, aleshores l'script no fa el que se suposa que ha de fer. > > L'error és a 2 (no es pot assumir alegrement que una variable no té > espais). El problema es podria rodejar usant "%OB" a l'script per a > extraure els noms de mesos (totes les llengües que he mirat retornen > els mesos sense espai), però això segueix sense garantir que les > cadenes no tindran espais, i el problema descrit a 2 podria tornar a > reproduir-se. La solució bona és escapar els espais de les variables, > amb les cometes dobles. > > Com diu el Josep, el millor és obrir un bug a automysqlbackup i, > idealment, aportar-hi la solució. Doncs bé, he fet l'exercici de consultar el codi font de l'script a [1] i l'he encertat de ple: com es pot veure a la funció shell, definida a partir de la línia 424, tant $1 com $2 no estan degudament protegits. El fet que un espai en blanc trenqui la creació de còpies de seguretat, per si sol, entenc que mereix que el bug tingui una severitat major que normal. Ara bé, que $1 tampoc estigui protegit i el paràmetre correspongui a una dada facilitada per l'usuari, el nom de la base de dades, em fa témer que podria arribar a explotar-se com a vulnerabilitat per a la injecció de comandes. Per exemple: una configuració que fes còpia d'una base de dades "foo; dropdb foo" (en el cas de treballar amb Postgres, on tinc experiència) podria, segons els permisos, destruir la base de dades, el que ho faria un bug crític [2]. Ara bé, no he comprovat fins a quin punt és explotable, però és quelcom que fa saltar totes les meves alarmes. També, com s'apunta correctament, si l'apòstrof no fos tipogràfic i es tractés d'una "cometa simple", causaria error i no completaria el backup. L'altre tema és el d'anomenar els backups en funció del locale, que està bé per a humans però és terrible per a gestió automàtica per a màquines. Si jo fes anar l'script (i, pel que he vist fins ara, el deixaria de fer servir immediatament) obriria dos bug reports: el primer, més greu, amb el problema d'escapament dels paràmetres de la funció dbdump; i el segon, com a wishlist, per parametritzar si la còpia s'ha d'anomenar de forma humana (com fins ara) o mecànica (en un format YYYY-MM-DD o similar però respectant l'ordre any-mes-dia i 4-2-2 dígits). No em sento còmode obrint-los jo per tractar-se d'una eina que no uso, doncs no podria donar respostes a preguntes addicionals del desenvolupador o de l'empaquetador, però puc ajudar a qui l'obri. [1] <https://salsa.debian.org/zigo/automysqlbackup/-/blob/debian/automysqlbackup> cf. <https://tracker.debian.org/pkg/automysqlbackup> [2] https://xkcd.com/327/
[toc] | [prev] | [next] | [standalone]
| From | julio <jamoros@correu.escoladeltreball.org> |
|---|---|
| Date | 2020-12-20 14:10 +0100 |
| Message-ID | <Bo6Df-2Ag-7@gated-at.bofh.it> |
| In reply to | #6511 |
[Multipart message — attachments visible in raw view] — view raw
"Doble quote lost in space", m'encanten aquestes novel•les de misteri col•laboratives. +1000 Le 20 décembre 2020 13:36:42 GMT+01:00, Eloi <entfe001@gmail.com> a écrit : >El 20/12/20 a les 12:27, Joan Montané ha escrit: >> >> >> Missatge de Josep Lladonosa <jlladono@gmail.com >> <mailto:jlladono@gmail.com>> del dia dg., 20 de des. 2020 a les >11:56: >> >> Hola, >> >> Sembla que ja està encaminada la solució però volia aportar la >> meva opinió: >> >> Per a mi és un "bug" d'aquest script ja que no hauria de suposar >> que les dates no tinguin espais si s'han d'usar en nom de fitxer >> ja que un nom de fitxer pot contenir-ne, d'espais. >> >> Potser es pot reportar un bug al creador del script i fins i tot >> fer una proposta per resoldre'l, "escapant" el nom de fitxer. >> >> >> Efectivament, en el cas particular que ens ocupa hi ha dues coses que > >> coincideixen, i fan aparèixer el problema: >> >> 1. En algunes llengües, la variable que conté el nom del mes conté un > >> espai. És el cas de català si s'usa el format %B per a tots els mesos > >> menys abril, agost i octubre. >> 2. L'script no escapa els possibles espais de les variables i si hi >ha >> espais, aleshores l'script no fa el que se suposa que ha de fer. >> >> L'error és a 2 (no es pot assumir alegrement que una variable no té >> espais). El problema es podria rodejar usant "%OB" a l'script per a >> extraure els noms de mesos (totes les llengües que he mirat retornen >> els mesos sense espai), però això segueix sense garantir que les >> cadenes no tindran espais, i el problema descrit a 2 podria tornar a >> reproduir-se. La solució bona és escapar els espais de les variables, > >> amb les cometes dobles. >> >> Com diu el Josep, el millor és obrir un bug a automysqlbackup i, >> idealment, aportar-hi la solució. > >Doncs bé, he fet l'exercici de consultar el codi font de l'script a [1] > >i l'he encertat de ple: com es pot veure a la funció shell, definida a >partir de la línia 424, tant $1 com $2 no estan degudament protegits. > >El fet que un espai en blanc trenqui la creació de còpies de seguretat, > >per si sol, entenc que mereix que el bug tingui una severitat major que > >normal. Ara bé, que $1 tampoc estigui protegit i el paràmetre >correspongui a una dada facilitada per l'usuari, el nom de la base de >dades, em fa témer que podria arribar a explotar-se com a >vulnerabilitat >per a la injecció de comandes. Per exemple: una configuració que fes >còpia d'una base de dades "foo; dropdb foo" (en el cas de treballar amb > >Postgres, on tinc experiència) podria, segons els permisos, destruir la > >base de dades, el que ho faria un bug crític [2]. Ara bé, no he >comprovat fins a quin punt és explotable, però és quelcom que fa saltar > >totes les meves alarmes. > >També, com s'apunta correctament, si l'apòstrof no fos tipogràfic i es >tractés d'una "cometa simple", causaria error i no completaria el >backup. > >L'altre tema és el d'anomenar els backups en funció del locale, que >està >bé per a humans però és terrible per a gestió automàtica per a >màquines. >Si jo fes anar l'script (i, pel que he vist fins ara, el deixaria de >fer >servir immediatament) obriria dos bug reports: el primer, més greu, amb > >el problema d'escapament dels paràmetres de la funció dbdump; i el >segon, com a wishlist, per parametritzar si la còpia s'ha d'anomenar de > >forma humana (com fins ara) o mecànica (en un format YYYY-MM-DD o >similar però respectant l'ordre any-mes-dia i 4-2-2 dígits). > >No em sento còmode obrint-los jo per tractar-se d'una eina que no uso, >doncs no podria donar respostes a preguntes addicionals del >desenvolupador o de l'empaquetador, però puc ajudar a qui l'obri. > >[1] ><https://salsa.debian.org/zigo/automysqlbackup/-/blob/debian/automysqlbackup> > >cf. <https://tracker.debian.org/pkg/automysqlbackup> > >[2] https://xkcd.com/327/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[toc] | [prev] | [next] | [standalone]
| From | Orestes Mas <orestes@riseup.net> |
|---|---|
| Date | 2020-12-20 14:20 +0100 |
| Message-ID | <Bo6MV-2DC-7@gated-at.bofh.it> |
| In reply to | #6511 |
[Multipart message — attachments visible in raw view] — view raw
El diumenge, 20 de desembre de 2020, a les 13:36:42 CET, Eloi va escriure: Doncs bé, he fet l'exercici de consultar el codi font de l'script a [1] i l'he encertat de ple: com es pot veure a la funció shell, definida a partir de la línia 424, tant $1 com $2 no estan degudament protegits. El fet que un espai en blanc trenqui la creació de còpies de seguretat, per si sol, entenc que mereix que el bug tingui una severitat major que normal. Ara bé, que $1 tampoc estigui protegit i el paràmetre correspongui a una dada facilitada per l'usuari, el nom de la base de dades, em fa témer que podria arribar a explotar-se com a vulnerabilitat per a la injecció de comandes. Per exemple: una configuració que fes còpia d'una base de dades "foo; dropdb foo" (en el cas de treballar amb Postgres, on tinc experiència) podria, segons els permisos, destruir la base de dades, el que ho faria un bug crític [2]. Ara bé, no he comprovat fins a quin punt és explotable, però és quelcom que fa saltar totes les meves alarmes. També, com s'apunta correctament, si l'apòstrof no fos tipogràfic i es tractés d'una "cometa simple", causaria error i no completaria el backup. L'altre tema és el d'anomenar els backups en funció del locale, que està bé per a humans però és terrible per a gestió automàtica per a màquines. Si jo fes anar l'script (i, pel que he vist fins ara, el deixaria de fer servir immediatament) obriria dos bug reports: el primer, més greu, amb el problema d'escapament dels paràmetres de la funció dbdump; i el segon, com a wishlist, per parametritzar si la còpia s'ha d'anomenar de forma humana (com fins ara) o mecànica (en un format YYYY-MM-DD o similar però respectant l'ordre any-mes-dia i 4-2-2 dígits). No em sento còmode obrint-los jo per tractar-se d'una eina que no uso, doncs no podria donar respostes a preguntes addicionals del desenvolupador o de l'empaquetador, però puc ajudar a qui l'obri. [1] <https://salsa.debian.org/zigo/automysqlbackup/-/blob/debian/automysqlbackup>[1] cf. <https://tracker.debian.org/pkg/automysqlbackup>[2] [2] https://xkcd.com/327/[3] Ostres, *moltes* gràcies a tots els qui heu respost aportant el vostre punt de vista. Ja em semblava que la cosa tenia més suc i transcendència del que hom podia pensar a primera vista, i el resultat no m'ha decebut gens :-) Atès que sóc jo qui ha iniciat el fil veig que em tocarà a mi d'obrir el bug contra l'automysqlbackup. Passa que vaig una mica atrafegat amb el final de curs i no sé ben bé quan podré fer-ho. A més, tampoc no sóc gens expert en els temes de locale, libc, bash i demés. Vull dir que obrir el bug m'hi veig en cor, però proposar solucions més enllà de les que heu comentat (protegir les variables amb cometes, etc.) ja no tant. En tot cas ho provo i si el desenvolupador demana més coses, aleshores ja us demanaré consell a vosaltres. -- Cordialment, Orestes Mas -------- [1] https://salsa.debian.org/zigo/automysqlbackup/-/blob/debian/automysqlbackup [2] https://tracker.debian.org/pkg/automysqlbackup [3] https://xkcd.com/327/
[toc] | [prev] | [next] | [standalone]
| From | Orestes Mas <orestes@tsc.upc.edu> |
|---|---|
| Date | 2020-12-20 15:40 +0100 |
| Message-ID | <Bo82n-3lu-23@gated-at.bofh.it> |
| In reply to | #6507 |
El diumenge, 20 de desembre de 2020, a les 10:40:27 CET, Joan Montané va escriure: > Hola, > > Anem a pams, que potser s'estan barrejant temes. > > Els canvis a la glibc es van per fer coincidir els formats de data amb el > CLDR. Objectivament, aquests canvis permeten escriure les dates > correctament. És a dir, la iniciativa original no va ser des de Softcatalà, > però sí a la glibc. En castellà no apostrofen els mesos, per això en el > format de data tenen "hardcoded" la preposició "de". En francès no usen la > preposició "de" en les dates (sospito que en el seu dia van triar fer-ho > així per a evitar el problema de l'apostrofació) > > En bash, cal canviar de locale ni res. Només cal usar "%OB" (lletra o > majúscula) en el format de date perquè usi el format sense proposició. > Hauria de funcionar en tots els locales. P.ex: date -d "2018/04/01" +"%OB" > retorna "abril" (sense preposició). > > El tema dels mesos incorrectes a "ls -l" no està directament relacionat amb > això. És un altre problema que se suposa ja està corregit i tard o d'hora > arribarà tothom [1] > > Salutacions, > Joan Montané > > Més informació: > https://rluzynski.fedorapeople.org/slides/2017-01-27-DevConf.cz/GenitiveMon > ths-updated.pdf I, en concret per al català: > https://www.softcatala.org/projectes/abril/ [1] > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963513 Desconeixia que "+%OB" retorna el nom del mes en "cas nominatiu". Molt interessant. En el cas que ens ocupa (català) això podria ser la solució, però desconec si en altres llengües arreglaria el problema o no. En qualsevol cas, potser el desenvolupador de automysqlbackup desconeix aquest canvi a la glibc. Serà qüestió d'esbrinar-ho. -- Cordialment, Orestes Mas
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user.catalan
csiph-web