./test가 아닌 .test로 실행

실행 파일과 같은 폴더에 있다고 가정하면 이것을 입력하여 실행해야합니다.

./file

입력 /하기 /가 어렵 기 때문에 입력 할 필요가 없습니다 .

파일을 더 쉽게 실행할 수있는 방법이 있습니까? 이상적으로는 다음과 같은 간단한 구문이 이상적입니다.

.file

또는 다른 것이 있지만 /거기 에 문자 를 삽입하는 것보다 쉽습니다 .

아마도 /bin디렉토리 에 무언가를 넣거나 인터프리터의 별칭을 만들어서 사용할 수있는 방법이있을 수 있습니다.

p file

"위험"일 수 있지만 그냥 가질 수 있습니다. 당신의 경로에.

다른 사람들이 말했듯이 이것은 위험 할 수 있으므로 항상 확인하십시오. 시작이 아닌 PATH 끝에 있습니다.

../적어도 현대 Bash 쉘에서는 자동 완성 (을 입력 .하고 누름 Tab)하므로 복잡하거나 안전하지 않은 ( PATH수정 과 같은 ) 솔루션 을 사용할 필요가 없습니다 .

자동 완성되지 않으면 "bash-completion"패키지를 설치해야합니다.

또는 .. 아마도 해석기에 bashrc 파일에 별명을 부여한 다음 간단히

   p  file

그러한 함수를 작성할 수 있습니다 :

p() {
 ./"$@"
}

당신의 ~/.bashrc. 그런 다음 p app arguments대신 실행할 수 있습니다 ./app arguments. 이 솔루션은 스크립트 및 바이너리를 포함한 모든 유형의 실행 파일에 적용됩니다.

"$@"함수에 전달 된 적절하게 인용 된 인수 목록으로 확장하고 (글로브 또는 변수 확장에서 모든 특수 문자를 유지) @Scott이 지적했듯이 @Scott이 지적했듯이 나머지를 보존하기 위해 첫 번째 문자 bash앞에 붙일만큼 영리 ./합니다.

당신은 넣을 수있는 .당신에게 $PATH예를 추가하여 PATH=$PATH:.당신에게 /etc/profile, 당신이 실행할 수있는이 방법 file만 쓰기로를 file이 경로 (예에서 다른 폴더에있는 경우를 제외하고 /usr/bin/). 이것은 일반적으로 좋은 생각이 아닙니다.

나쁜 이유 : 디렉토리의 내용을 완전히 신뢰하지 않는 상황에 있다고 가정하십시오. 디렉토리에서 파일을 다운로드하여 실행하기 전에 조사하고 싶거나 시스템 관리자가 일부를 돕는 경우 사용자는 자신의 홈 디렉토리를 살펴 보는 등의 방법으로 디렉토리를 나열하려고합니다. 따라서 ls를 입력하려고 시도하지만 죄송합니다. 오타를 작성하면 대신 sl을 입력하게됩니다. 이 악의적 인 디렉토리의 저자는 이것을 예상하고 'rm -rf --no-preserve-root /'(또는 루트킷 설치와 같은 악의적 인)를 실행하는 "sl"이라는 쉘 스크립트를 넣었습니다.

(설명 해주신 @Muzer에게 감사드립니다)

예를 들어 통역사에게 전화 할 수 있습니다.

bash test

이 경우 스크립트에 shebang 줄 (예 :) #!/bin/bash이나 실행 가능한 비트 가없는 경우에도 스크립트가 실행됩니다 . 올바른 인터프리터도 실행해야합니다. 예를 들어 shebang 행이 다음과 같은 경우 파일의 shebang 행을 먼저 읽고 올바른 인터프리터를 호출 할 수 있습니다.

#!/usr/bin/env python3

당신은 전화 할 것이다

python3 test

내가 아는 한, env 경로에 파일을 포함시키지 않으면 파일을 얻을 수있는 방법이 없으므로 다음을 입력하여 실행할 수 있습니다. file

.file다른 파일 이름이므로 작동하지 않습니다. 이 .file아니라 라는 파일 ./file입니다.

영어 이외의 레이아웃으로 인해 슬래시를 입력하기 어려울 수 있습니다. 이 경우 나에게도 발생하므로 Windows에서 Alt + Shift를 눌러 키보드 레이아웃을 영어로 자주 교체합니다 (ssh에서 Linux를 사용합니다)

사람들은에 추가 .를 제안 PATH했습니다.이 경우 위험 할 수 있습니다.이 파일은 실수로 세계 기록 가능한 디렉토리에 설치된 악성 프로그램을 실행할 위험이 있습니다. 당신은 당신이 소유 몇 디렉토리에 실행 프로그램을 가지고 만 쓰기 권한이있는 경우 그러나, 그것은 안전 (매우 안전?)입니다 넣어 그 이사 (들)을 에 PATH같은 줄을 추가하여,

PATH=$PATH:~/dev/myprog1:~/dev/myprog2

당신에 ~/.bashrc파일. 물론 이것은 파일 시스템의 어느 곳에서나 해당 디렉토리 중 하나에서 프로그램을 실행할 수 있음을 의미합니다. 예를 들어,을 cd /etc입력 foo하고 실행할 수 있습니다 ~/dev/myprog1/foo. 이것은 하나 이상의 디렉토리에 같은 이름의 프로그램을 가질 수 없다는 사소한 단점이 있습니다. 특히 및 foo 에서 호출 된 프로그램이있는 경우 경로를 지정하지 않으면 두 번째 프로그램을 실행할 수 없습니다. 마찬가지로 당신이 -하지만 왜 당신이 원하십니까?~/dev/myprog1~/dev/myprog2~/dev/myprog1/cat

이 작업을 수행하는 프로그램이 몇 개인 경우 다른 접근 방식은 해당 프로그램의 별명을 정의하는 것입니다.

alias gizmo='./gizmo'
alias gonzo='./gonzo'

아니면 별칭을 호출 할 수 있습니다 .gizmo그리고 .gonzo 당신이 경우 그보다 직관적를 찾을 수 있습니다.

실제로 이것은 어느 정도까지는 보안 위험 .이 있습니다 PATH. 악의적 인 사용자가 사용자를 읽고 .bashrc별명을 볼 수 있다면, 사용자가 원하는 대로 멀웨어 gizmo및 gonzo임의의 디렉토리에 맬웨어를 넣을 수 있습니다 . 이 경로를 절대 경로 이름으로 사용하는 것이 좋습니다.

alias gizmo='~/dev/myprog1/gizmo'
alias gonzo='~/dev/myprog2/gonzo'

그건 그렇고, 실행 파일 test은 셸 내장 명령이기 때문에 실행 파일 이름을 피해야 하며 경로 또는 다른 트릭을 지정해야만 해당 이름으로 프로그램을 실행할 수 있습니다.

인터프리터에 대한 Zanna의 답변을 확장하려면 (죄송합니다, 코멘트에 대한 답장이 없습니다) : 네이티브 실행 파일 (일명 이진 ELF 파일)의 "인터프리터"는 동적 로더 ( ld.so)이지만 일반적으로 원하는 구문을 이해하지 못합니다.

$ /usr/lib/ld-linux-x86-64.so.2 program
program: error while loading shared libraries: program: cannot open shared object file
$ /usr/lib/ld-linux-x86-64.so.2 ./program
<program is launched>

(또한 ld.so경로에 심볼릭 링크 가 없으면 /s 를 작성해야합니다 )

구성을 시작할 수 있다면

mkdir -p ~/.local/bin
cat > ~/.local/bin/x << 'EOF'
#!/bin/sh
N="$1"
shift
exec "./$N" "$@"
EOF
chmod a+x ~/.local/bin/x

대부분의 최신 배포판은 이미 (추가 $ PATH에 ~ / .local의 / bin이 포함 export PATH="$HOME/.local/bin:$PATH"에 ~/.profile당신이하지 않는 경우). 그런 다음을 사용 x file하여 실행할 수 있습니다 ./file.

.명령 을 정의하려고하지 마십시오 . 명령은 . script이미 script현재 쉘에서 실행됩니다 . script현재 쉘에 대한 환경 변수를 정의 할 수 있습니다 .

도우미 스크립트를 만들 수 있다면 pwd를 PATH에 추가하는 도우미를 만들고

. pathhelper    #adds pwd to path
file            #now it can be run without ./

"."를 추가하지 않아도됩니다. 어떤 경로에서 무언가를 실행하려는 모든 경로로 .profile을 오염시킵니다.

수정 된 PATH로 새 쉘을 시작하는 도우미를 만들어이 접근 방식을 한 단계 더 발전시킬 수 있습니다. pwd를 기본값으로 사용하여 디렉토리를 매개 변수로 사용하는 pushd경우 경로를 편집하는 것과 같은 기능을 합니다. 서브 쉘을 종료 할 때 다른 환경 변수에 대한 변경 사항은 유실 될 수 있지만 장기 실행 쉘에서는 PATH 변수가 모두 어지럽히지는 않습니다. 워크 플로우에 따라이 방법이 유리할 수 있습니다.

:outer shell prompt$; subshellpathhelper    # launches a subshell with modified PATH
: subshell prompt $ ; file                  # in the subshell it can be run without ./

그러나 나는 당신이 그것을 실행하기를 원한다면 당신은 해킹 수도 있겠죠 pushd과 popd그들이 다른 변경 사항을 잃게됩니다 서브 쉘을하지 않고 경로에 동일한 수정을 할 수 있습니다.

pushd --path ~/some/path/    # normal pushd plus adds target to path
file                         # it can be run without ./ until you popd

(에 cd대한 아날로그가 없기 때문에 동일한 작업을 수행 할 수 없습니다 popd.)

PATH 항목을 푸시하고 팝업하기 위해 전용 도우미 쌍을 만들 수도 있습니다. 가장 잘 작동하는 것은 사용 패턴에 따라 다릅니다.

. script.sh실행하려는 스크립트가 현재 디렉토리에있는 한 구문을 사용할 수 있습니다 .

sh 또는 bash와 같은 인터프리터를 접두사로 사용할 수도 있습니다. 예:bash script.sh