bash에서 파일을 만들거나 자르거나 덮어 쓸 수 있는지 어떻게 확인합니까?

사용자는 스크립트의 어느 시점에서 foo.sh file.txt또는 처럼 파일 경로를 만들거나 덮어 쓰는 파일 경로로 내 스크립트를 호출합니다 foo.sh dir/file.txt.

작성 또는 덮어 쓰기 동작은 >출력 경로 재 지정 연산자 의 오른쪽에 파일을 배치 하거나 인수로 파일을 전달하기 위한 요구 사항과 매우 유사합니다 tee(사실, 파일을 인수로 전달하는 tee것은 정확히 내가 수행하는 작업입니다) ).

스크립트의 장에 들어가기 전에 파일 을 만들거나 덮어 쓸 수는 있지만 실제로 만들지는 않는지 합리적으로 확인하고 싶습니다 . 이 검사는 완벽 할 필요는 없으며 예, 검사와 파일이 실제로 작성된 지점 사이에서 상황이 바뀔 수 있다는 것을 알고 있습니다. 그러나 여기서는 최선의 노력 유형 솔루션으로 괜찮 으므로 조기에 구제 할 수 있습니다 파일 경로가 유효하지 않은 경우

파일을 만들 수없는 이유의 예 :

• 파일에 디렉토리 구성 요소가 포함되어 dir/file.txt있지만 디렉토리 dir가 존재하지 않습니다.
• 지정된 디렉토리 (또는 디렉토리가 지정되지 않은 경우 CWD)에 대한 쓰기 권한이 사용자에게 없습니다.

그렇습니다. "앞에서"권한을 확인하는 것이 UNIX Way ™ 가 아니라는 것을 알고 작업을 시도하고 나중에 용서를 구해야합니다. 그러나 내 특정 스크립트에서 이것은 나쁜 사용자 경험으로 이어지고 책임있는 구성 요소를 변경할 수 없습니다.

명백한 테스트는 다음과 같습니다.

if touch /path/to/file; then
    : it can be created
fi

그러나 실제로 파일이 없으면 파일을 만듭니다. 우리는 스스로를 정리할 수 있습니다.

if touch /path/to/file; then
    rm /path/to/file
fi

그러나 이것은 이미 존재하는 파일을 제거 할 것입니다.

그러나 우리는이 문제를 해결할 방법이 있습니다.

if mkdir /path/to/file; then
    rmdir /path/to/file
fi

해당 디렉토리의 다른 객체와 이름이 같은 디렉토리를 가질 수 없습니다. 디렉토리를 만들 수는 있지만 파일을 만들 수없는 상황은 생각할 수 없습니다. 이 테스트가 끝나면 스크립트를 사용하여 기존 방식을 자유롭게 만들고 /path/to/file원하는대로 작업 할 수 있습니다.

내가 수집하는 것에서 사용할 때 확인하고 싶습니다.

tee -- "$OUT_FILE"

( ---로 시작하는 파일 이름에 대해서는 또는 작동하지 않습니다), tee쓰기 위해 파일을 여는 데 성공합니다.

그게 그거야:

• 파일 경로의 길이가 PATH_MAX 제한을 초과하지 않습니다
• 파일이 존재하고 (symlink 확인 후) 디렉토리 유형이 아니며 쓰기 권한이 있습니다.
• 파일이 존재하지 않는 경우 파일의 dirname은 (symlink 확인 후) 디렉토리로 존재하며 파일에 대한 쓰기 및 검색 권한이 있으며 파일 이름 길이는 디렉토리가있는 파일 시스템의 NAME_MAX 제한을 초과하지 않습니다.
• 또는 파일이 존재하지 않고 심볼릭 링크 루프는 아니지만 바로 위의 기준을 충족하는 파일을 가리키는 심볼릭 링크

vfat, ntfs 또는 hfsplus와 같은 파일 시스템에는 파일 이름에 포함될 수있는 바이트 값, 디스크 할당량, 프로세스 제한, selinux, apparmor 또는 기타 보안 메커니즘, 전체 파일 시스템, inode가 남지 않은 장치, 장치 등이 제한되는 파일 시스템은 무시합니다. 어떤 이유로 프로세스가 열릴 수있는 실행 파일 인 다른 이유로 인해 열 수없는 파일은 파일을 열거 나 만드는 기능에도 영향을 줄 수 있습니다.

로 zsh:

zmodload zsh/system
tee_would_likely_succeed() {
  local file=$1 ERRNO=0 LC_ALL=C
  if [ -d "$file" ]; then
    return 1 # directory
  elif [ -w "$file" ]; then
    return 0 # writable non-directory
  elif [ -e "$file" ]; then
    return 1 # exists, non-writable
  elif [ "$errnos[ERRNO]" != ENOENT ]; then
    return 1 # only ENOENT error can be recovered
  else
    local dir=$file:P:h base=$file:t
    [ -d "$dir" ] &&    # directory
      [ -w "$dir" ] &&  # writable
      [ -x "$dir" ] &&  # and searchable
      (($#base <= $(getconf -- NAME_MAX "$dir")))
    return
  fi
}

에서 bash또는 본쉘 같은 그냥 교체

zmodload zsh/system
tee_would_likely_succeed() {
  <zsh-code>
}

와:

tee_would_likely_succeed() {
  zsh -s -- "$@" << 'EOF'
  zmodload zsh/system
  <zsh-code>
EOF
}

zsh여기 의 특정 기능은 $ERRNO(마지막 시스템 호출의 오류 코드를 표시 함) $errnos[]관련 배열을 해당 표준 C 매크로 이름으로 변환합니다. 그리고 $var:h(csh에서) 및 $var:P(zsh 5.3 이상 필요).

bash에는 아직 동등한 기능이 없습니다.

$file:hdir=$(dirname -- "$file"; echo .); dir=${dir%??}또는 GNU dirname: 로 대체 할 수 있습니다 IFS= read -rd '' dir < <(dirname -z -- "$file").

의 경우 파일에서 $errnos[ERRNO] == ENOENT접근 ls -Ld하고 오류 메시지가 ENOENT 오류에 해당하는지 확인 하는 방법이 있습니다 . 그래도 믿을 수 있고 휴대하기가 까다 롭습니다.

한 가지 방법은 다음과 같습니다.

msg_for_ENOENT=$(LC_ALL=C ls -d -- '/no such file' 2>&1)
msg_for_ENOENT=${msg_for_ENOENT##*:}

(오류 메시지 가정 끝 로 syserror()번역 ENOENT하고 그 번역이 포함되지 않는 :대신, 다음) 및 [ -e "$file" ]수행 :

err=$(ls -Ld -- "$file" 2>&1)

와 함께 ENOENT 오류를 확인하십시오.

case $err in
  (*:"$msg_for_ENOENT") ...
esac

이 $file:P부분은 bash특히 FreeBSD 에서 가장 까다로운 부분입니다 .

FreeBSD에는 옵션 을 허용 하는 realpath명령과 readlink명령이 -f있지만 파일이 해석되지 않는 심볼릭 링크 인 경우에는 사용할 수 없습니다. 그와 같은의 perl의 Cwd::realpath().

python의 os.path.realpath()유사에 작동하는 것처럼 않는 zsh $file:P정도의 적어도 하나 개의 버전 가정, python설치하고는있다 python, 당신이 할 수있는 (안 FreeBSD의에 주어진 인) 중 하나를 의미 명령 :

dir=$(python -c '
import os, sys
print(os.path.realpath(sys.argv[1]) + ".")' "$dir") || return
dir=${dir%.}

그러나에서의 모든 작업을 수행 할 수도 있습니다 python.

또는 모든 코너 케이스를 처리하지 않기로 결정할 수 있습니다.

고려해야 할 한 가지 옵션 은 파일을 조기에 작성 하지만 나중에 스크립트에서 채우는 것입니다. 이 exec명령을 사용하여 파일 설명자 (예 : 3, 4 등)에서 파일을 연 다음 나중에 파일 설명자 ( >&3등)로 리디렉션을 사용 하여 해당 파일에 내용을 쓸 수 있습니다.

다음과 같은 것 :

#!/bin/bash

# Open the file for read/write, so it doesn't get
# truncated just yet (to preserve the contents in
# case the initial checks fail.)
exec 3<>dir/file.txt || {
    echo "Error creating dir/file.txt" >&2
    exit 1
}

# Long checks here...
check_ok || {
    echo "Failed checks" >&2
    # cleanup file before bailing out
    rm -f dir/file.txt
    exit 1
}

# We're ready to write, first truncate the file.
# Use "truncate(1)" from coreutils, and pass it
# /dev/fd/3 so the file doesn't need to be reopened.
truncate -s 0 /dev/fd/3

# Now populate the file, use a redirection to write
# to the previously opened file descriptor.
populate_contents >&3

a trap를 사용하여 오류가 발생했을 때 파일을 정리할 수도 있습니다 . 이는 일반적인 관행입니다.

이렇게 하면 파일을 만들 수있는 권한에 대한 실제 검사를받을 수 있으며, 동시에 실패 할 경우 긴 검사를 기다리는 데 시간을 소비하지 않을 정도로 빨리 파일을 수행 할 수 있습니다.

업데이트 : 검사가 실패 할 때 파일을 방해 하지 않으려면 파일을 즉시 자르지 않는 bash의 fd<>file리디렉션 을 사용 하십시오. (우리는 파일을 읽는 것에 신경 쓰지 않습니다. 이것은 해결 방법 일 뿐이므로 잘리지 않습니다. 추가 >>하면 아마도 작동하지만 O_APPEND 플래그를 유지하면서 조금 더 우아하게 찾는 경향이 있습니다 그림의.)

내용을 바꿀 준비가되면 먼저 파일을 잘라 내야합니다 (그렇지 않으면 이전에 파일에 있던 것보다 적은 바이트를 쓰면 후행 바이트가 그대로 유지됩니다). truncate (1) 그런 목적으로 coreutils에서 명령을 실행하면 /dev/fd/3의사 파일을 사용하여 열린 파일 설명자를 전달할 수 있으므로 파일을 다시 열 필요가 없습니다. (다시 말해서 기술적으로 더 간단한 : >dir/file.txt것이 작동하지만 파일을 다시 열지 않아도되는 것이 더 우아한 솔루션입니다.)

DopeGhoti의 솔루션이 더 낫다고 생각하지만 이것이 작동해야합니다.

file=$1
if [[ "${file:0:1}" == '/' ]]; then
    dir=${file%/*}
elif [[ "$file" =~ .*/.* ]]; then
    dir="$(PWD)/${file%/*}"
else
    dir=$(PWD)
fi

if [[ -w "$dir" ]]; then
    echo "writable"
    #do stuff with writable file
else
    echo "not writable"
    #do stuff without writable file
fi

첫 번째 if 구문은 인수가 전체 경로인지 확인하고 (로 시작 /) dir변수를 디렉토리 경로로 설정합니다 /. 그렇지 않으면 인수가 a로 시작하지 않지만 (하위 디렉토리 지정)을 /포함하는 경우 현재 작업 디렉토리 + 하위 디렉토리 경로로 설정됩니다. 그렇지 않으면 현재 작업 디렉토리를 가정합니다. 그런 다음 해당 디렉토리가 쓰기 가능한지 확인합니다./dir

test아래에 설명 된 것처럼 일반 명령을 사용하는 것은 어떻습니까?

FILE=$1

DIR=$(dirname $FILE) # $DIR now contains '.' for file names only, 'foo' for 'foo/bar'

if [ -d $DIR ] ; then
  echo "base directory $DIR for file exists"
  if [ -e $FILE ] ; then
    if [ -w $FILE ] ; then
      echo "file exists, is writeable"
    else
      echo "file exists, NOT writeable"
    fi
  elif [ -w $DIR ] ; then
    echo "directory is writeable"
  else
    echo "directory is NOT writeable"
  fi
else
  echo "can NOT create file in non-existent directory $DIR "
fi

사용자 경험이 귀하의 질문을 주도하고 있다고 언급했습니다. 기술적 인 측면에서 좋은 답변을 얻었으므로 UX 각도에서 대답하겠습니다.

사전 점검을 수행하는 대신 결과를 임시 파일 에 쓴 다음 마지막에 사용자가 원하는 파일에 결과를 넣는 것은 어떻습니까? 처럼:

userfile=${1:?Where would you like the file written?}
tmpfile=$(mktemp)

# ... all the complicated stuff, writing into "${tmpfile}"

# fill user's file, keeping existing permissions or creating anew
# while respecting umask
cat "${tmpfile}" > "${userfile}"
if [ 0 -eq $? ]; then
    rm "${tmpfile}"
else
    echo "Couldn't write results into ${userfile}." >&2
    echo "Results available in ${tmpfile}." >&2
    exit 1
fi

이 접근 방식의 장점은 정상적인 해피 패스 시나리오에서 원하는 작업을 생성하고 테스트 및 설정 원 자성 문제를 회피하며 필요한 경우 작성하는 동안 대상 파일의 권한을 유지하며 구현하기가 쉽지 않습니다.

참고 : 우리가 사용했다 mv 했다면 임시 파일의 권한을 유지하고 싶습니다. 우리는 원하지 않습니다. 권한은 대상 파일에 설정된 권한을 유지하려고합니다.

이제 나쁜 점 : 공간 ( cat .. >구문)의 두 배가 필요하고 필요한 시점에 대상 파일을 쓸 수없는 경우 사용자가 수동 작업을 수행하도록하고 임시 파일을 남겨 둡니다 (보안이있을 수 있음) 또는 유지 보수 문제).

TL; DR :

: >> "${userfile}"

달리 <> "${userfile}"거나 touch "${userfile}",이 파일의 타임 스탬프에 대한 가짜 수정을하지 않으며 또한 쓰기 전용 파일과 함께 작동합니다.

OP에서 :

파일을 만들거나 덮어 쓸 수 있지만 실제로 만들지는 않는지 합리적으로 확인하고 싶습니다.

UX 관점 에서 귀하의 의견에서 내 대답에 이르기까지 :

이것이 실패하는 압도적 인 대다수는 제공된 경로가 유효하지 않기 때문입니다. 작업 도중에 작업을 중단하기 위해 일부 FS를 동시에 수정하는 악의적 인 사용자를 합리적으로 막을 수는 없지만 유효하지 않거나 쓸 수없는 경로의 # 1 실패 원인을 확실히 확인할 수 있습니다.

신뢰할 수있는 유일한 테스트는 open(2)경로, 소유권, 파일 시스템, 네트워크, 보안 컨텍스트 등과 같은 쓰기 가능성에 대한 모든 질문을 해결하기 때문에 파일 대한 . 다른 테스트는 쓰기 가능성의 일부를 다루지 만 다른 테스트는 다루지 않습니다. 테스트의 하위 세트를 원할 경우 궁극적으로 중요한 것을 선택해야합니다.

그러나 여기 또 다른 생각이 있습니다. 내가 이해 한 것에서 :

1. 콘텐츠 제작 과정이 오래 지속되고
2. 대상 파일은 일관된 상태로 유지되어야합니다.

# 1 때문에이 사전 검사를 수행하려고하고 # 2 때문에 기존 파일로 바이올린을 사용하고 싶지 않습니다. 그렇다면 왜 쉘에 파일을 열어달라고 요청하지 말고 실제로 아무것도 추가하지 않습니까?

$ tree -ps
.
├── [dr-x------        4096]  dir_r
├── [drwx------        4096]  dir_w
├── [-r--------           0]  file_r
└── [-rw-------           0]  file_w

$ for p in file_r dir_r/foo file_w dir_w/foo; do : >> $p; done
-bash: file_r: Permission denied
-bash: dir_r/foo: Permission denied

$ tree -ps
.
├── [dr-x------        4096]  dir_r
├── [drwx------        4096]  dir_w
│   └── [-rw-rw-r--           0]  foo
├── [-r--------           0]  file_r
└── [-rw-------           0]  file_w

이를 통해 쓰기 가능성 질문이 원하는대로 정확하게 해결됩니다.

open("dir_w/foo", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3

파일 내용이나 메타 데이터를 수정하지 않고 자,이 접근법은 :

• 파일이 추가 전용인지는 알려주지 않으므로 콘텐츠 작성이 끝날 때 파일을 업데이트 할 때 문제가 될 수 있습니다. 이를 어느 정도 감지 lsattr하고 그에 따라 반응 할 수 있습니다 .
• 그러한 경우 이전에 존재하지 않는 파일을 작성합니다 rm. selective로이를 완화하십시오 .

(다른 대답으로) 가장 사용자 친화적 인 접근 방식은 사용자가 이동 해야하는 임시 파일을 작성하는 것이라고 주장하지만 , 이것이 입력을 완전히 조사 하는 데 가장 적대적인 접근 방식 이라고 생각합니다 .