Newsgroup: it.comp.os.linux.iniziare
Titolo: Sintassi evidenziata con Mc (mcedit)

[ crosspost it.comp.os.linux.iniziare,it.comp.os.linux.software ]
 
 
Perche' con $() tra virgolette annidati mcedit sbaglia, perdendo per
strada una virgoletta? sara' un bug (difficile) o e' a me, che mi
sfugge qualcosa (facile)?
 
Ecco, per chiarezza, come ad esempio mi tocca scrivere:
---------
#!/bin/bash
 
t_UTC="$1"
 
ANNI="$(echo \
"$(date -u "+%Y - 1970" --date=@${t_UTC})" | bc -l)"
--------------
 
altrimenti, se non vado inutilmente a capo con \, l'eventuale
seguito resta come fosse tutto commentato.
 
 
[ crosspost it.comp.os.linux.iniziare,it.comp.os.linux.software ]
 
-- 
Yoda
 


Cosa dovrebbe calcolare il tuo script?
 
Quale argomento gli dai?
 
t_UTC che è impostato a primo argomento cosa sarebbe?
 
Fai un esempio di utilizzo dello script: come lo lanci da terminale.

 ANNI="$(echo \
       ^--virgolette aperte> "$(date -u "+%Y - 1970" --date=@${t_UTC})"
| bc -l)"
  ^--virgolette chiuse
 
"a"b"c"
 
Significa che "a" e "c" sono tra virgolette,
non che 'a"b"c' e` tra virgolette ed anche 'b'...
 
Che poi, quante virgolette metti?
 
bye,
 
-- 
 
piergiorgio

 Fai un esempio di utilizzo dello script: come lo lanci da terminale.
 
$: ./pippo 6546418548412028870
 
Mi da' gli anni civili, son molto difficili da calcolare.. se faccio
all'antica: 1 anno = 365 giorni e quattro ore, c'e' errore anche
rispetto all'anno tropico ciao comunque lo scherzetto mcedit e' da
molto che me lo fa e con molti altri script del tutto differenti
 
-- 
Yoda
 

Addi' 07 gen 2021 22:16:40, Piergiorgio Sartor scrive:

Si' (e no!), ma in ogni caso quello che non capiso e' perche' a bash
il comando arriva corretto anche senza l'a capo ed invece mcedit con
l'a capo non segue piu' il tuo schema-ragionamento e la smette di
commentare nel seguito.
 
D'altra parte m'ero distratto, perche' a date la direttiva "+%Y -
1970" posso metterla (molto meglio) tra apici: '+%Y - 1970', pero'
anche cosi' per mcedit non cambia nulla (ho provato adesso).
 
Pertanto vediamolo punto per punto:
ANNI="$(echo "$(date -u '+%Y - 1970' --date=@${t_UTC})" | bc -l)"
ebbene:
 
1. l'output di date e' ad esempio:
2023 - 1970
dunque e' obbligatorio passarlo a bc con virgolette:
"$(date -u '+%Y - 1970' --date=@${t_UTC})"
doppie perche' interviene la variabile t_UTC.
 
2. Resta allora soltanto l'output di bc.. dici che e' sbagliato
metterle o in ogni caso che son troppe? Be', in questo caso e' un
numero, ma considera che in altri casi potrebbero esserci spazi
(ho scritto-chiesto adesso, ma e' da molto che mcedit mi fa questo
scherzetto anche con comandi dove le virgolette sono assolutamente
indispensabili) ciao
 
-- 
Yoda
 


L'esempio non è calzante, l'argomento è troppo grande.
Quando si chiede e viene richiesto un esempio meglio
sempre fare un esempio cosrretto. Per capirsi dar modo
di fare una prova e poter verificare precisamente.
 
Esempio:
 
$ ./pippo.sh 654641849
20
 
 
Con 654641849 secondi, mi ritorna 20 anni.
 
Conto a spanne:
 
$ echo "654641849/(3600*24*365)"|bc
20
 
Direi che ci siamo...
 
Vediamo pippo.sh, molto simile al tuo:
--------------------------------------
$ cat pippo.sh
#!/bin/bash
 
t_UTC=$1
ANNI=$(date -u --date=@${t_UTC} +%Y-1970 |bc)
echo $ANNI
----------
 
Troppe virgolette non servono.
 
ANNI è un numero intero, non contiene spazi, virgolette non e servono.
t_UTC è un numero intero, vedi sopra
 
Ma soprattutto bc interpreta in input via pipe l'output del comando
"date", e non ha problemi con gli spazi.
 
In più l'echo che inserivi tu non serve. Già il comando date produce
l'output corretto.
 
Invece servono per formattare correttamente l'argomento del comando
date, se lo vuoi scrivere con gli spazi. Ma non serve neanche quello
se adiamo a vedere. Perché potresti banalmente scrivere:
 
date +%Y-1970
 
come ho messo io sopra. E ti risparmi anche quelle virgolette lì.

 l'output corretto.
 
Si', certo.. solo che prima il "- 1970" era fuori comando data, ho
riportato senza controllare - ariscusate:-(  e ariciao
 
-- 
Yoda
 

 Ecco, la questione-domanda e' questa ciao e grazie eh
 
Intanto come già detto sopra, le virgolette esterne le
puoi togliere, non sono necessarie.
Poi evidentemente l'evidenziazione sintattica dell'editor
o va in panne oppure è proprio fatta così.
Volendo puoi anche toglierla:
F9 opzioni evidenziazione sintassi
la imposti ad unknown e via.
 
Altrimenti prova altri editor.
Io uso vim per lo più.
Anche lì comunque in certi casi, la sintassi evidenziata
non è sempre perfetta. Vado a memoria, ma in rare occasioni
mi sembra di ricordare qualche svarione...
 
Se vuoi restare su mcedit, devi cercare bene in rete su come
impostarlo correttamente per avere una schermata comoda e
cercare bene situazioni che riportano il problema rilevato,
sicuramente no sei il primo ad accorgerti di questo comportamento,
e sicuramente qualcuno lo avrà fatto presente e gli avranno anche
proposto delle soluzioni.
Se non trovi in italiano cerca in inglese. Trovi molta più roba,
manco a dirlo...

 ANNI="$(echo "$(date -u '+%Y - 1970' --date=@${t_UTC})" | bc -l)"
       ^       ^-chiuse
        \-aperte
 
Fai sempre lo stesso *errore*!
 
Non e` la sintassi corretta per quello
che vuoi fare tu.
 
Usa due variabili.
 
bye,
 
-- 
 
piergiorgio

 manco a dirlo...
 
Ok ancora grazie.. aggiungo, a quanto sopra, che mi e' oramai
evidente che mcedit pensa che la /prima/ chiusa-parentesi che
incontra dopo $( sia di chiusura della sostituzione di comando:
$(echo "-($1)
 
equivale a:
$(pippo)
 
per cui le successive virgolette:
" | bc)
 
valgono come apertura d'un commento ariciao
 
-- 
Yoda
 

 indispensabili) ciao
 
Mcedit fa diverse volte anche in altri contesti lo stesso errore, e male
interpreta nella evidenziazione i comandi annidati.
Tranquillo, lo fa da anni pure a me.
 
In questo spezzone:
 
        y="${r%"${r##*[![:space:]]}"}"
        printf '%s\n' "$y"
        t=$((t+1))
 
dalla chiusura dell'ultima parentesi graffa, è tutto evidenziato come commento!
 
 
 
-- 
---
 * Origin: Valentina_(.)  (2:332/213.22)

 dunque e' obbligatorio passarlo a bc con virgolette:
 
No, non e` obbligatorio.
Inoltre, funziona anche *senza* echo...
 
Questo:
 
date -u '+%Y - 1970' --date=2021-01-08T15:15:42 | bc -l
 
Senza "echo" e senza virgolette funziona.
 
Al massimo, servono le virgolette intorno
alla variabile "t_UTC", se vi sono spazi,
cosa che non credo sia il caso...
 
bye,
 
-- 
 
piergiorgio

 Senza "echo" e senza virgolette funziona.
 
Si', non l'avrei mai detto ciao e grazie!
 
-- 
Yoda
 

 come commento!
 
Si' oramai lo schema logico di mcedit l'ho capito, guarda come vede
il tuo "${r%"${r##*[![:space:]]}"}"
 
"${quello_che_vuoi_tanto_non_mi_riguarda}"}"
 
cioe' tre oggetti:
1. "${a}"
2. }
3. "+a_capo
 
la prima chiusa-graffa la riferisce alla prima aperta, la seconda
aperta neppure la guarda, come non guarda-vede le seconde virgolette
(perche' anch'esse interne a {}) ciao
 
-- 
Yoda
 

 Usa due variabili.
 
Si', questa e' proprio una buona idea, facilita anche la lettura del
codice ciao e grazie
 
-- 
bye, Yoda
 

 e dall'inutile primo comando echo).
 
Non e` questo il punto.
Scritto in quella maniera e` incomprensibile
e si presta ad errori.
 
Il fatto che l'ordine di espansione della shell,
in questo caso, sia favorevole, non vuol dire
che sia corretto usarlo.
 
Puo` essere un altro caso in cui non lo e`.
 
bye,
 
-- 
 
piergiorgio

 Si', non l'avrei mai detto ciao e grazie!
 
Perche` no?
 
Prima di scrivere cose "complicate", bisogna
sempre iniziare con quelle semplici.
 
Far diventare cose semplici complicate e`
facile, il contrario e` difficile.
 
bye,
 
-- 
 
piergiorgio

 POSITIVO=$(echo "-($1)" | bc)
 
Oggi mi son scocciato di tutti questi casini con parentesi e
virgolette varie e ho fatto semplicissimamente cosi':
 
POSITIVO=$(echo $1 | tr -d '-')
 
dici che corro qualche pericolo ciao?
 
-- 
Yoda
 


Non direi, anzi ti risparmi anche il controllo condizionale...
------------------
$ echo 9 |tr -d -
9
 
$ echo -9 |tr -d -
9
------------------
 
A me funziona anche senza apici.
Per cui:
 
POSITIVO=$(echo $1 | tr -)
 
Senza "if" e senza apici ' '.
 
 

 Che poi, quante virgolette metti?
 
Lo vedi perche' m'e' venuta la fissa delle virgolette? guarda questo
caso.
-----------
#!/usr/bin/env bash
 
if [ -n "$(echo $1 | grep -e "/" -e "[[:alpha:]]")" ]; then
echo pieno
else
echo vuoto
fi
----------------
 
ebbene: senza le virgolette esterne da' sempre pieno (ho provato
anche a metterci "echo -n"), qualunque cosa io ci metta in $1.
Me lo dici se e come lo puoi spiegare? perche' in fondo in fondo io
sulle virgolette doppie o semplici non ci ho mai capito molto, cosi'
le metto sempre a meno che non diano errore ciao
 
-- 
Yoda
 

Il 31/01/21 21:12, Yoda ha scritto:

   Le virgolette semplici (apostrofi) servono per identificare le 
stringhe che la shell non deve analizare per fare le sue solite 
operazioni di espansione/sostituzione.  Quelle doppie servono per 
evitare che la shell interpreti *alcuni* caratteri come speciali.  Ad 
esempio, gli spazi non fungono più da separatori e gli apostrofi perdono 
la loro funzione appena descritta.
 
   Nel tuo caso la differenza che osservi nella valutazione del test 
dipende da una caratteristica del comando stesso.
 
   Il comportamento di [ -n ... ] (come del comando test) è diverso 
quando ha una stringa vuota come parametro rispetto al caso in cui 
invece non ha nessun parametro:
 
[alessandro@wkstn03 ~]$ test -n '' && echo Vero || echo Falso
Falso
[alessandro@wkstn03 ~]$ test -n && echo Vero || echo Falso
Vero
[alessandro@wkstn03 ~]$
 
   Questo è controintuitivo, considerare una stringa inesistente non 
solo diversa da una stringa vuota, ma logicalmente il suo contrario è 
una delle tante bizarrie che si incontrano nelle shell Unix, ma così è. 
  Anche per questo è una buona abitudine abusare delle virgolette, visto 
che uno degli effetti che hanno è di far esistere una stringa anche 
quando l'espansione che la genera è vuota, mentre in loro assenza 
un'espansione nulla è considerata dalla shell inesistente.
 
 
   Ciao,
 
 
Alessandro
 
 

    Le virgolette semplici (apostrofi) servono per identificare le
-snip-
 
Ok ciao e grazie!
 
-- 
Yoda
 

 operazioni di espansione/sostituzione.
 
Si' ma ci stanno pure delle eccezioni-complicazioni.. vorrei
sapere per qual buon motivo (l'ho visto proprio stamattina)
queste protezioni "\" non vengono stampate a monitor dando
addirittura cat ciao
---------
sed -e 's/ \[[0-9]*;*[0-9]*;*[0-9]*m//g' -e \
's/ \[[0-9]*;*[0-9]*;*[0-9]*m \[K//g' -e \
's/ \[K//g'
-------------
(le ho fatte per togliere il colore)
 
-- 
Yoda
 

 (le ho fatte per togliere il colore)
 
   Non ho capito che cosa intendi con "non vengono stampate a monitor 
dando addirittura cat ciao".
 
   Dovresti per favore farmi vedere un esempio di input, l'output 
desiderato e l'output effettivo, così potrei capire qual'è il problema.
 
 
   Ciao,
 
 
Alessandro
 
 

 desiderato e l'output effettivo, così potrei capire qual'è il problema.
 
Il file pippo, d'input, contiene questo:
---------
sed 's/ \[[0-9]*;*[0-9]*;*[0-9]*m//g'
-------------
 
Se do "cat pippo" ottengo:
sed 's/ [[0-9]*;*[0-9]*;*[0-9]*m//g'
 
dove la bash e' intervenuta anche in cio' che sta tra apici.
 
Aggiungo che invece col comando echo (interno), bash rispetta "\"
pure con virgolette (doppie) ciao
 
echo s/ \[[0-9]*;*[0-9]*;*[0-9]*m//g
s/ [[0-9]*;*[0-9]*;*[0-9]*m//g
 
echo 's/ \[[0-9]*;*[0-9]*;*[0-9]*m//g'
s/ \[[0-9]*;*[0-9]*;*[0-9]*m//g
 
echo "s/ \[[0-9]*;*[0-9]*;*[0-9]*m//g"
s/ \[[0-9]*;*[0-9]*;*[0-9]*m//g
 
-- 
Yoda
 

 sed 's/ [[0-9]*;*[0-9]*;*[0-9]*m//g'
 
   Il comando cat manda in output il contenuto del file, tale e quale, 
senza nessuna modifica, com'è suo mestiere.
   È il terminale, il dispositivo di output che riceve i dati da cat e 
che li deve rappresentare sullo schermo, che vede il carattere di ESC e 
che quindi lo usa.  Le sequenze di escape esistono proprio per questo, 
per dire al dispositivo di output di fare delle operazioni, delle 
configurazioni particolari, del testo che gli sta per essere inviato. 
Non possono e quindi non devono essere usate come parte del testo.
 
 
   Ciao,
 
 
Alessandro
 
 
 

 che quindi lo usa.
 
Capit.. grazie ciao
 
-- 
Yoda
 

 invece di \033.
 
No.. sed prende anche gli ottali o i decimali, solo che ha
convenzioni diverse da echo: echo \033, sed \o33 (oppure in
base 10 \d27).
 
-- 
bye, Yoda
 

Il 11/02/21 19:27, Yoda ha scritto:

   La cosa bella di Unix: la stessa cosa può essere fatta in n maniere 
diverse.
 
   La cosa brutta di Unix: per fare la stessa cosa devi impare n maniere 
diverse per farla.
 
 
   Ciao,
 
 
Alessandro