2015-08-24 23 views
38

I dotfiles, ad esempio .htaccess.gitignore e .config, hanno un'estensione di file e nessun nome di file o sono considerati come aventi un nome file e nessuna estensione?I dotfile hanno un'estensione di file?


Sto cercando di implementare alcune funzioni di utilità in PHP, che è noto per fare le cose male e ho notato che la funzione di PHP pathinfo considera dotfile di avere un'estensione del file e non il nome del file, mentre il nodo di path.extname considera dotfile a avere un nome file e nessuna estensione.

Non sono chiaro se uno standard esiste o se questo equivale alle preferenze dello sviluppatore.

+0

Molto interessante. Bene, dato che entrambi trattano i dotfile in modo diverso, sembra ragionevole supporre che entrambi stiano operando su standard diversi (indipendentemente dal fatto che uno standard "vero" esista o meno in questo caso). Pensieri? –

+0

Interessante davvero. [Boost.Filesystem] (http://www.boost.org/doc/reference/html#path-extension), ad esempio, considererebbe un'estensione di file senza nome del file. "estensione del percorso (const path & p) const;' ... se p.filename() contiene un punto ma non consiste solo di uno o due punti, restituisce la sottostringa di p.filename() partendo dal punto più a destra e termina alla fine del percorso, altrimenti restituisce un oggetto percorso vuoto. " – Anthony

+5

@JoshBeam, PHP ha la tendenza a marciare al ritmo di un altro batterista, e quindi cadere fuori passo e fare un paio di giri sbagliati anche da quel batterista diverso. Basta vedere come gestisce le stringhe di query o una qualsiasi delle sue librerie standard. Detto questo, ho sempre considerato i dotfile come file di sola estensione senza nome file, quindi sono rimasto sorpreso dal fatto che il nodo li considerasse non avere un'estensione. – zzzzBov

risposta

19

Paghi i tuoi soldi e tu fai la tua scelta: Sì, No, forse.

Arriva alla definizione di "estensione".

  • È "qualcosa dopo l'ultimo punto nel nome"? Se è così, quei file non hanno nome e sono tutti estensioni.
  • È "qualcosa dopo un punto che non è il primo carattere nel nome"? Se è così, quei file non hanno un'estensione.
  • Se si utilizza qualche altra definizione, la risposta dovrà essere regolata di conseguenza.

Ricordate che i file SCCS utilizzato un prefisso s. (tra gli altri, che ci si vede p. file anche - e ci sono stati molti i nomi di file temporanei con altri prefissi). Un file SCCS s.something ha un'estensione o un prefisso? (Con s.source.c, è ragionevolmente semplice: c'è un prefisso, un nome e un'estensione o un suffisso, oppure puoi ignorare il prefisso come caso speciale e il nome è s.source e l'estensione è .c.) Che dire dell'eseguibile predefinito nome, a.out? Che dire di un nome come ..dot; ha un'estensione e, in caso affermativo, di cosa si tratta?

Si noti che la risposta su DOS era più formalizzata. Lì il file system utilizzato per far rispettare (una volta su un altro millennio o giù di lì) i nomi con 8.3 e l'estensione era tangibile. Ma questa è un'epoca passata per la maggior parte (e ci sono pochi che lo mancano).

Anthony Arnold e paxdiablo entrambi hanno notato che i nomi che terminano con .tar.gz esistono - qual è l'estensione su tali file?

Se si considera l'estensione di somecode-8.76.tar.gz come un valore diverso da .gz, ci si sta aprendo a un sacco. Il file contenuto è somecode-8.76.tar; che si può ragionevolmente dire di avere un'estensione di .tar. La definizione dell'estensione dell'intero file tar gzip come .tar.gz solleva la domanda "perché non è .76.tar.gz" e significa anche che è necessario rivisitare la convenzione di denominazione dei file SCCS. Assorbimento della porzione .76 del nome in .76.tar.gz o .76.tar poiché un suffisso sta rendendo davvero complessa la vita. È una domanda valida, ma qualsiasi cosa diversa da "un'estensione è la stringa dall'ultimo punto alla fine del nome" è davvero irreale - o richiede un'interpretazione del significato dell'estensione, ed entra in un'altra area complessa che generalmente è meglio evitare

Si noti che Unix a livello di sistema operativo o di file system non si preoccupa dell'estensione sui file.I programmi possono decidere che si preoccupano delle estensioni, ma questo dipende dal programma. L'estensione è un indicatore del tipo di file; non è definitivo. Ecco perché esiste il programma file per identificare il contenuto dei file. Guarda il contenuto del file per identificare il contenuto; non presta attenzione all'estensione del file (quindi non deve decidere quale sia l'estensione).

+1

Sì, lo stesso UNIX non ha concetto di estensioni, è qualcosa di stratificato dall'alto come i lanciatori di programmi. Potresti anche chiedere se l'estensione del file per 'x.tar.gz' è' tar.gz' o solo 'gz' :-) Per dotfiles. caratteri '2-x' non hanno nulla a che fare con il tipo di file, quindi non li chiamerei un'estensione me stesso. – paxdiablo

+1

@paxdiablo: Sono d'accordo che '.htaccess' (per esempio, o' .profile' o '.bashrc') è tutto nome e nessuna estensione, ma dipende dalla definizione di estensione, e qualsiasi definizione è potenzialmente in qualche modo contenzioso . –

+1

@JonathanLeffler Vero, ma affidarsi alle estensioni per qualsiasi cosa diversa dalla convenienza è anche irto di pericoli. In questo momento, sembra che accettiamo universalmente '.' come delimitatore di estensione e generalmente ci basiamo sulle estensioni come semplice indicatore del formato o dell'utilizzo del file. Tuttavia, non è scolpito nella pietra e nemmeno uno standard formale. – Anthony

7

Il motivo per cui qualcuno vorrebbe conoscere l'estensione di un file è che vuole conoscere il tipo (o alcuni altri metadati) del file, giusto?

Il nome di un dotfile non ha nulla a che fare con il suo tipo. La parte dopo il primo punto del dotfile è il suo nome e nessuna estensione. Ma un dotfile potrebbe anche avere un'estensione (ad esempio .mongorc.js o qualche altro file nascosto su un sistema UNIX).

Quindi direi che il modo in cui il nodo è path.extname è il modo a destra.

Restituisce l'estensione del percorso, dall'ultima '.' alla fine della stringa nell'ultima porzione del percorso. Se non c'è "." nell'ultima porzione del percorso o il suo primo carattere è ".", quindi restituisce una stringa vuota.


Ci sono due cose diverse qui:

  • C'è una parte del meccanismo di determinazione alcuni metadati da un'estensione nome file, ad esempio per aprire con un "default" applicazione in non unix-like sistemi.

  • dotfile d'altra parte sono solo i file nascosti (con un nome normale e un punto di fronte, per renderli non visibile a ls) provenienti da Unix-like sistemi. Quindi .gitignore è solo un file denominato gitignore e contrassegnato come nascosto - non esiste l'estensione qui .

+1

Suonerò l'avvocato del diavolo su questo. Le estensioni di file vengono in genere utilizzate come suggerimento su come il file deve essere gestito dal sistema operativo per la loro azione predefinita. Questa è solo comodità in modo che quando fai doppio clic su un file '.txt' si apre nel tuo editor di testo preferito. Se '.gitignore' fosse trattato dal sistema operativo come privo di estensione di file, non ci sarebbe un modo consistente per dire al sistema operativo di aprire il file nell'editor' .gitignore' personalizzato preferito. Il sistema operativo dovrebbe quindi trattarlo come un file senza estensione proprio come un file chiamato 'file' e chiedere come si desidera gestirlo. – zzzzBov

+0

@zzzzBov Sarebbe bello assegnare i gestori di file predefiniti in base alle espressioni regolari. In questo modo, sei libero di usare qualsiasi schema di denominazione che ti piace invece di essere legato al modello di "estensione". – Anthony

+0

@zzzzBov Ho cercato di spiegare la mia opinione un po 'di più in una modifica della mia risposta. Le directory –

3

Mi sento di dover lasciare una risposta per risolvere il problema reale dell'utente.

Per quale motivo è effettivamente necessaria l'estensione, in questo caso? File come .gitignore, .htaccess ecc. Corrispondono al nome completo del file. Non l '"estensione" (o la mancanza di) ma il nome completo.

Vorrei discutere il caso di eliminare qualsiasi controllo delle estensioni di file e verificare il nome del file. Per esempio, in PHP:

basename ("/path/to/.htaccess"); 
3

direi che sono solo nascosti ... In Unix/Linux, una directory/file è considerato nascosti se è il primo carattere è "" (punto), quindi è solo il primo carattere - non un'estensione/suffisso.

Inoltre, è possibile nascondere anche le directory, incluso "." e ".."(corrente e padre) le directory - e l'estensione/suffisso di solito non è qualcosa che associamo alle directory.In realtà, molti programmi creano tali directory nascoste per se stessi (ad esempio .foo) piuttosto che un solo file (ad esempio .foorc

Infine, Unix/Linux non ha mai riguardato i suffissi in ogni caso - la maggior parte dei programmi è in grado di leggere i "loro" file senza inoltrarsi su uno, mentre Unix usa spesso i test dal file "magico" (/ etc ../magic) e il comando file al determent il tipo di file (la notevole eccezione essendo compressione-programmi come gzip e bzip2, che sostituisce originale con una versione compressa suffisso)

vorrei aggiungere che il "rc" - terminando (per "run-command") - in ad esempio .bashrc, .wgetrc, .zshrc e così via, potrebbe essere pensato come suffisso/estensione per questi tipi di file - evento anche se non c'è alcun punto tra il nome e il suffisso (alcuni - come .rtorrent.rc - in realtà hanno un punto).

+0

possono anche essere nascoste, incluso "." e ".." '. - Ah, '..' è solo la versione nascosta di' .', vedo ... –

+0

Thomas Weller: Non posso dire se stavi scherzando o no; ma nel caso in cui: '..' è il genitore della directory corrente; '.' è la directory corrente. – echristopherson

+0

Non proprio ... ;-) Sono * entrambi * nascosti. La directory corrente è chiamata "." e la directory genitore è chiamata "..". Ma dal momento che i file/directory nascosti inizia con un punto in Unix - che entrambi "." e ".." fa - sono entrambi entrambi ** nascosti ** ... I.e. non si visualizzano se fai un semplice 'ls' ... devi usare' ls -a' per vederli - insieme ad altri file/directory nascosti. –