Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user.catalan > #6502 > unrolled thread

Problemes amb automysqlbackup combinat amb un "locale" en català

Started byorestes@riseup.net
First post2020-12-19 19:50 +0100
Last post2020-12-20 15:40 +0100
Articles 13 — 10 participants

Back to article view | Back to linux.debian.user.catalan


Contents

  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

#6502 — Problemes amb automysqlbackup combinat amb un "locale" en català

Fromorestes@riseup.net
Date2020-12-19 19:50 +0100
SubjectProblemes 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]


#6503

FromNarcis Garcia <debianlists@actiu.net>
Date2020-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]


#6504

FromEloi <entfe001@gmail.com>
Date2020-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]


#6505

FromToni Mas Soler <antomassol@gmail.com>
Date2020-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]


#6506

FromErnest Adrogué <nr9@posteo.de>
Date2020-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]


#6507

FromJoan Montané <jmontane@gmail.com>
Date2020-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]


#6508

FromErnest Adrogué <nr9@posteo.de>
Date2020-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]


#6509

FromJosep Lladonosa <jlladono@gmail.com>
Date2020-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]


#6510

FromJoan Montané <jmontane@gmail.com>
Date2020-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]


#6511

FromEloi <entfe001@gmail.com>
Date2020-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]


#6512

Fromjulio <jamoros@correu.escoladeltreball.org>
Date2020-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]


#6513

FromOrestes Mas <orestes@riseup.net>
Date2020-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]


#6514

FromOrestes Mas <orestes@tsc.upc.edu>
Date2020-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