temp 폴더의.leiningen cmdline이 삭제되지 않았습니까?

묘사

임시 파일.leiningen-cmdline은 lein javac이 실행될 때 만들어졌지만 삭제되지 않은 것 같아서 파일은 다음과 같습니다.

.leiningen-cmdline167389448103795685.tmp
.leiningen-cmdline2457099859297015392.tmp
.leiningen-cmdline7571502716474781336.tmp

임시 폴더에 남습니다.(%TEMP%)
코드에서 파일은 다음과 같이 생성됩니다.https://github.com/technomancy/leiningen/blob/21c7710755762355f176bba08506b0538f008703/src/leiningen/javac.clj#L63
이후에 파일이 더 이상 필요하지 않을 수도 있습니다.https://github.com/technomancy/leiningen/blob/21c7710755762355f176bba08506b0538f008703/src/leiningen/javac.clj#L92

토론 #1

임시 운영체제 디렉터리에 있다면 괜찮습니다.운영체제는 재부팅, 디스크 공간이 부족하거나 다른 계발식 방법을 사용할 때 이 파일들을 정리해야 한다.

토론 #2

네...그런데 이 파일이 정말 필요합니까? 아니면 우리가 그것을 만들지 않아도 됩니까?
편집: @pathandfilehere 을 (유일한) 매개 변수로 javax.tools.ToolProvider/getSystemJavaCompiler 전달하는 것을 보았습니다. 그러면 빈칸이 있는 경로를 걱정할 필요가 없습니다.
EDIT2: @file를 유일한 (문자열) 그룹 요소로args로 전달하는 것이 아니라 파일의 줄마다 그룹의 문자열 요소로 전달하는 것이 같은지 알고 싶을 뿐입니다.
EDIT3: 실제로 임시 파일이 필요한 현재 동작을 설명합니다.https://github.com/technomancy/leiningen/commit/3867d4d17ce7785e83db1b1f1e8dc67f5074d251

토론 #셋

나는 deleteOnExit와 유사한 the repl task does의 물건을 받아들이고 싶다.하위 프로세스에서 deleteOnExit 만들기를 원하지만, 파일은 주 프로세스에서 만듭니다. (내가 생각한 것은 javac 번지점프대에서 실행되는 경우)그러나 나는 우리가 그 일을 보도하기만 하면 문제가 있다는 어떤 이유도 찾아볼 수 없다.

토론 #4

만약 내가 정확하게 이해한다면 이것은 가능하다는 말이야(번지점프대?)파일[1] 행 생성하기
이 파일을 사용하는 [2] 행(다른 프로세스에서)에 도달하기 전에 종료할 프로세스에 있습니까?(그래서 .deleteOnExit를 [1] 근처에 놓으면 안 돼)
그리고 [2]는 같은 파일에서 여러 번 (두 개의 다른 프로세스에서) 실행할 수 있기 때문에 .deleteOnExit를 거기에 두면 안 됩니까?
파일을 만드는 프로세스가 하위 프로세스가 끝날 때까지 기다린다면 [1] 근처에 .deleteOnExit를 두는 것이 가능할 것 같습니다.
[1] https://github.com/technomancy/leiningen/blob/21c7710755762355f176bba08506b0538f008703/src/leiningen/javac.clj#L63
[2] https://github.com/technomancy/leiningen/blob/21c7710755762355f176bba08506b0538f008703/src/leiningen/javac.clj#L93

토론 #5

첫 번째 부분은 제가 번지점프 안건에서 생각한 거예요. 맞아요.
둘째, 아니, 나는 [2]가 같은 파일에서 여러 번 실행되는 방식을 보지 못했다. 같은 프로세스에서도, 여러 프로세스에서도.그런데 어쩌면 내가 뭘 놓쳤을지도 몰라?

토론 #6

[3]에서 보면 임시 파일을 만드는 프로세스가 아직도 실행 중인 것 같고 하위 프로세스의 종료 코드를 포착할 수 있다. 임시 파일은 let에서 만들어진 것으로 줄javac-opts (vec (javac-options project files args))이 있다.이것은 나태한 것이 아니라, 하위 프로세스가 종료될 때까지 막을 것이다. 그렇지 않으면 종료 코드 검사가 있는catch는 중요하지 않을 것이다.
아마도 eval/eval-infinally(또는 유사)에 대해서는 가능할 것이다. 왜냐하면 이것은 임시 파일을 사용하는 유일한 곳인 것 같기 때문이다(적어도 지금은 이렇다).그러나 나는 이런 방식을 좋아하지 않는다. .delete 에서 finally 함수의 구현 세부 사항을 가정했기 때문이다. (이것은 파일을 만들고 '@' 접두사가 있는 파일을 되돌려주었고, 지금은 javac-options 벡터의 첫 번째 문자열로 사용되고 있기 때문이다.다른 유형의 추상화도 가능할 수 있습니다. 예를 들어 javac-opts의close는 삭제할 수 있고 javac-options는close에서 호출할 수 있습니다.마치 이 줄finally에서 우리는 무언가를 열고 닫는 일을 할 것 같다. 헤헤, 어쩌면 javac-opts (vec (javac-options project files args))의 개념이 파일에 적용될까?
따라서 최악의 경우 파일이 생성되었을 때with-open(메인 프로세스가 종료되었을 때 삭제됨), a.deleteOnExit는 정상적이거나 finally보다 낫다.
[3] https://github.com/technomancy/leiningen/blob/21c7710755762355f176bba08506b0538f008703/src/leiningen/javac.clj#L117

토론 #7

오, 쿨, 그래, 아무래도 :eval-in :subprocess:https://github.com/technomancy/leiningen/blob/21c7710755762355f176bba08506b0538f008703/src/leiningen/javac.clj#L76-L78
그래서, 네.deleteOnExit는 곧 완전히 안전해졌습니다. 번지점프대와 비번지점프 장면에서 저는 현지에서 일했습니다.

토론 #8

대박!leiningen을 컴파일할 때 이 점을 테스트할 것입니다. 100여 개의 임시 파일을 만들거나, 실행 bin\lein test 을 몇 번 기다린 후에.
감사합니다!!1
편집: 유효합니다. bin\lein test 동안 34개의 파일을 만들었고 모든 작업이 끝난 후에 삭제했습니다.