Perché i builtin di Shell non possono essere eseguiti con lettere maiuscole ma altri comandi possono farlo?

Perchè è questo?

Quando lo faccio

CD ~/Desktop

Non mi porta sul desktop. Ma questo:

echo "foo
bar" | GREP bar

mi da:

bar

— Nome da visualizzare
fonte

Controlla se alias GREPo which GREPemetti qualcosa.

— Chepner,

Ecco qua Hai un comando chiamato GREP, che è distinto da grep. (È vero, potrebbe essere solo un collegamento reale o un collegamento simbolico a /usr/bin/grep, ma dal punto di vista della shell, è un comando separato.)

— chepner

Aspetta: sei su Mac OS X, vero? HFS + mantiene automaticamente le maiuscole, il che significa che se il caso è importante quando si crea un file, ma una volta che il file esiste, le ricerche non fanno distinzione tra maiuscole e minuscole. Cioè, bashpotrebbe richiedere un file denominato GREP, ma il file system considera grepuna corrispondenza.

— Chepner,

Sì, perché è Unix.

— DisplayName

I file system sono indipendenti dal sistema operativo. Puoi usare altri file system con Mac OS X e (in teoria) puoi usare HFS + con altri sistemi operativi. Inoltre, puoi fare distinzione tra maiuscole e minuscole HFS +; il comportamento di conservazione del caso è solo il valore predefinito per motivi storici.

— Chepner,

Dalle altre tue domande, suppongo che tu stia utilizzando OS X. Il filesystem HFS + predefinito su OS X non fa distinzione tra maiuscole e minuscole: non puoi avere due file chiamati "abc" e "ABC" nella stessa directory e provare ad accedere entrambi i nomi arriveranno allo stesso file. La stessa cosa può succedere sotto Cygwin o con filesystem senza distinzione tra maiuscole e minuscole (come FAT32 o ciopfs ) ovunque.

Perché grepè un vero eseguibile, è stato cercato nel filesystem (nelle directory di PATH). Quando la tua shell cerca /usr/binuno grepo GREPtroverà l' grepeseguibile.

I builtin della shell non vengono cercati sul filesystem: poiché sono integrati, sono accessibili tramite confronti di stringhe (sensibili al maiuscolo / minuscolo) all'interno della shell stessa.

Quello che stai incontrando è un caso interessante. While cdis builtin, accessibile in modo sensibile al maiuscolo / minuscolo, CDsi trova come eseguibile /usr/bin/cd. L' cdeseguibile è piuttosto inutile: poiché cdinfluisce sull'ambiente di esecuzione della shell corrente, viene sempre fornito come un normale shell incorporato , ma esiste comunque un cdeseguibile per il bene di POSIX , che cambia directory per se stesso e quindi termina immediatamente, lasciando la shell circostante da dove è iniziato.

Puoi provarli con il typebuiltin :

$ type cd
cd is a shell builtin
$ type CD
CD is /usr/bin/CD

typeti dice cosa farà la shell quando eseguirai quel comando. Quando esegui cd, accedi all'integrato, ma CDtrova l'eseguibile. Per altri builtin, il builtin e l'eseguibile saranno ragionevolmente compatibili (provare echo), ma per cdquello non è possibile.

— Michael Homer
fonte

buona risposta. Stavo per dire Cygwin, che avrebbe avuto lo stesso effetto.

— Giosuè,

@Joshua Il problema del PO è risolto, ma penso che per ulteriori lettori della domanda, una risposta basata su Cygwin sarebbe utile almeno quanto quella esistente; Forse puoi rendere questa una risposta separata, anche se breve, e rinviare a quella esistente per i dettagli?

— Volker Siegel,

Perché posix richiederebbe un comando inutile come cd, e perché il cd interno di osx non si qualifica?

— Giovanni,

51 voti! Avrei dovuto solo postare una risposta, invece di un commento :)

— chepner,

/ usr / bin / cd ha uno scopo. la sintassi è / usr / bin / cd argomenti del programma di directory

— Joshua