Supondo que o arquivo que você abriu não foi excluído, o seguinte fechará todos os aplicativos que o abrem:
fuser -k -TERM FILE
Substitua FILE pelo nome do arquivo em questão.
Note que isso é potencialmente muito perigoso se você não for cuidadoso. Se você acidentalmente passar seu diretório pessoal por exemplo, ele encerrará todas as sessões de login atuais que você tem no sistema (gráficas e textuais), além de matar a maioria de seus processos em segundo plano.
Supondo que você saiba qual aplicativo abriu o arquivo, há outros métodos específicos de ambiente de área de trabalho mais seguros para fazer isso, mas não sei o suficiente sobre eles para dar um bom conselho aqui.
Agora, por que motivo não existe o comando xdg-close :
xdg-open existe para que ferramentas como gerenciadores de arquivos ou navegadores da web possam garantir que o aplicativo preferido do usuário seja chamado quando tentarem abrir um determinado arquivo. Em outras palavras, originou-se para que você não precise percorrer todos os aplicativos em seu sistema quando quiser alterar o que é usado para abrir um arquivo, mas, em vez disso, pode definir padrões em um único local, e os aplicativos não têm para se preocupar com o ambiente de área de trabalho que você está usando quando deseja abrir algo em outro aplicativo. Pode ser chamado a partir da linha de comando manualmente, mas não é para isso que ele foi projetado.
Automatizar fechamento aplicativos que abriram um arquivo específico não é exatamente algo que seja amigável ao usuário. Seu navegador da web não tem nenhum negócio fechando o visualizador de PDF que você abriu para ver o PDF que você baixou, então por que ele precisa de uma ferramenta que permita isso? Além disso, o ambiente de área de trabalho não rastreia quais aplicativos têm quais arquivos abertos (o SO rastreia como os processos (que não mapeiam 1: 1 para aplicativos) têm arquivos abertos), portanto, não há uma maneira fácil de implementar isso também.
Por que vale a pena, a única razão pela qual xdg-open existe como um comando é porque ele se originou antes do DBus se tornar parte da especificação FreeDesktop.org, caso contrário seria quase certamente uma chamada DBUS API fornecida por outro desnecessário. processo de fundo.