# cut -d"ACAPO" -f2 [RISOLTO]

## HoX

Devo usare il comando cut in uno script, ma il problema è che il carattere che devo usare come delimitatore è il carattere a_capo (\n).

Seguendo il man di cut dice di inserire semplicemente un a capo tipo

```
cut -d'

' -f2
```

che funziona benissimo da console, ma mi paralizza lo script e non si muove più...

avete suggerimenti su come fare?

per ora io ho trovato questo workaround

```
tr "\n" "°" | cut -d'°' -f2
```

ma se esistesse qualcosa di più pulito (e che non mi pregiudichi l'utilizzo di un carattere (in questo caso '°')) preferirei... consigli?Last edited by HoX on Mon Jun 04, 2007 8:14 pm; edited 1 time in total

----------

## Luca89

Prova così:

```
cut -d$'\n'
```

----------

## HoX

 *Luca89 wrote:*   

> Prova così:
> 
> ```
> cut -d$'\n'
> ```
> ...

 

Funziona... grazie mille!

----------

## gutter

Moved from Forum italiano (Italian) to Forum di discussione italiano.

----------

## drizztbsd

????

non ha molto senso usare cut con \n imho (e considera che non è portable $'\n')

io di solito gioco di read

----------

## nick_spacca

 *Drizzt Do` Urden wrote:*   

> ????
> 
> non ha molto senso usare cut con \n imho (e considera che non è portable $'\n')
> 
> io di solito gioco di read

 

Perché? questi tips interessano anche me, che spesso mi imbatto in cazzatine bash con cut (tipo anche con il tab '\t') ...potresti spiegarmi meglio cosa intendi?

----------

## drizztbsd

 *nick_spacca wrote:*   

>  *Drizzt Do` Urden wrote:*   ????
> 
> non ha molto senso usare cut con \n imho (e considera che non è portable $'\n')
> 
> io di solito gioco di read 
> ...

 

cut di default usa \t e va bene  :Razz: 

$'' è una estensione di bash e non è POSIX compatibile (che ne so se ti serve usarlo con (d)ash o busybox sh)

se devi prendere la seconda riga di un file lo puoi fare in diversi modi POSIX compliant, quello consigliato è 

```
head -n 2 $FILE | tail -n 1
```

----------

## mouser

Ma scusa, invece di usare cut -d"a_capo" o con il \t come ti consigliano, non è più comodo buttare tutto in una variabile (anche i \n) e fare un bel

```
echo -e $VARIABILE | while read LINEA; do

...

done
```

???

Ciriciao

mouser  :Wink: 

----------

## djinnZ

se non ricordo male:

tail usa una fopen che scorre il file un blocco alla volta ed a parte il buffer non impegna altro mentre con la variabile carichi l'intero file nell'abiente e quindi consumi maggiori risorse ma dovrebbe essere leggermente più immediato visto che è tutto builtin.

Se sei certo che il peggio che ti capita sono una decina di righe di non più di un centinaio di caratteri e non rischi di avere molte istanze sarebbe preferibile anche per me ma se non è così perchè buttar via risorse o rischiare di esaurilrle?

Tanto per cambiare è questione di "dove, quando e come". Che poi lo scripting (ba)sh sia un esercizio di minimalismo per tradizione fa sempre brodo.

Un poco come il dilemma dell'usare tar -xf - | bzip o tar file ; bzip file per capirci.

----------

## Dr.Dran

Ehm... e scusate se modifichiamo provvisoriamente il valore della variabile ambiente IFS e facciamo un ciclo for?

Questo è un semplice esempio:

```
#!/bin/bash

IFS=$'\n'

for i in $(cat prova.txt); do

        echo $i;

done

#oppure senza modificare IFS

echo -e "\t"

#oppure senza modificare IFS

cat prova.txt | while read LINEA; do

        echo $LINEA;

done
```

il file prova.txt

```
Questa è una prova 1

Questa è una prova 2

Questa è una prova 3

Questa è una prova 4
```

L'output generato è:

```
 bash prova.sh

Questa è una prova 1

Questa è una prova 2

Questa è una prova 3

Questa è una prova 4

Questa è una prova 1

Questa è una prova 2

Questa è una prova 3
```

Mentre il primo ciclo assegna ad $i ogni stringa delimitata con '\n' il secondo suggerito giustamente da mouser mi esclude l'ultima poichè nel file non è inserito lo stesso carattere in coda all'ultima stringa. (N.B. è da notare poichè se è uno stream o un flusso che tu intercetti da chissadove non è detto che il file termini con il newline o altro)

@djinnZ

La tua considerazione su tail ed head è corretta, ma dovresti avere a che fare con uno file che conosci per dimensione, oppure dovresti inserire in un ciclo il comando che ha suggerito Drizzt Do` Urden.

Cheers

Franco

----------

## djinnZ

Usando IFS il risultato è lo stesso, sempre usi una variabile.

In più anche read obbedisce ad IFS in bash.

Quanto alla dimensione se pensi di affrontare il parsing di un file di configurazione o di una lista di utenti (che per quanto relativamente enormi avranno sempre dimensioni accettabili) una soluzione vale l'altra.

Se invece devi lavorare su un log che può assumere facilmente dimensioni inumane la soluzione di drittzt è quella più indicata. Dato che tradizionalmente in ambito posix si pensa sempre in grande e si cercano di evitare legacy è la via più "corretta".

Forse sarebbe stato più chiaro se invece di dimensioni avessi parlato di ordini di grandezza.

----------

## Dr.Dran

@djinnZ

Concordo con ciò che hai detto, l'unica cosa è che sarebbe stato bello sapere su cosa si stava lavorando.

Cheers

Franco

----------

