Newsgroup: it.comp.os.linux.iniziare
Titolo: wget ed url con # non funziona

devo scaricare una trentina di pagine (solo) html con wget,
per l'url ha all'interno il carattere # il che non mi fa funzionare il 
tutto.
 
Ho sia provato con un batch .sh pero' il # penso sia riconoscuto come 
commento:
 
--------------------
#!/bin/sh
 
for (( X=1; X<31; X++ ))
do
  echo "PROGRESSIONE: X=" $X
  wget --append-output=log.txt 
http://www.sito.com/pagine/lista#page=$X
; 
done
------------------
 
Ho provato a mettere le virgolette cosi':
 
  wget --append-output=log.txt "
http://www.sito.com/pagine/lista#page=$X
;"
 
ma non mi esegue la progressione.
 
Poi ho provato a mettere i link in un file ed usare l'opzione -i ma non ha 
funzionato, ignora sempre tutto quello che c'e' dopo il cancelletto:
Il file e' tipo cosi':
 
http://www.sito.com/pagine/lista#page=1
 
http://www.sito.com/pagine/lista#page=2
 
http://www.sito.com/pagine/lista#page=3
 
... 

 commento:
 
Basta sostituire "#" con "%23"
 
Ad esempio:
http://www.sito.com/pagine/lista%23page=1
 
 
 
In generale, la regola è questa:
1 - prendi il codice ascii del carattere che ti "crea problemi"
2 - converti il numero del punto 1 in esadecimale
3 - nel link, sostituisci il carattere scrivendo % seguito dal valore del 
punto 2
 
 
Ciao, Mario

 commento:
 
No. 
 
Il problema è che # nell'url indica al browser l'anchor a cui 
posizionarsi nella pagina e non viene mandato al server. In soldoni il 
browser scarica tutta la pagina (nell'url, fino al cancelletto) e poi la 
scorre fino a trovare l'anchor (dopo il cancelletto).
 
Esempio:
 
wget 
http://localhost/index.html#page=1
 
 
127.0.0.1 - - [15/Jan/2014:20:41:52 +0100] "GET /index.html HTTP/1.1" 200 
3700 "-" "Wget/1.14 (linux-gnu)" "-"
 
Se la stessa riga la metto nel browser:
 
127.0.0.1 - - [15/Jan/2014:20:40:26 +0100] "GET /index.html HTTP/1.1" 200 
3700 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 
Firefox/26.0" "-"
 
Quindi spiega meglio quello che vuoi fare, perché a lume di naso è una 
cosa che con wget non si può fare. 

 cosa che con wget non si può fare.
 
Ti ringrazio per la risposta, mi ero dimenticato che # indica l'anchor,
quindi mi sono andato a studiare meglio l'HTML della pagina in questione
e ho notato che la paginazione (i numeri i basso) non richiamano link del
tipo wget 
http://sito/index.html#page=1
, ma semplicemente "#" ed una 
funzione javascript usando onclick, quindi sicuramente si tratta di qualche
procedura particolare di qualche linguaggio di programmazione lato server,
In pratica il # non viene usato come anchor, ma serve per ricaricare la 
stessa pagina e ri-elaborarla lato server.
Quindi penso che con wget non sia fattibile la cosa, o comunque andrebbe 
fatto qualche artificio, quindi ci rinuncio e faccio il lavoro manualmente
salvando le 30 pagine con il browser.
Vi ringrazio comunque per avermi chiarito le idee e farmi decidere a passare
al modo manuale.
Grazie
 

    wget --append-output=log.txt "
http://www.sito.com/pagine/lista#page=$X
;"
 
Metti i singoli apici:
wget --append-output=log.txt '
http://www.sito.com/pagine/lista#page=$X
;'
 
Se metti le virgolette, questo ti protegge dagli spazi ma *non* 
dall'espansione di bash (e # ha un significato).
Con l'apice, viene inibita qualsiasi espansione di bash e quindi il # 
verrà visto come # e basta.
 
-- 
Massimo Bacilieri AKA Crononauta


Vi ringrazio tutti per l'aiuto, ma manco cosi' funziona.
Come hai scritto tu, anche il page=$X non cambia e rimane tale senza essere 
sostituito dalla numerazione progressiva.
Provato anche cosi':
 
wget --append-output=log.txt '
http://www.sito.com/pagine/lista#page='$X
;
 
Ma non va bene lo stesso in quanto scarica tutte pagine uguali a:
http://www.sito.com/pagine/lista
 
 
Grazie a tutti, ma passo a farlo a mano, per fortuna non sono tanti.
Spero che non si ripeta un problema simile per moltissime pagine.
 

 verrà visto come # e basta.
 
Anche se metti i doppi apici o se non metti niente se è per questo. Basta 
provare a fare:
echo 
http://www.sito.com/pagine/lista#page=$X
;
 
Il problema non è che il carattere # ha un significato per bash bensì per 
http. Anche se la metti nel browser questo si comporta in modo identico.
 
 


Il # viene usato come escamotage e non come anchor.
Infatti penso che venga usato ajax per la paginazione per non ricaricare 
tutta la pagina, quindi usando wget, ma ho provato anche ad usare il "Salva 
pagina come.." del browser e' uguale, mi scarica sempre e' soltanto la prima 
pagina. Le altre pagine penso siano dinamiche e usano ajax o simile e quindi 
non si puo' fare nulla.
Grazie lo stesso, ho risolto a mano.


  Sbagliato.
Tra doppi apici tutti i caratteri sono considerati letterali tranne:
 
1) $ (dollaro)
2) ` (accento)
3) \ (backslash)
4) ! (punto esclamativo)
 
  In particolare, tra doppi apici il carattere # è considerato alla stregua
di qualsiasi carattere letterale, e non c'è differenza con il metterlo tra
singoli apici.
 
  Per ulteriori informazioni, man bash(1), sezione QUOTING.
 
 
  Ciao,
 
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.


Facebook: Massimo Bacilieri

 ${P#PA}
 
  E quindi?  Stai confondendo due cose diverse.
Anche nel tuo esempio il carattere # è assunto letterale.  Solo che, come
molti altri caratteri, non può far parte di un nome di variabile, che, come
puoi leggere in man bash(1), sezione DEFINITIONS, può solamente:
 
1) contenere caratteri alfanumerici e il carattere "_";
2) inizia con un carattere alfabetico o il carattere "_".
 
  Quello che hai scritto tu non è dovuto al fatto che il carattere "#" sia
trattato come un contrassegno di inizio commento, altrimenti la shell
avrebbe eseguito, nella seconda riga, il comando:
 
echo ${P
 
 che è una riga sintatticamente incompleta che provoca, inuna shell
interattiva, l'apertura del propmpt secondario.  Quello che è invece
successo è stato un "matching prefix pattern removal", come nel caso seguente:
 
[alessandro@hal9k ~ ]$ PANINO='col formaggio'
[alessandro@hal9k ~ ]$ echo ${PANINO#col }
formaggio
[alessandro@hal9k ~ ]$
 
  Per i dettagli consiglio di prendere confidenza con man bash(1).


    Per i dettagli consiglio di prendere confidenza con man bash(1).
 
"Fate come dico, non fate come faccio".
Saluti.


 Stai delirando?
 
  Ah ecco, è finalmente saltato fuori il ghigno del trollone che non sa
mandare giù l'essere stato scoperto nella sua ignoranza.
 
 
  Fine delle trasmissioni.


>
[CUT]
 
Se riferisci alla bash ti posso assicurare che il # od una stringa che 
inizia con # non viene espansa dentro i doppi apici
 
Fuori è l' inizio di un commento
 
 


  Quello che Crononauta ha scritto è come sostenere che nessun carattere
alfanumerico è protetto dall'espansione tra doppi apici.  La prova?
 
$ echo "$BASH"
/bin/bash
 
  Secondo lui solo i singoli apici danno questa protezione.  La prova?
 
$ echo '$BASH'
$BASH
 
  Non gli entra in testa che non sono i caratteri alfabetici BASH che
eseguono l'espansione, ma il carattere "$".
 
  Bah.
 
 
  Buonanotte a tutt?.



Va bene, avrà appreso qualcosa di nuovo
 

 Se ci metti i singoli apici, invece, hai questa certezza.
 
Scusa ha ragione lui, stai confondendo eccome e tu hai fatto un esempio 
del piffero. Lì ciò che viene espanso è ${} ed è nel contesto 
dell'espansione di quest'ultimo che il carattere # assume un significato 
particolare.
 
echo "PATTERN #"
 
echo 'PATTERN #'
 
danno ovviamente lo stesso identico risultato. Così come:
 
echo PATTERN#
 
echo "PATTERN#"
 
echo 'PATTERN#'
 
ti lascio come esercizio spiegare il perché.
 
 
 
 

 ...
 
Questo è quello che hai letti tu, non quello che ha scritto Crononauta.
 
 

 particolare.
 
Quale parte di "dentro i singoli apici hai la certezza che # venga 
trattato testualmente, mentre dentro i doppi apici no" non è chiara?


 dell'espansione, ma questi caratteri sono e rimangono letterali.
 
Non diciamo idiozie.
Se sono elementi sintattici (operatori) di un'espansione, per 
definizione, non possono essere caratteri letterali.
 
Sorvolo sul resto, che è irrilevante.


 Saluti.
 
Pur condividendo quanto hai scritto voglio sottolineare che le espansioni 
della bash (e sono ben sette) avvengono su stringe e non su singoli 
caratteri per cui ha senso chiedersi se "#" sia un carattere letterale od 
un operatore ma ha poco senso chiedersi se viene espanso o in che 
cosa viene espanso appunto perché viene espansa la stringa di cui "#"
fa parte.
 

  ...
 
Cioè ti stai contraddicendo da solo. Proprio perché la bash espande 
stringe e non caratteri:
  1) non ha senso chiedersi se "#" o "$" vengono espansi od 
      in che cosa vengono espansi
  2) un carattere sarà interpretato come un operatore o come
      un letterale solo in funzione della sintassi della 
      espansione che si sta effettuando anche all'interno 
      delle virgolette.
Cioè stai montando una polemica senza senso.


Vabeh visto che come minimo ciurli nel manico direi che per questa 
discussione ho già dato.


  La documentazione e i fatti dicono che:
 
A) il carattere "#" da solo non introduce *MAI* nessuna espansione, né
quendo e da solo, né quando è tra doppi apici, né quando è tra singoli apici;
B) la sola espansione cui partecipa il carattere "#" è l'espansione dei
parametri posizionali, se e solo se appare dopo il carattere "$%";
 
Si faccia riferimento a man bash(1), sezione EXPANSION.
 
  Chi scoprisse e documentasse comportamenti difformi da quanto scritto,
apra un bug report a 
bug-...@gnu.org
 e si goda la relativa gloria.
Altrimenti fare silenzio, grazie.
 
  Astenersi ignoranti e perditempo.
 
 
  Ciao,


 Sorvolo sul resto, che è irrilevante.
 
  Ossia: la mia ignornanza è soverchia e non sono capace di argomentare le
mie idee oltre a dire "gne gne gne, ho ragione io e torto te".
 
  La documentazione e i fatti dicono che:
 
A) il carattere "#" da solo non introduce *MAI* nessuna espansione, né
quendo e da solo, né quando è tra doppi apici, né quando è tra singoli apici;
B) la sola espansione cui partecipa il carattere "#" è l'espansione dei
parametri posizionali, se e solo se appare dopo il carattere "$%";
 
Si faccia riferimento a man bash(1), sezione EXPANSION.
 
  Chi scoprisse e documentasse comportamenti difformi da quanto scritto,
apra un bug report a 
bug-...@gnu.org
 e si goda la relativa gloria.
Altrimenti fare silenzio, grazie.
 
  Astenersi ignoranti e perditempo.
 
 
  Ciao,
 
 


 dei parametri posizionali, se e solo se appare dopo il carattere "$%";
 
 
Stronzate! Prima di tutto ``$#'' è un parametro speciale non un parametro 
posizionale e poi "#", oltre ad essere il carattere di commento di default,
partecipa pure all'espansione dello storico, all'espansione delle variabili 
ed all'espansione degli array (che in realtà è un caso particolare 
dell'espansione dei parametri e delle variabili).
 
 
 
 
 

 dell'espansione dei parametri e delle variabili).
 
  Il che non solo non smentisce, ma conferma quanto ho scritto.  Oltre a non
dire nulla sul fatto che un carattere speciale non introduce mai alcuna
espansione, al contrario dei caratteri "$", "`" e "!", ma partecipa come
elemento sintattico di altre espansioni in quanto carattere letterale.


 espansione,
 
  Ossia, *il* carattere speciale "#", come pure qualsiasi carattere oltre
quelli elencati dopo.


 ...
 
Davvero con te non vale la pena perdere tempo.
 
 

 che è una cosa sacrosanta.
 
 
Sacrosanta un par di palle.
 
Hai fatto benissimo a fare questa citazione perché nel mirror climbing di 
Crononauta c'eravamo persi. In quel caso come è facile verificare che tu 
metta i doppi apici, i singoli apici o addirittura niente non cambia una 
ceppa. Infatti il problema dell'OP non era (ovviamente) quello.
 
Il cancelletto SOLO se preceduto da spazio viene interpretato come 
separatore di commento, ma ovviamente questa interpretazione viene 
neutralizzata sia dai doppi apici che dai singoli apici proprio perché 
non è in ballo nessuna espansione. Il cancelletto è un carattere 
"speciale" ne più ne meno di quando lo sia lo spazio.
 
 
 

    wget --append-output=log.txt "
http://www.sito.com/pagine/lista#page=$X
;"
 
 
Metti i singoli apici:
wget --append-output=log.txt '
http://www.sito.com/pagine/lista#page=$X
;'
 
Se metti le virgolette, questo ti protegge dagli spazi ma *non*
dall'espansione di bash (e # ha un significato).
Con l'apice, viene inibita qualsiasi espansione di bash e quindi il #
verrà visto come # e basta.
 
 
--
Massimo Bacilieri AKA Crononauta
 
 


 apra un bug report a 
bug-...@gnu.org
 e si goda la relativa gloria.
 
Non c'è nessun bug da segnalare, perché tutto funziona esattamente come 
documentato. Il più è capirlo.
 
Semmai, l'unica obiezione che andava fatta, e che non hai fatto, è molto 
più semplice:
 
wget "
http://www.sarcazzo.it/index.html#tag1
"
 
qui, e solo qui (ma non in senso generale), non ha senso preoccuparsi di 
# perché in questo caso *non è* operatore visto che non vi è espansione. 
Questa era la mia svista, in questo specifico caso, l'unica cosa che 
andava fatta notare, per cui si poteva *anche* lasciare i doppi apici 
senza cadere in comportamenti inattesi.
La mia osservazione, pur sacrosanta in linea generale, semplicemente qui 
non era applicabile.
 
Non tutta la quantità spaventevole di stronzate che hai tirato fuori, 
per il puro gusto di polemica.


 fa parte.
 
Se la mettiamo dal punto di vista lessicale, hai ragione, # è operatore 
di espansione, non viene espanso esso stesso.
 
Ciò non toglie che stiamo divagando, il punto di partenza era molto più 
semplice: dentro i doppi apici # può "significare qualcosa" dal punto di 
vista di un'espansione; dentro i singoli apici, # vale come carattere # 
(cioè ascii(35)) e niente altro.
 
Qua c'è gente che sta negando tale concetto lapalissiano, mah.


 Qua c'è gente che sta negando tale concetto lapalissiano, mah.
 
 
Condivido 
 

 Qua c'è gente che sta negando tale concetto lapalissiano, mah.
 
No caro mio, sei te che meni il can per l'aia. Il punto di partenza era 
un altro: l'OP ha chiesto perché un url passato come parametro a wget 
*apparentemente* tronca in presenza del carattere #, tu hai risposto che 
la soluzione stava nell'usare i singoli apici perché, secondo te, il 
problema era una presunta espansione del carattere #. Io ti ho spiegato e 
dimostrato che poteva usare singoli apici, doppi apici oppure nessuno dei 
due che in ogni caso quel cancelletto veniva trattato come letterale, 
tant'è che il problema non era della shell ma della invocazione HTTP per 
il quale il carattere # nell'url ha sì un significato importante. A quel 
punto ti sei buttato nel mirror climbing estremo tirando in ballo l'uso 
di # all'interno delle espansioni, cosa che non c'entra assolutamente 
NULLA ne con il problema iniziale ne con le successive confutazioni. Al 
che ho smesso di discutere con te, fino ad ora che in un picco di 
disonestà vai tacciando gli altri di negare il lapalissiano... eh no, 
caro mio, te lo faccio dire da Jules Winnfield: 
http://www.youtube.com/watch?v=IjpTHdo30T4
 
 

 ...
 
No bellino, ti potrei anche dare ragione se ti fosti fermati qui. Hai
ragione, il problema dell'OP riguardava il significato di "#" per HTML
e con la bash non c'entra una cippa di cazzo; tu hai indovinato e
Crononauta ha fatto una ipotesi errata. Tanto di capello. 
 
Però tu ti hai proseguito, ti sei arrampicato sugli specchi negando 
le cose più elementari della bash e negando persino i i manuali;
sarai anche un cosiddetto esperto di HTML ma rimani sempre 
un bellino (sì, ho fatto la naja in Liguria).
 

 cose più elementari della bash e negando persino i i manuali; 
 
Cos'è che avrei negato?