Почему входные данные stdin редко имеют опциональные входные данные, в то время как обычные для аргументов командной строки?

Моя проблема заключалась в том, что я не понимал, что awk также использует пробел в качестве разделителя, а не только табуляцию. После добавления -F'\t'все работает. Сравнение чисел было в порядке.

-1
08.12.2019, 15:43
3 ответа

Это очень необычно для программ Unix принимать параметры командной строки на стандартный ввод.

На самом деле это привело бы к изменению поведения, потому что в мире Unix расширение имени файла («подстановка» )выполняется вызывающей оболочкой, а не приложением.

напр. если вы выполните ls *.c, то оболочка расширяет *.cв file1.cfile2.c, и поэтому на самом деле выполняется ls file1.c file2.c.

Если бы у вас были значения на стандартном вводе, тогда программа отвечала бы за расширение.

Итак... это не только не распространено, но и вообще не очень хорошая идея.

Программы нередко запрашивают отсутствующие данные

напр.

#!/bin/bash

filename=$1

if [ -z "$filename" ]
then
  read -p Filename: filename
fi

Но это не то же самое, что использование параметров командной строки на стандартном вводе.

1
28.04.2021, 23:37

Команды этого не делают, потому что многие обычно получают данные из стандартного ввода. Если бы стандартный ввод был смесью параметров и данных, все было бы сложно (и опасно ).

2
28.04.2021, 23:37

tl;dr Это очень похоже на желание использовать lsв сценариях(1 , 2 ), цитирование только при необходимости или пересечение потоков (что почти буквально то, что это делает, используя стандартный ввод для двух полностью ортогональных вещей ). Это плохая идея.

При таком подходе возникает несколько проблем:

  1. Ваш инструмент должен будет обрабатывать всерасширения , которые оболочка уже обрабатывает за вас :
    • расширение раскоса
    • расширение тильды
    • раскрытие параметров и переменных
    • подстановка команды
    • арифметическое расширение
    • разбиение на слова
    • расширение имени файла, включая подстановку имен , как указывает @StephenHarris
  2. Если ваш инструмент не обрабатывает какие-либо расширения (, как вы предлагаете , в отличие от приведенного вами примера, который явно должен выполнять разбиение слов, чтобы не рассматривать -l fetch.pngкак один параметр ), вы придется очень долго объяснять разработчикам, почему ни один из -l "$path", -l ~/Downloadsи -l 'my files'не делает того, что они ожидают.
  3. Если ваш инструмент обрабатывает расширения не так, как оболочки (, что он будет делать, потому что оболочки обрабатывают расширения по-разному, и никто не может позволить себе определить, в какой оболочке вы работаете, и поддерживать их все навсегда ), вы только что добавили новый синтаксис, который необходимо изучить, запомнить и использовать всем, кто использует ваш инструмент.
  4. Стандартный ввод больше не является просто вводом инструмента. Основываясь наThe Unix Philosophy , , он больше не может тривиально работать вместе с другими инструментами, потому что этим другим инструментам придется делать особые вещи, чтобы передать входные данные вашему инструменту.
  5. Уже существует соглашение, используемое каждым основным инструментом. Нарушение условностей таким фундаментальным образом было бы действительно плохой идеей с точки зрения удобства использования.
  6. Смешивание опций и ввода не может безопасно выполняться для произвольного ввода, если только вы не приложите дополнительных усилий по кодированию или экранированию одного из них.
4
28.04.2021, 23:37

Теги

Похожие вопросы