[articolo]Primo incontro con la shell testuale

[heba]

non vorrei offendervi, ma ci sono alcune imprecisioni di cui volevo portarvi a conoscenza.

Quando si accede alla shell di linux di solito si entra già nella

/home/nomeutente

dedicata all'utente stesso, questo perché di solito l'utente non ha permessi speciali per accedere alla shell, per attivare un altro utente si lancia il comando

sudo

verrà chiesto nome utente e pass.

per accedere come root, solo


su

Una seconda inesattezza, c'è quando parlate del manuale. Quando si lancia il comando

man [nomecomando]

si accede al manuale in versione testuale, ma non è l'help della shell

la shell ha un suo help testuale diverso dal manuale e si lancia con questo comando

nomecomando --help

l'help è di solito in inglese e fa vedere solo il comando con le opzioni, il manuale invece è più completo.

per chi viene da dos è più semplice utilizzare il comando dir per vedere il contenuto di una directory, il comando dir visualizza file e cartelle in ordine alfabetico e se sono tante in colonnate.

il comando rm non chiede nessuna conferma prima di eliminare il file, per le directory si usa rmdir. o

rm -r o -R

per scrivere dei programmi di shell è sufficiente utilizzare il C o il C++ in abbinamento ai comandi shell, utilizzando uno scrittore di file testuali, di solito si usa vim, richiamabile con

vim

[thomas]

Bene per i suggerimenti; capirai anche che data l'enormità di numeri di versione e comportamenti differenti, magari anche piccoli, da un sistema all'altro, è impossibile fare qualcosa di globalmente valido.

Molto dipende dalla distribuzione, dalla versione della shell, da come è impostata e da quanto sia vergine... infatti alcune vengono precaricate con configurazione che aiutano gli utenti, ma che poi rendono meno pura la shell di base.

Anche nelle tue osservazioni, ad esempio, c'è qualche imprecisione; ne approfitto per fare delle considerazioni utili per tutti.

per attivare un altro utente si lancia il comando

sudo

verrà chiesto nome utente e pass.

per accedere come root, solo


su

E' esattamente il contrario
sudo = super user do, quindi verrà chiesto di inserire la propria pass ed il comando a seguire verrà eseguito con i permessi di super user... Ovviamente bisogna permettere all'utente di eseguire comandi come sudo, quindi impostare l'utente e l'ambito d'azione nel file "sudoers", tramite il comando "visudo".
La sintassi corretta sarebbe

Codice: Seleziona tutto

$ sudo ls
<inserire la propria password>

Codice: Seleziona tutto

$ sudo -s
<inserire la propria password>

Il primo esegue "ls" con i permessi da super user, il secondo apre una shell con i permessi da super user (per eseguire un po' più di un paio di comandi in sequenza).
La particolarità di questo comando è che permette di disabilitare l'utente root dal sistema e quindi stare in un certo qual senso tranquilli, in quanto proprio l'utente più pericoloso è disabilitato; d'altro campo, porta anche molti bachi e potenziali punti di ingresso incontrollati al sistema... quindi, attenzione.

su = substitute user, permette di eseguire la shell con il nome utente di un altro user.
Esempio

Codice: Seleziona tutto

[thomas]$ su pippo
<inserire la password di pippo>
[pippo]$ ...

oppure, senza specificare il nome utente, viene inteso quello di root

Codice: Seleziona tutto

[thomas]$ su
<inserire la password di root>
[root]#

Una seconda inesattezza, c'è quando parlate del manuale. Quando si lancia il comando

man [nomecomando]

si accede al manuale in versione testuale, ma non è l'help della shell

la shell ha un suo help testuale diverso dal manuale e si lancia con questo comando

nomecomando --help

l'help è di solito in inglese e fa vedere solo il comando con le opzioni, il manuale invece è più completo.

Allora, la shell è l'interprete dei comandi che vengono lanciati; la shell è di solito un programma testuale e come tutti i programmi ha anch'essa un manuale; se parliamo di bash:

Codice: Seleziona tutto

[thomas]$ man bash

permette di accedere al manuale di bash, così come specificando un qualsiasi altro nome di programma si accede al suo manuale (se fornito).
Diversamente il parametro da te indicato (sempre prendendo ad esempio bash)

Codice: Seleziona tutto

[thomas]$ bash --help

di solito si utilizza per avere una veloce panoramica sul modo di inserire i parametri o per vedere i parametri accettati dal programma stesso; normalmente viene invocato anche quando l'utente sbaglia ad inserire i parametri, magari l'ordine o la precedenza.

Poi c'è un'altro sistema di informazioni sui programmi, che si chiama "info"; non ho molta cultura in merito, ma credo voglia soppiantare man, anche se lo trovo veramente difficile; si utilizza come "man" ed ha il suo stesso scopo

per chi viene da dos è più semplice utilizzare il comando dir per vedere il contenuto di una directory, il comando dir visualizza file e cartelle in ordine alfabetico e se sono tante in colonnate.

Questa è, diciamo, grave:
"dir" non è un comando di shell, non è nemmeno un programma; è semplicemente un alias per un altro comando, ovvero una parametrizzazione di "ls" e più specificatamente

dir (installato anche come d) equivale a «ls -C -b»; cioè i file sono di natura elencati in colonne, ordinati verticalmente. vdir (installato anche come v) equivale a «ls -l -b»; cioè i file sono di natura elencati nel formato lungo.

il comando rm non chiede nessuna conferma prima di eliminare il file, per le directory si usa rmdir. o

rm -r o -R

E' vero, nella sua installazione base rm è pericoloso perché non chiede conferma prima di eliminare, ma basta farlo seguire dal parametro "i" per ottenere quel comportamento

Codice: Seleziona tutto

[thomas]$ rm -i

Utile sarebbe definire un'alias a questo scopo negli startup file della shell in uso........... appena trovo un'oretta di tempo scriverò qualcosa a proposito degli alias.
"rmdir" è diverso da "rm -r", in quanto il primo cancella directory vuote, mentre il secondo cancella ricorsivamente (r) tutti i file a partire da quello specificato, un po' di chiarezza:
in linux tutto è un file, una directory è un file, quindi se scrivo

Codice: Seleziona tutto

[thomas]$ rm -r /home/thomas

dico alla shell che intendo cancellare il file "/home/thomas" e se quello è una directory, il parametro "r" entra nella directory ed applica il comando "rm" a tutti i file ivi presenti... è l'unico metodo per cancellare le directory non vuote.
Anche qui, sarebbe utile farlo in modo interattivo (parametro i), facendoci chiedere conferma ogni volta prima di cancellare un file...

Codice: Seleziona tutto

[thomas]$ rm -ir /home/thomas

per scrivere dei programmi di shell è sufficiente utilizzare il C o il C++ in abbinamento ai comandi shell, utilizzando uno scrittore di file testuali, di solito si usa vim, richiamabile con

vim

C o C++ sono storicamente i più utilizzati linguaggi di programmazione, utilizzati anche per scrivere i programmi testuali, utilizzabili quindi nelle shell.... ma non solo; è necessario però avere un'attimo di confidenza con la programmazione in generale.
Più immediati invece i linguaggi di scripting, come perl, php, ... la shell stessa, bash ad esempio, contiene un set di utility davvero utili per scrivere script anche complessi; uno script non è altro che un insieme di comandi che altrimenti dovresti battere a mano; normalmente si scrivono script per semplificare sessioni di lavoro monotone e sempre uguali...
Anche qui, una qualche oretta di tempo, dopo l'estate e vi verrò incontro.




Ah, spero non ti sia offeso e..... BENVENUTO!
Ci servono persone con esperienza Linux!!!

[mofo]

a proposito di rm... non e' sempre vero che la versione di default sfugga alla richiesta di conferma... varia da distro a disto... solitamente la conferma c'e' e viene richiesta nelle distro piu' "semplici" (mandriva ad esempio) nel qual caso si puo' "evitare" applicando al comando la flag -f quindi per cancellare brutalmente un ramo di directory si fara

rm -rf nomecartella/

(dove -r sta come gia' detto per "recursive" e -f per "force" ed e' l'esatto opposto di del flag -i)

a proposito dell'articolo... agetty non si trova sempre con ctrl+alt+f[1...4]... anche questo dipende dalle distro... in slackware ad esempio l'unica agetty di default e' in f6

[heba]

Bene per i suggerimenti; capirai anche che data l'enormità di numeri di versione e comportamenti differenti, magari anche piccoli, da un sistema all'altro, è impossibile fare qualcosa di globalmente valido.

Molto dipende dalla distribuzione, dalla versione della shell, da come è impostata e da quanto sia vergine... infatti alcune vengono precaricate con configurazione che aiutano gli utenti, ma che poi rendono meno pura la shell di base.

vero, se usi less o cat su mandrake non funziona, perché non sono di default, se lo usi su altre distribuzioni funzionano perfettamente.

per attivare un altro utente si lancia il comando

sudo

verrà chiesto nome utente e pass.

per accedere come root, solo


su

E' esattamente il contrario
sudo = super user do, quindi verrà chiesto di inserire la propria pass ed il comando a seguire verrà eseguito con i permessi di super user... Ovviamente bisogna permettere all'utente di eseguire comandi come sudo, quindi impostare l'utente e l'ambito d'azione nel file "sudoers", tramite il comando "visudo".
La sintassi corretta sarebbe

Codice: Seleziona tutto

$ sudo ls
<inserire la propria password>

Codice: Seleziona tutto

$ sudo -s
<inserire la propria password>

Il primo esegue "ls" con i permessi da super user, il secondo apre una shell con i permessi da super user (per eseguire un po' più di un paio di comandi in sequenza).
La particolarità di questo comando è che permette di disabilitare l'utente root dal sistema e quindi stare in un certo qual senso tranquilli, in quanto proprio l'utente più pericoloso è disabilitato; d'altro campo, porta anche molti bachi e potenziali punti di ingresso incontrollati al sistema... quindi, attenzione.

su = substitute user, permette di eseguire la shell con il nome utente di un altro user.
Esempio

Codice: Seleziona tutto

[thomas]$ su pippo
<inserire la password di pippo>
[pippo]$ ...

oppure, senza specificare il nome utente, viene inteso quello di root

Codice: Seleziona tutto

[thomas]$ su
<inserire la password di root>
[root]#

non lo so, ho su debian, quindi posso parlare solo per debian e al massimo mandrake che sono le distribuzioni che ho e sto utilizzando tutt'ora (debian)
sul man di sudo c'è scritto:

Sudo, sudoedit - execute a command as another user
se riesco vi allego la parte del manuale che lo riguarda
su permette di usare o un altro utente se specificato o semplicemente root, si può anche usare su-to-root.

Una seconda inesattezza, c'è quando parlate del manuale. Quando si lancia il comando

man [nomecomando]

si accede al manuale in versione testuale, ma non è l'help della shell

la shell ha un suo help testuale diverso dal manuale e si lancia con questo comando

nomecomando --help

l'help è di solito in inglese e fa vedere solo il comando con le opzioni, il manuale invece è più completo.

Allora, la shell è l'interprete dei comandi che vengono lanciati; la shell è di solito un programma testuale e come tutti i programmi ha anch'essa un manuale; se parliamo di bash:

Codice: Seleziona tutto

[thomas]$ man bash

permette di accedere al manuale di bash, così come specificando un qualsiasi altro nome di programma si accede al suo manuale (se fornito).
Diversamente il parametro da te indicato (sempre prendendo ad esempio bash)

Codice: Seleziona tutto

[thomas]$ bash --help

di solito si utilizza per avere una veloce panoramica sul modo di inserire i parametri o per vedere i parametri accettati dal programma stesso; normalmente viene invocato anche quando l'utente sbaglia ad inserire i parametri, magari l'ordine o la precedenza.

concordo, ma è la stessa cosa che ho detto io.... L'help è molto meno preciso e da una scorsa al comando ed alle sue opzioni, mentre il manuale è molto più completo e preciso, spiegando fin nei minimi dettagli il suo utilizzo. Il manuale non è solo in maniera testuale ma anche visiva, infatti se si va nella sezione manuali di kde si trova tutto il manuale al completo, ma non è in forma testuale, ma viene visualizzato sul browser. Ti faccio un esempio se provi a scrivere


man fsck
che è il comando per la riparazione dei filesystem ti fa vedere il manuale a riguardo

se invece mandi il comando

fsck --help o -h

ti rimanda questa scritta:

heba@heba:~$ fsck --help
bash: fsck: command not found
heba@heba:~$

in realtà il comando esiste eccome, come puoi notare dal manuale e funziona pure.

Poi c'è un'altro sistema di informazioni sui programmi, che si chiama "info"; non ho molta cultura in merito, ma credo voglia soppiantare man, anche se lo trovo veramente difficile; si utilizza come "man" ed ha il suo stesso scopo

sì effettivamente rimanda alla stessa pagina di manuale di man, non ci sono differenze, la motivazione per cui è stato creato non la so, sinceramente.

per chi viene da dos è più semplice utilizzare il comando dir per vedere il contenuto di una directory, il comando dir visualizza file e cartelle in ordine alfabetico e se sono tante in colonnate.

Questa è, diciamo, grave:
"dir" non è un comando di shell, non è nemmeno un programma; è semplicemente un alias per un altro comando, ovvero una parametrizzazione di "ls" e più specificatamente

dir (installato anche come d) equivale a «ls -C -b»; cioè i file sono di natura elencati in colonne, ordinati verticalmente. vdir (installato anche come v) equivale a «ls -l -b»; cioè i file sono di natura elencati nel formato lungo.

[/quote]
non proprio sono elencati nel formato lungo solo se sono pochi, se sono tanti come nella directory /etc ti garantisco al cento per cento che vengono elencati in colonne, anche se io non ho mai detto che è un programma, è un comando che per chi viene da dos, è più semplice utilizzare, nulla di più alla fin fine fa il suo lavoro, come info al posto di man, ognuno utilizza ciò per cui è più comodo e per il lavoro che deve fare. Se dovrò controllare le directory di un pc solo e di un utente solo, sarà più comodo usare dir, se dovrò controllare le directory di trecento utenti che usano il mio sistema, molto più comodo ls

il comando rm non chiede nessuna conferma prima di eliminare il file, per le directory si usa rmdir. o

rm -r o -R

E' vero, nella sua installazione base rm è pericoloso perché non chiede conferma prima di eliminare, ma basta farlo seguire dal parametro "i" per ottenere quel comportamento

Codice: Seleziona tutto

[thomas]$ rm -i

Utile sarebbe definire un'alias a questo scopo negli startup file della shell in uso........... appena trovo un'oretta di tempo scriverò qualcosa a proposito degli alias.

vero, ma nell'articolo non è stato specificato, quindi è un'inesattezza dire che rm rimuove i file chiedendoti conferma, in realtà non lo fa se non gli si da quel parametro che hai detto tu.

"rmdir" è diverso da "rm -r", in quanto il primo cancella directory vuote, mentre il secondo cancella ricorsivamente (r) tutti i file a partire da quello specificato, un po' di chiarezza:
in linux tutto è un file, una directory è un file, quindi se scrivo

Codice: Seleziona tutto

[thomas]$ rm -r /home/thomas

no, in linux non è tutto un file, quando provi a cancellare una directory con rm ti dice non è un file è una directory:

heba@heba:~$ rm EXCEL
rm: impossibile rimuovere `EXCEL': Is a directory
heba@heba:~$

se fosse tutto un file, l'avrebbe eliminata senza problemi, invece mi rimanda quel comando, attenzione a dire che in linux è tutto un file, anche perché linux differenzia assolutamente queste cose, anzi per lui è importantissimo differenziare.

dico alla shell che intendo cancellare il file "/home/thomas" e se quello è una directory, il parametro "r" entra nella directory ed applica il comando "rm" a tutti i file ivi presenti... è l'unico metodo per cancellare le directory non vuote.
Anche qui, sarebbe utile farlo in modo interattivo (parametro i), facendoci chiedere conferma ogni volta prima di cancellare un file...

Codice: Seleziona tutto

[thomas]$ rm -ir /home/thomas

sì, ma nell'articolo non si è stati chiari, mi spiego se inserisci il parametro puoi cancellare tutto l'albero un po' come deltree in dos, mentre se usi rmdir cancelli la directory, sarebbe meglio evitare di usare rm -r per evitare di cancellare file alla cieca. Mi spiego potrei essermi dimenticata un file in una directory che non doveva essere cancellato, se uso quel comando potrei eliminarlo. Questione di sicurezza personale, poi come ho detto ognuno libero di usare i comandi che più ritiene giusti.

per scrivere dei programmi di shell è sufficiente utilizzare il C o il C++ in abbinamento ai comandi shell, utilizzando uno scrittore di file testuali, di solito si usa vim, richiamabile con

vim

C o C++ sono storicamente i più utilizzati linguaggi di programmazione, utilizzati anche per scrivere i programmi testuali, utilizzabili quindi nelle shell.... ma non solo; è necessario però avere un'attimo di confidenza con la programmazione in generale.
Più immediati invece i linguaggi di scripting, come perl, php, ... la shell stessa, bash ad esempio, contiene un set di utility davvero utili per scrivere script anche complessi; uno script non è altro che un insieme di comandi che altrimenti dovresti battere a mano; normalmente si scrivono script per semplificare sessioni di lavoro monotone e sempre uguali...
Anche qui, una qualche oretta di tempo, dopo l'estate e vi verrò incontro.

se ti riferisci a if, for, while eccetera eccetera, sì la bash li contiene, ma non sono comandi linux, ma comandi di programmazione reale, mi spiego si usano in Cobol, in Pascal, in Turbo Pascal, in C, in C++, in Visual C o C# e Vusuak C++, in PHP, in Asp, in Perl, eccetera eccetera. Gli script che si scrivono in bash sono in C, semplicemente perché il kernel e la maggior parte del sistema operativo è programmato in C, quindi la shell deve scrivere in C per poter far capire al traduttore del linguaggio macchina cosa dire al sistema operativo quando traduce in binario il tutto.
Poi boh...sarò rimasta l'unica, ma sono convinta che script complessi se non si hanno le basi della programmazione è difficile che si riesca a utilizzare i comandi appropriati, diciamo coscienziosamente e non per intuito, sia chiaro, ci possono essere dei bravissimi programmatori anche se non sono diplomati o laureati tali. Magari sbaglio, ma l'esperienza mi ha detto questo per il momento, sono sicura che un giorno verrò smentita in pieno...;)

Ah, spero non ti sia offeso e..... BENVENUTO!
Ci servono persone con esperienza Linux!!!

No, non mi sono offesa, tranquillo, grazie per il benvenuto, ma ero qui solo di passaggio...^__^, o almeno non pensavo di rimanere, ...sono femmina comunque...:D


thomas: ho sistemato i quote

[atomik]

non vorrei offendervi, ma ci sono alcune imprecisioni di cui volevo portarvi a conoscenza.

Quando si accede alla shell di linux di solito si entra già nella

/home/nomeutente

dedicata all'utente stesso, questo perché di solito l'utente non ha permessi speciali per accedere alla shell, per attivare un altro utente si lancia il comando

sudo

verrà chiesto nome utente e pass.

per accedere come root, solo


su

Sbagliato,

per cambiare utente si utilizza
su nomeutente
inserendo la password per l'utente "nomeutente"

se vuoi diventare root basta dare

su
inserendo la password dell'utente root

"sudo" e' un comando che consente di eseguire dei comandi con i privilegi di root, senza la necessita' di cambiare utente.
Per esempio per eseguire vim con i privilegi di root si lancia (perche' magari e' necessario modificare un file sotto /etc..):

sudo vim /etc/bashrc


Oltre questo, dire "primo incocntro con la shell testuale" e' errato, dato che non esiste una shell non testuale.
Piuttosto avrebbe dovuto essere una cosa del tipo:

"Primo incontro con la Command Line Interface"

o magari:

"Primo incontro con l'interfaccia a linea di comando"

[thomas]

No, non mi sono offesa, tranquillo, grazie per il benvenuto, ma ero qui solo di passaggio...^__^, o almeno non pensavo di rimanere, ...sono femmina comunque...:D

Perdonami immensamente allora... capisci che è raro trovare femminucce su forum informatici, soprattutto quando si parla di linux: fatta questa considerazione, non puoi per nulla al mondo lasciarci Servono le considerazioni che hai fatto nel tuo primo post, anche perché un maschietto le avrebbe fatte passare senza replicare, quindi grazie!

Detto questo voglio sottolineare che il mio intervento era per completare il tuo, non certo per andarci contro in toto; le inessattezze ci sono in ogni articolo ed è bene sottolinearle come hai fatto tu.

Ripeto, non è possibile fare articoli precisi al 100% con Linux, soprattutto perché, come ha fatto notare anche mofo, le distribuzioni tendono a personalizzare a seconda del target del loro mercato...

Una cosa però è da spiegare: Linux effettivamente tratta tutto come file, non c'è via di scampo: le fopen() e fclose() non distinguono tra file e directory, per esempio, e stiamo parlando di due pietre miliari nella programmazione C sotto linux!

Che poi le utility scrivano directory anzichè file, è un'altra cosa... serve per l'interazione con l'utente... Linux deve andare in un certo qual senso verso l'utenza di massa, non può rivolgersi solo ai programmatori od appassionati.

Poi boh...sarò rimasta l'unica, ma sono convinta che script complessi se non si hanno le basi della programmazione è difficile che si riesca a utilizzare i comandi appropriati, diciamo coscienziosamente e non per intuito, sia chiaro, ci possono essere dei bravissimi programmatori anche se non sono diplomati o laureati tali. Magari sbaglio, ma l'esperienza mi ha detto questo per il momento, sono sicura che un giorno verrò smentita in pieno...;)

Si certo, hai ragione: per scrivere script complessi servono delle basi di programmazione, ma per scrivere semplici script, basta avere giusto un po' di confidenza con bash.


A propostito di "dir"

... anche se io non ho mai detto che è un programma, è un comando che per chi viene da dos, è più semplice utilizzare, nulla di più alla fin fine fa il suo lavoro, ...

Si, insomma, non soffermiamoci sulle sottigliezze
Volevo solo specidicare che dir era un alias per ls, poi io non lo uso e la spiegazione che ho messo l'ho presa pari pari dalle manual pages tradotte in italiano da ILDS

...

fsck --help o -h

ti rimanda questa scritta:

heba@heba:~$ fsck --help
bash: fsck: command not found
heba@heba:~$

Occhio che non centra con la documentazione: li ti dice "command not found", non certo parametri errati, significa che il tuo utente non trova il comando: su debian, una delle motivazione è che il tuo utente non ha diritti da super user e quindi non può leggere "/sbin/" e "/usr/sbin/" dove effettivamente fsck risiede...

Sudo, sudoedit - execute a command as another user

Si, hai ragione... confondevo con l'utilizzo classico che se ne fa

[heba]

Oltre questo, dire "primo incocntro con la shell testuale" e' errato, dato che non esiste una shell non testuale.
Piuttosto avrebbe dovuto essere una cosa del tipo:

"Primo incontro con la Command Line Interface"

o magari:

"Primo incontro con l'interfaccia a linea di comando"

...buh...l'articolo è vostro, mi riferivo ad un vostro articolo che è uscito penso qualche giorno fa, io l'ho ricevuto tramite newsletter.

[atomik]

Non ho letto l'articolo, ma immaginavo che il titolo fosse preso dall'articolo..
La mia critica era per la scelta del titolo, non era una critica nei tuoi confronti.

Ho apprezzato il tuo intervento, credo sia molto utile fare delle critiche costruttive agli articoli, e spero potro' leggerne altre

[heba]

Perdonami immensamente allora... capisci che è raro trovare femminucce su forum informatici, soprattutto quando si parla di linux: fatta questa considerazione, non puoi per nulla al mondo lasciarci Servono le considerazioni che hai fatto nel tuo primo post, anche perché un maschietto le avrebbe fatte passare senza replicare, quindi grazie!

nessuna scusa, non c'è stata nessuna offesa...;)...ci sono abituata ad essere scambiata per un maschietto, lo faccio solo notare, per evitare altri equivoci, perché non mi sembra giusto, ecco tutto.
Poi non penso sia una questione femminile, penso sia più una questione personale, cioè sono io che sono così...:PP, grazie a voi che comunque mi avete insegnato qualcosa di nuovo....^^

Detto questo voglio sottolineare che il mio intervento era per completare il tuo, non certo per andarci contro in toto; le inessattezze ci sono in ogni articolo ed è bene sottolinearle come hai fatto tu.

Ripeto, non è possibile fare articoli precisi al 100% con Linux, soprattutto perché, come ha fatto notare anche mofo, le distribuzioni tendono a personalizzare a seconda del target del loro mercato...

non volevo dare l'impressione di essermi offesa, ho ribattutto secondo ciò che sapevo io, che magari non è corretto, ma è la mia esperienza. Ognuno ha esperienze diverse, perché ha usi diversi di Linux, un grafico sicuramente non avrà le stesse esigenze di un programmatore, ed anche le distribuzioni sono diverse con piccole differenze ma che a volte conta. Vedi che su mandrake/mandriva non funziona less o cat di default, quindi è tutto relativo alla fin fine.
Alla fin fine tutti sbagliamo e non c'è da vergognarsi, siamo umani. Quindi scusa se ti sono sembrata in contrattacco, ma proprio non era mia intenzione, volevo solo dire le cose come sono sul mio pc.

Una cosa però è da spiegare: Linux effettivamente tratta tutto come file, non c'è via di scampo: le fopen() e fclose() non distinguono tra file e directory, per esempio, e stiamo parlando di due pietre miliari nella programmazione C sotto linux!

Che poi le utility scrivano directory anzichè file, è un'altra cosa... serve per l'interazione con l'utente... Linux deve andare in un certo qual senso verso l'utenza di massa, non può rivolgersi solo ai programmatori od appassionati.

vero e falso, diciamo che apre il file che gli si specifica ma gli si deve dare un path di esecuzione, se non gli si da un file non apre nulla perché non sa dire cosa aprire, cioè apre le directory e poi rimane senza input o almeno così so io.

A propostito di "dir"
Si, insomma, non soffermiamoci sulle sottigliezze
Volevo solo specidicare che dir era un alias per ls, poi io non lo uso e la spiegazione che ho messo l'ho presa pari pari dalle manual pages tradotte in italiano da ILDS

sì, sì...tranquillo...:-D

Occhio che non centra con la documentazione: li ti dice "command not found", non certo parametri errati, significa che il tuo utente non trova il comando: su debian, una delle motivazione è che il tuo utente non ha diritti da super user e quindi non può leggere "/sbin/" e "/usr/sbin/" dove effettivamente fsck risiede...

hai ragione, è che su debian si deve scrivere


help nomecomando

sulle altre distro si mette dopo l'help...:-D

Si, hai ragione... confondevo con l'utilizzo classico che se ne fa

tranquillo nessun problema, come hai visto sbaglio anche io...;)

[heba]

Non ho letto l'articolo, ma immaginavo che il titolo fosse preso dall'articolo..
La mia critica era per la scelta del titolo, non era una critica nei tuoi confronti.

Ho apprezzato il tuo intervento, credo sia molto utile fare delle critiche costruttive agli articoli, e spero potro' leggerne altre

scusa, avevo capito male...nessun problema...^^

[mofo]

udiu... mi sono appena reso conto che nell'articolo non viene nemmeno menzionato il tasto tab... spero che sia dato per scontato...