터미널에서는 프록시 설정이 작동하지만 데스크톱 런처에서는 작동하지 않는 이유
프록시 구성을 데스크톱의 실제 실행 경계에 두고, 셸 시작에 대한 가정 대신 데스크톱 항목의 명령 형식을 사용하세요.
터미널에서 프록시를 내보냅니다. 거기서 시작한 명령은 그것을 사용합니다. 데스크톱 아이콘을 클릭하면 여전히 다른 경로를 갑니다. 아이콘은 그 터미널의 자식이 되지 않았습니다.
데스크톱 세션은 자체 실행 기구를 통해 애플리케이션을 시작합니다. 그 프로세스는 그 환경을 상속하며, 무관한 셸 안에서 나중에 한 모든 편집을 상속하지는 않습니다. 이는 차이를 설명할 수 있지만 애플리케이션 패키지가 결함이 있다는 것을 증명하지는 않습니다.
Exec는 명령 설명이며 셸 스크립트가 아닙니다
Desktop Entry 명세는 Exec 에 대해 실행 파일과 인자를 정의합니다. 셸 변수 확장이나 셸 내장 명령을 약속하지는 않습니다.
해당 환경 변수를 읽는 외부 프로그램이라면, 의도적으로 범위를 좁힌 실행은 이런 형태일 수 있습니다.
Exec=env https_proxy=http://proxy.example:8080 /path/to/application엔드포인트와 실행 파일을 모두 바꾸세요. 이것은 실행 입력을 보여 줄 뿐, 임의의 애플리케이션이 그 변수를 읽는다는 보장은 아닙니다. 자체적인 명시적 프록시 정책을 가진 브라우저는 여전히 다른 구성 원본을 선택할 수 있습니다. Chrome의 경우 프록시 인자를 사용자 런처에 저장하세요.
Exec=export ... 라고 쓰고 데스크톱이 그것을 로그인 셸로 해석하리라 기대하지 마세요. 데스크톱 항목의 인용 규칙과 지원되는 필드 코드도 염두에 두세요. 그것들은 또 다른 파서입니다.
새로운 것이 실행되었는지 확인하세요
일부 애플리케이션은 이미 실행 중인 인스턴스로 요청을 보냅니다. 일부 항목은 자체 실행 경로를 가진 D-Bus 활성화를 사용합니다. 새로운 아이콘 클릭이 방금 편집한 Exec 환경을 가진 새 프로세스를 세우지는 않습니다.
요청을 보내는 인스턴스와 그것이 실제로 소유한 구성을 식별하세요. 필요할 때 통제된 새 실행은 비교를 좁힐 수 있습니다. 의도한 환경이 애초에 그것에 도달했는지 확인하기 전에 애플리케이션을 다시 설치하는 것은 피하세요.