Por que a substituição de processo não funciona com listas de reprodução VLC?

Por que a substituição de processo não funciona com listas de reprodução VLC?

Porque vlc é mal concebido nesta matéria. Pior, ele é mal projetado duas vezes :
provavelmente tem suas razões* para funcionar de uma maneira que cria as duas desvantagens a seguir:

• inotifywait -m my_ordered_playlist.m3urevela que após vlc my_ordered_playlist.m3uo arquivo é aberto e lido várias vezes. Não investiguei se há buscas envolvidas. Quando você usa <(shuf my_ordered_playlist.m3u) vlcobtém dados canalizados shufe é capaz de lê-los exatamente uma vez. Aparentemente isso não é suficiente. Em um mundo perfeito vlcleria os dados apenas uma vez e deveria ser suficiente.

• vlcse recusa a trabalhar com uma lista de reprodução sem extensão. No Zsh existe uma =()sintaxe semelhante a <(); a diferença é que o shell cria um arquivo regular temporário em vez de um pipe. Esse arquivo pode ser lido várias vezes e é pesquisável. Parece uma boa solução para o seu problema (se você estiver bem com o Zsh), mas normalmente o nome do arquivo está sem a extensão, então vlc =(shuf my_ordered_playlist.m3u)ainda não funciona.

  Mas tem um jeito :

  # in zsh
  TMPSUFFIX=.m3u; vlc =(shuf my_ordered_playlist.m3u)
  

  Execute os comandos em um subshell se desejar que a alteração TMPSUFFIXnão afete o shell principal.

*A declaração " vlcé mal projetado" recebeu um comentário útil:

Suspeito que pelo menos uma das buscas no arquivo é determinar se o arquivo é ANSI, UTF-8 ou UTF-16 (com ou sem uma marca de ordem de byte) e, em seguida, redigitalizar o arquivo com um formato apropriado aplicado internamente. Claro que isso não impede o fato de que o VLC está esperando uma extensão, o que não é tão estúpido quando você considera o número de formatos que o VLC pode ver... Você não pode realmente esperar que ele escaneie o arquivo primeiro, e esfregue-o contra cada decodificador interno para ver qual funciona, cuja ação esvaziaria o tubo após a primeira busca e tornaria os dados inúteis novamente ...

Uma opção alternativa é fazer isso em duas etapas e passar uma lista de reprodução já embaralhada para o VLC em um arquivo em vez de na linha de comando.

shuf my_ordered_playlist.m3u > /tmp/random_playlist.m3u && vlc /tmp/random_playlist.m3u

Você pode até estendê-lo para

shuf my_ordered_playlist.m3u > /tmp/random_playlist.m3u && vlc /tmp/random_playlist.m3u && rm /tmp/random_playlist.m3u 

Para limpar após a saída do VLC.

Você pode até usar um alias bash

alias shuf_vlc="shuf my_ordered_playlist.m3u > /tmp/random_playlist.m3u && vlc /tmp/random_playlist.m3u && rm /tmp/random_playlist.m3u"

e depois é só correr shuf_vlcpara embaralhar sua playlist.

A razão pela qual seu comando não funciona é porque ainda é um pipe e está sujeito às limitações de um pipe.

Limitações da Substituição do Processo

A substituição do processo tem algumas limitações:

• Sem busca de arquivo: os "arquivos" criados não são pesquisáveis, o que significa que o processo de leitura ou gravação no arquivo não pode realizar acesso aleatório; ele deve ler ou escrever uma vez do início ao fim. Programas que verificam explicitamente o tipo de arquivo antes de abri-lo podem se recusar a trabalhar com substituição de processo, pois o "arquivo" resultante da substituição de processo não é um arquivo comum.

• Sem códigos de saída : "Não é possível obter o código de saída de um comando de substituição de processo do shell que criou a substituição de processo."

Dependendo do comportamento que você está vendo, pode ser que o VLC esteja procurando por uma lista de reprodução válida (para verificar UTF-8/16 etc ou que o arquivo foi construído corretamente), mas não está realmente lendo a lista de reprodução no primeiro passar. Ele tenta voltar para realmente carregar os arquivos e, devido a "nenhuma busca de arquivo", não consegue ler a lista de reprodução. A primeira passagem esvazia efetivamente o pipe que recebe um descritor de arquivo e, em seguida, não há nada com que trabalhar.

Alternativamente, o VLC verifica se o arquivo é "real" e capaz de ser seekeditado e ao descobrir que não pode simplesmente se recusar a abri-lo, pois não poderá analisar tanto para frente quanto para trás no arquivo.

Seus dois primeiros comandos são simples e não esperam nada mais do que um fluxo legível, o VLC quer algo real que possa segurar.