Este programa do Windows em execução no Wine não reconhece o caminho absoluto para o seu argumento?

Question

Estou usando o PDFXCview.exe no Ubuntu 16.04 em wine-3.1.

Quando eu especificar um arquivo pdf como um argumento para PDFXCview.exe , o caminho absoluto para o arquivo pdf não faz com que PDFXCview.exe encontre o arquivo pdf, enquanto o caminho relativo para o arquivo pdf faz.

Por exemplo:

wine /path/to/PDFXCView.exe my.pdf

abrirá my.pdf em PDFXCView.exe , enquanto

wine /path/to/PDFXCView.exe "$PWD"/my.pdf

não.

1. O argumento de caminho absoluto é usado apenas por PDFXCView.exe , não por wine , convertendo assim o caminho absoluto para um caminho reconhecível pelo vinho não ajuda. Por exemplo, wine /path/to/PDFXCview.exe "$(winepath /tmp/test/O.pdf)" não faz PDFXCview.exe encontrar e abre o arquivo pdf, onde o caminho reconhecível pelo vinho é:

   $ echo wine /path/to/PDFXCview.exe "$(winepath /tmp/test/O.pdf)"
   wine /tmp/test/PDFXCview.exe /home/t/.wine/dosdevices/z:/tmp/test/O.pdf
   

2. Pelo contrário, quando eu especifico um arquivo de texto como um argumento para notepad.exe , eu posso especificar o caminho absoluto ou um caminho relativo para o arquivo de texto, e notepad.exe pode encontrar o arquivo de texto para abrir. Por exemplo, ambos wine notepad "$PWD"/note e wine notepad note pode fazer o bloco de notas encontrar e abrir o arquivo de texto note .

O acima também é o caso de outras pessoas?

Qual é a razão pela qual PDFXCview.exe não reconhece o caminho absoluto para seu argumento, mas apenas um caminho relativo?

Eu queria saber se o problema acima com PDFXCview.exe é por causa do próprio programa ou do vinho? Eu não tenho o Windows para testar, e também me pergunto se PDFXCview.exe se comporta no Windows da mesma forma que no Wine.

Obrigado.

Captura de tela da tag do Drive de winecfg

    

Answer 1

Você está fornecendo um caminho absoluto estilo Linux para um executável do Windows que está sendo executado pelo Wine, não dando esse argumento de caminho para o próprio Wine. Portanto, você deve tratar cada argumento após o caminho para o argumento .exe como um estilo do Windows (por exemplo, wine /home/$USER/.wine/drive_c/path/to/Windows/executable.exe [Windows Style Arguments] ).

Os caminhos de estilo Linux completos funcionam para notepad.exe , mas considere que notepad.exe provavelmente não é a versão do Windows do Notepad, está incluído na configuração do Wine e provavelmente está ajustado para aceitar Caminhos do Linux (como /tmp/test/O.pdf ).

A maioria dos aplicativos que wine podem executar, no entanto, não possuem esses ajustes e, portanto, aceitam apenas caminhos no estilo do Windows. Então, você precisa dar a esses aplicativos um caminho no estilo do Windows, no formato como C:\Windows\System32\... , mas com relação à localização real dos arquivos e com relação aos mapeamentos de unidade no Wine, levando em consideração o console do Bash / Linux interpretações de estilo * de caminhos.

Primeiro, encontre os mapeamentos de unidade e onde eles 'existem' na infra-estrutura de arquivos do Linux. Para fazer isso, carregue acima de winecfg e, na janela de configuração do Wine, vá para " Drives "tab. Será algo parecido com isto:

Como você pode ver, eu tenho C: , que está mapeado para o diretório Wine drive_c , que nesta instância está em /home/teward/.wine . Eu também tenho uma unidade M: mapeada para meu diretório /mnt/ , o que é relevante porque tenho coisas referenciadas por M:\ nos aplicativos do Wine.

O que é mais relevante é o Z: mapping, que mapeia para a partição root / no meu ambiente Linux. Este geralmente é um mapeamento padrão, mas não necessariamente estará em seu ambiente (portanto, certifique-se de que esteja). Qualquer que seja a unidade Wine mapeada para / , você precisará usar. E se não existir, você precisará adicionar um mapeamento de unidade que corresponda a / ou ao diretório real em que seus dados estão, na verdade, que você está abrindo com o aplicativo do Windows. Tecnicamente, você poderia ter T: mapeado para /tmp/ e, em seguida, T:Z:.pdf , mas não estou assumindo isso como resposta.

Assim, para os propósitos desta resposta, assumirei que / está realmente mapeado para Z:\ e use isso a partir deste ponto em minha resposta.

Você precisa seguir o caminho do Linux e convertê-lo para o estilo Windows a partir da raiz da unidade /tmp/test/0.pdf . Então, para 'Z:\tmp\test'.pdf' no Linux, você vai realmente dar /foo/bar/baz (incluindo as citações únicas de : para que o shell não atrapalhe a interpretação * do caminho). Dessa forma, o aplicativo no estilo do Windows está obtendo um caminho que pode ler e entender, não um caminho que não é possível.

Muito poucas aplicações do Wine são realmente capazes de entender os caminhos do estilo \ do Linux, e a maioria dos que foram modificados e instalados como parte da configuração do Wine para começar. Portanto, é melhor fornecer caminhos no estilo do Windows para aplicativos do Windows em execução no Wine, em vez de caminhos de estilo do Linux.

* Quando me refiro a 'interpretação', não me refiro ao \ , mas ao C:\Program Files\Foo\bar.exe que está nos caminhos. E embora o seu caminho não contenha espaços, também me refiro a espaços. Na sintaxe Bash, o C:\Program\ Files\Foo\bar.exe é usado como parte de um caractere de escape. Além disso, na linha de comando, os argumentos são delimitados por espaços, portanto, ele não sabe como processar espaços nos caminhos e, como tal, você teria que escapar deles com barras invertidas. Então, para o que seria ' , você precisaria colocar 'C:\Program Files\Foo\bar.exe' no caminho. No entanto, com o shell Bash padrão, você pode negar essa má interpretação de barras e espaços envolvendo o caminho com aspas simples ( %code% ), que o trata como um argumento literal sendo passado, em sua totalidade, para que você possa fazer %code% sem ter que lidar com barras invertidas ou espaços vazios.