Newsgroup: it.comp.os.linux.iniziare
Titolo: PATH per documenti

Come molti sapranno, le variabili d'ambiente PATH e CDPATH ci permettono 
di lanciare eseguibili e cambiare directory senza digitare i percorsi 
completi.
 
C'è qualcosa di simile anche per i documenti?
 
Ad esempio invece di
 
$ cat ~/docs/README.md
 
impostare
 
$ DOCPATH=~/docs
 
e digitare comodamente (da qualunque directory mi trovo)
 
$ cat README.md
 
Naturalmente al posto di cat si dovrebbe poter usare qualunque comando:
 
$ gedit README.md
$ less README.md
...

 C'è qualcosa di simile anche per i documenti?
 
  Risposta breve: no.
  Risposta lunga: dipende dall'applicativo che deve aprire un certo tipo
di file.  Ad esempio, la ricerca dei file delle pagine man può essere
personalizzata con la variabile MANPATH.
Mentre la procedura di esecuzione di un eseguibile è unica ed è
un'operazione eseguita dal sistema operativo, un meccanismo di apertura
dei documenti simile a PATH non c'è perché:
 
1) il sistema opearativo non si preoccupa di sapere quali applicativi
sono giusti per aprire ciascun tipo di file, non è il suo mestiere;
2) ci sono in genere più applicativi che possono aprire un certo tipo di
file, il SO non si preoccupa di doverne sceglierne uno;
3) i tipi di file e la lista di applicativi capaci di gestire i vari
tipi di file sono informazioni piuttosto variabili; gli sviluppatori del
SO tentano di relegare il funzionamento più variabile del sistema
nell'interfaccia utente, non di integrarlo nel SO a basso livello.
 
  In generale questo tipo di operazioni è relegato all'interfaccia
utente di più alto livello, e infatti comportamenti del genere sono a
volte integrati nel desktop, nell'interfaccia grafica.  So di alcune
shell (come la zsh) che nell'interfaccia testuale estendono il concetto
di gerarchia delle directory della bash con concetti tipo: "in qualunque
cartella al di sotto di quella data", ma non sono erudito sui dettagli
di queste estensioni e comunque non associano un certo applicativo ad un
dato tipo di file.
 
 
  Ciao,
 
 
Alessandro
 

Il 01/09/20 00:06, Alessandro Selli ha scritto:

grazie delle info

 un'operazione eseguita dal sistema operativo,
 
No l'apertura  e' gestita da bash o chi per lei e NON dal SO, quindi la tua lunga spiegazione parte da basi sbagliate, il sistema 
operativo effettivamente non conosce nemmeno la variabile PATH, ma risponde solo alla syscall exec con i parametri passati da bash.
 
Al massimo la cosa piu' simile se non usi bash ma un sw da te scritto e' execlp di glibc (che sono librerie e non il SO), che cerca 
l'eseguibile nella variabile PATH e chiama exec.
 
 
Il problema e' come funziona bash , non il problema di identificare come aprire un file di dati cosa che ad esempio xdg-open fa.
 
Probabilmente il meccanismo utilizzato dallo script   command_not_found_handle  potrebbe essere utilizzato per cercare  quel nome 
file tramite variabile d'ambiente DATAPATH (dagli il nome che vuoi tu)
per ripassare  il file trovato a  xdg-open (tanto a parte file di testo vari tutto il resto lo apri tramite programmi GUI).
 
 
Giulia
 
 
 

 vari tutto il resto lo apri tramite programmi GUI).
 
  Il che non risolve nessuno dei punti elencati: ci sono più applicativi
ecc.
 
xdg-open è certo arduo considerare parte del SO, altrimenti anche Gnome
lo è.
 
 
  Ciao,
 
 
Alessandro
 

 una sua componente essenziale.
 
No, da init in poi NIENTE e' piu' componente del sistema operativo (oltre ai moduli), fai confusione tra sistema operativo e 
distribuzione, bash ash zsh busybox ecc ecc sono applicativi utente non necessari per far funzionare il SO che hanno il compito di 
fornirti una linea di comando o interpretare gli script, ma potresti avere un sistema funzionate senza nessuno di questi applicativi.
 
Giulia
 

 funzionate senza nessuno di questi applicativi.
 
  No, senza shell avresti un sistema NON funzionale.
  Fai una prova, dai.
 
 
Alessandro
 

 che senza il SO non partirebbe.
 
Quindi, ipotizzando un sistema che abbia solo il kernel e init,
secondo questa tua frase, ad esempio, io capisco che non si potrebbe,
far partire un eseguibile senza avere in esecuzione anche
una shell testuale?
 
Qui sembra possibile:
 
https://stackoverflow.com/questions/24583614/want-to-build-bare-linux-system-that-has-only-a-kernel-and-one-binary
 
 
Pero', nel kernel, sembra ci sia un riferimento a /bin/sh (non so se
e' sempre vero), anche se la sua eventuale mancanza nel sistema
non so che effetti abbia nel kernel.
 
Ciavete raggione tutti eddue, ciavete!


Se costruisci un sistema embedded la shell non è indispensabile.  Però 
devi avere un meccanismo che permetta di mandare in esecuzione i 
programmi.  La shell è sicuramente il meccanismo più pratico per interagire.
 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 interagire.
 
Grazie, si, poi in pratica e' cosi'.
il discorso in effetti  verteva piu' sul
senso dei termini che sul concreto. :-D