.bashrc다시 매핑하기 위해 다음을 추가했습니다 less.vim
alias vsi='vim -R -c ":map Q :q!<enter>" -' # Vim Standard Input [readonly]
alias less='vsi'
그 이유는 키 바인딩 기본 설정으로 두 개의 구성 파일을 유지하고 싶지 않고 vim이 더 유용하고 예측 가능하다고 생각하기 때문입니다. (종종 내가 찾고 있는 텍스트가 강조 표시되지 않거나 보기에 없기 때문에 찾을 수 없습니다.)
그것~인 것 같다"대형" 파일을 열 수 없기 때문에 개발 도중과 그 이후에 개발되었는데 less, 당시 "대형"으로 간주되어 처리할 수 없었던 것은 무엇입니까? 오늘은 그게 문제가 아니지 않나요?vimorevimore
이 별칭이 종속 스크립트나 프로그램을 손상시키나요 less?
답변1
불완전한 입력을 보는 것이 문제입니다.
seq 10000 | pv -qL 10 | less
답변2
less쉘 별칭은 스크립트나 다른 명령에 대해 확장되지 않으므로 종속 스크립트나 명령은 중단되지 않습니다 .
쉘 별칭은 대화형 쉘 세션을 촉진하기 위해서만 존재합니다. 별칭은 하위 프로세스가 상속한 환경의 일부가 아니기 때문에 해당 셸 세션에서 시작된 셸 스크립트 및 명령으로 전달되지 않습니다.
유일한 문제는 이 별명이 있다는 사실을 잊고 대화형 쉘 세션에서 추가 옵션과 함께 이를 계속 사용하는 경우입니다. 그런 다음 이러한 옵션을 에 제공합니다 vim.
view대신 사용하는 것을 고려할 수도 있습니다 vim -R.
"대형 파일"과 관련하여 이는 RAM보다 크기가 크거나 최소한 사용 가능한 RAM의 상당 부분 크기인 파일입니다. 전통적으로 편집자는 파일을 열 때 전체 파일을 메모리에 로드했으며 일부 편집자는 여전히 이 작업을 수행합니다. 따라서 대용량 파일을 열면
- 느리게
- 편집기에서 리소스 제약(메모리 부족)이 발생할 수 있습니다.
.swp나는 Vim 편집기가 이 문제를 해결하기 위해 "스왑 파일"(파일 이름 접미사가 붙은 파일을 본 적이 있을 수도 있음)을 사용하고 있다고 생각합니다 . :help swap-fileVim에 무엇이 있는지 살펴보세요 .
less기본적으로 호출기는 그대로 유지됩니다.모두파이프에서 읽을 때 메모리에서 데이터를 읽습니다. 사용 가능한 RAM보다 더 많은 데이터를 읽으면 문제가 발생합니다. 다행히 읽은 데이터의 마지막 부분만 강제로 메모리에 보관하도록 하는 -B(또는 --auto-buffers) 옵션이 있습니다 . less그러나 이로 인해 이전에 본 입력 라인으로 다시 점프하는 것이 불가능해졌습니다.
호출기 more는 때때로 less위장됩니다(바이너리에 대한 하드 링크일 뿐입니다 less). 시스템의 more위치실제 more, 호출기는 파이프에서 읽은 데이터를 볼 때 뒤로 스크롤하는 것을 허용하지 않습니다.
내용을 보기 위해 파일을 완전히 읽을 less필요 는 없습니다 . more둘 다 파일에서 적절한 위치를 찾습니다.
답변3
예를 들어, 스위치와 함께 less 명령을 실행하는 경우 예기치 않은 동작이 발생할 수 있습니다. 나는 다음과 같이 더 적은 줄 번호로 실행하기 위해 "-N" 스위치를 사용하는 것을 좋아합니다 less -N filename. vim에 더 적은 별칭을 설정하면 예상되는 줄 번호를 얻지 못합니다(vim의 경우 "-N" 스위치는 "비호환 모드"는 vim을 "더 나은 성능을 제공하지만 Vi와 덜 호환되게" 만듭니다(man 페이지). 귀하의 사용 사례가 less와 vim의 다양한 동작을 결코 강조하지 않을 것이라고 확신할 수 있습니까?