Какая разница в использовании «touch file» и «> file» при создании нового файла?

Я новичок в Linux. Когда я создаю новый файл .gitignore в текущем каталоге, используя bash, я обнаружил, что могу сделать:

> .gitignore

или

touch .gitignore

Кажется, они делают то же самое. Когда я проверяю руководство на touchэто, оно говорит, что изменяет метку времени для текущего файла, но нет никакого руководства для >. Так может кто-нибудь объяснить, что можно >сделать, и есть ли разница в использовании этих двух команд в этом контексте? Благодарю.

command-line

— Стив Дэн Зиши
источник

Мне любопытно, где вы научились использовать «>» в качестве генератора файлов, не изучив его предполагаемое использование

— forresthopkinsa

Вы найдете переадресацию, документированную в руководстве по Bash. В командной строке введите команду man bash. Это длинный документ, и на его понимание уйдут дни или даже недели, но его стоит изучить, если вы хотите тщательно изучить Bash.

— Пэдди Ландау

Ответы:

>является оператором перенаправления оболочки. См. В чем разница между ">" и ">>" в команде оболочки? и когда я должен использовать <или <() или << и> или> ()? Он в основном используется для перенаправления вывода команды в файл. Если файл не существует, оболочка создает его. Если он существует, оболочка обрезает его (очищает). С просто > fileнет команды, поэтому оболочка создает файл, но не отправляет выходные данные, поэтому чистый эффект заключается в создании пустого файла или очистке существующего файла.

touchэто внешняя команда, которая создает файл или обновляет временную метку, как вы уже знаете. При touchэтом содержимое файла не теряется, если оно существует, в отличие от >.

Поведение >зависит от оболочки. В bash, dash и большинстве оболочек все > fooбудет работать так, как вы ожидаете. В zsh по умолчанию > fooработает как cat > foo- zsh ждет, пока вы введете ввод.

— Мур
источник

Ключевым моментом здесь является то , что нет практической разницы между >> fileи , touch fileно , если fileне существует, есть большая разница между ними обоими и > file(в том , что предыдущее содержимое fileтеряется). Кроме того, противоречивое поведение zsh означает touch file«самый безопасный», и поэтому его следует запомнить как «Правильный способ сделать это».

— Монти Хардер

Вот интересное сравнение:

$ cat redirect.sh touch.sh sed.sh awk.sh cp.sh truncate.sh tee.sh vi.sh
> redirect.txt
touch touch.txt
sed 'w sed.txt' /dev/null
awk 'BEGIN {printf > "awk.txt"}'
cp /dev/null cp.txt
truncate -s0 truncate.txt
tee tee.txt </dev/null
vi -esc 'wq vi.txt'

Результат:

$ strace dash redirect.sh | wc -l
387

$ strace dash touch.sh | wc -l
667

$ strace dash sed.sh | wc -l
698

$ strace dash awk.sh | wc -l
714

$ strace dash cp.sh | wc -l
786

$ strace dash truncate.sh | wc -l
1004

$ strace dash tee.sh | wc -l
1103

$ strace dash vi.sh | wc -l
1472

— Стивен Пенни
источник

Хотя сравнение может быть интересным, я не совсем понимаю, что вы хотите, чтобы я увидел здесь. Можете ли вы объяснить, что вы собираетесь? Я предполагаю, что это разные способы записать вещи в файлы, но я нахожу это немного запутанным, как это. Может быть, мой недостаток кофе, хотя.

— 8:00 17

@ m00am, что показано здесь, по сути, 8 различных способов создания файла. straceдолжен показывать выполняемые системные вызовы, а > file.txtметод - это наименьшее количество выполненных системных вызовов, что на самом деле не так уж удивительно - чем сложнее инструмент, тем сложнее его системные вызовы. Проблема с показанными примерами, однако, заключается в том, что straceзапись в stderrпоток выполняется по умолчанию, и в этом ответе Стивен использует канал только для чтения stderr, поэтому я немного запутался, как он подсчитывал строки, используя |канал, а не|&

— Сергей Колодяжный,

И в Ubuntu 16.04, используя |&, как упоминает @Serg, я получаю отсчеты примерно пятую часть от здесь ... за исключением viслучая, когда я получаю примерно одинаковое значение

— muru

WSL? Ого ... Я не думаю , что WSL бы добавить , что многие системные вызовы для того, что он делает.

— Муру

@muru Cygwin - WSL еще не готов к работе stackoverflow.com/a/40370009

— Стивен Пенни