No OS X, como você altera o “Kind” de um arquivo?

Question

No OS X, gostaria de alterar o rótulo "Kind" associado aos arquivos. Muitos dos meus arquivos são exibidos como "Arquivos de texto simples" quando eles são realmente javascript, php, css e outros tipos de arquivos.

Eu não tenho problema em fazer com que eles abram com o aplicativo que eu quero, é fácil de fazer - há muitos tópicos sobre isso.

A coisa que me incomoda é quando eu tenho uma pasta grande com muitos arquivos, eu gostaria de poder classificar por tipo e ter todos os arquivos css, todos php e todos os js juntos.

Euvi tipo de arquivo que falha no OSX, e vi quickchange mas não tenho certeza se isso é realmente o que eu preciso.

Talvez alguém já tenha lidado com isso antes e saiba como consertar isso?

    

Answer 1

O arquivo kind geralmente é definido pelo aplicativo que lida com esse tipo de arquivo no Launch Services. Para a maioria deles, este é o aplicativo que abre um tipo de arquivo por padrão, no seu caso, Coda.

Os aplicativos especificam tipos de arquivos no arquivo Contents/Info.plist . Você pode vê-lo e editá-lo clicando com o botão direito do mouse no pacote do aplicativo e selecionando Mostrar conteúdo do pacote .

Parece que o pessoal do Panic bagunçou alguma coisa. Todos os tipos de arquivo que eles definem são PlainTextType :

VocêpodealteraronomedotipodearquivoeditandotodasasDocumentTypeNameentradasnoPropertyListEditor,outodasasCFBundleTypeNameentradasaoeditaroarquivoemumeditordetextonormal.Bastasubstituiroquevocêdesejaqueapareçacomodescrição.

Edite, salve e certifique-se de que os avisos do Launch Services (reinicie, efetue logout ou simplesmente mova o aplicativo para uma pasta diferente e volte novamente), e o resultado será assim:

Você precisa repetir isso sempre que houver uma atualização no aplicativo, pois eles substituem o arquivo Info.plist que você editou. Melhor relatar um bug para os desenvolvedores do Panic.

    

Answer 2

é até o programa de salvamento para definir o UTI (identificador de tipo uniforme) para um determinado arquivo. Se você conseguir alterá-los, edite o arquivo em qualquer programa que você os tenha criado, definindo-os como texto simples, eles provavelmente serão revertidos para texto simples quando você salvar novamente.

tecnicamente esses arquivos são texto simples, eles podem ser abertos por qualquer editor que suporte a UTI de texto sem formatação, que é a finalidade das UTIs, portanto, isso não é uma imprecisão, é um exercício de semântica. Eu pessoalmente evito tais problemas colocando minhas imagens, folhas de estilo e arquivos javascript em subpastas.

de qualquer forma, você provavelmente precisará vasculhar o editor escolhido e ver se ele suporta uma maneira de definir as relações de extensão de arquivo UTI- > ou uma maneira de definir com qual UTI um arquivo é salvo.

    

Answer 3

As descrições do Core Types do OS X podem ser alteradas editando InfoPlist.strings no CoreTypes.bundle.

A lista de propriedades é um binário compilado , portanto, apenas faça um backup antes de editá-lo. As atualizações do sistema provavelmente sobrescrevem, então mantenha uma cópia ou (o que Recomendo) vincule sua versão editada à localização do orginal - supondo que sua cópia tenha o nome InfoPlist.strings.custom e esteja no mesmo diretório como original:

cd /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/English.lproj

cp InfoPlist.strings InfoPlist.strings.custom - sua cópia personalizada

mv InfoPlist.strings InfoPlist.strings.backup - movimento original

abra InfoPlist.strings.custom com TextMate pois ele analisa bem as listas de propriedades binárias, supondo que você tenha mate instalado:

mate /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/English.lproj/InfoPlist.strings.custom

depois de concluir suas edições, vincule o arquivo original:

sudo ln -s /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/English.lproj/InfoPlist.strings.custom /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/English.lproj/InfoPlist.strings

e relançar o Finder com killall Finder - você deve ver as mudanças no localizador depois disso.

por exemplo, eu mudei "Portable Document Format (PDF)" = "Portable Document Format (PDF)"; para "Portable Document Format (PDF)" = "PDF"; e ... diga adeus para longas cadeias "Kind" no Finder: -)

Antes Depois

OBSERVAÇÃO: eu uso inglês como idioma do sistema - se você tiver outro conjunto de idiomas, será necessário alterar o nome do diretório para o idioma apropriado:

cd /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/ Alemão .lproj/ < - por exemplo, digamos que alemão

Atualização 1 (descobriu sobre o plutil):

você pode usar plutil para converter de formato binário para XML ou JSON

sudo plutil -convert json InfoPlist.strings -o InfoPlist.strings.json

depois de editar o .json, converta (compile?) de volta para um formato binário:

sudo plutil -convert binary1 InfoPlist.strings.json -o InfoPlist.strings

UPDATE 2

quer descobrir onde estão as cadeias de caracteres 'Kind' irritantes?

sudo find ./ -name '*.plist' -o -name '*.strings' -exec plutil -p {} \; | grep "annoying" em que annoying é a coisa que incomoda a s ** t do dia

    

Answer 4

Dê uma olhada em duti

A command line tool to select default applications for file types, on OS X

    

Answer 5

Isso aconteceu quando atualizei para o Office 2016 e removi o Office 2011 - o Finder decidiu que .dot files (modelos do MS Word 97-2004) eram GraphViz arquivos DOT, mesmo que eu não tenha instalado o GraphViz, e decidi que o Nisus Writer deveria ser o aplicativo padrão.

Consegui consertar o aplicativo padrão da maneira mais fácil no Finder (Get Info / Open With: / Change All…), mas o tipo de arquivo ainda estava errado. Por resposta de Daniel Beck , verifiquei o Info.plists do Word 2016 e do Nisus Writer, mas ambos estavam corretos.

Acabei tendo que recriar o registro dos Serviços de inicialização com

/System/Library/Frameworks/CoreServices.framework/Versions/Current/Frameworks/LaunchServices.framework/Versions/Current/Support/lsregister -kill -r -domain local -domain system -domain user

(do Terminal) e que finalmente consertou.