Dlaczego CP nie ma paska postępu takiego jak wget?

Pamiętaj, że nie pytam jak . Znam już opcje takie jak pvi rsync -P.

Chcę zapytać, dlaczego nie cpimplementuje paska postępu, przynajmniej jako flagi?

Tradycją narzędzi uniksowych jest wyświetlanie komunikatów tylko wtedy, gdy coś pójdzie nie tak. Myślę, że dzieje się tak zarówno ze względów projektowych, jak i praktycznych. Projekt ma na celu uczynienie oczywistym, gdy coś pójdzie nie tak: pojawia się komunikat o błędzie i nie tonie w komunikatach, które nie zawierają informacji. Praktycznym powodem jest to, że w bardzo wczesnych czasach Uniksa nadal istniały teleprintery ; oznacza to, że dane wyjściowe z programów byłyby drukowane na papierze i nie chcesz drukować pasków postępu.

Bez względu na przyczynę tradycja wyświetlania tylko przydatnych wiadomości utknęła w świecie unixowym. Nowoczesne narzędzia czasami wprowadzały paski postępu; w przypadku rsync główną motywacją jest to, że rsync jest często wykonywany przez sieć, a sieci są znacznie bardziej niestabilne niż dyski lokalne, więc pasek postępu jest bardziej przydatny. To samo rozumowanie dotyczy wget.

W świecie uniksowym każde narzędzie jest zaprojektowane do wykonywania jednej pracy i wykonywania jej dobrze. Po co cpmartwić się o generowanie postępu, skoro inne narzędzie pvjuż to robi? Podobnie, dlaczego tak wiele programów zrzuca rzeczy na ekran bez podziału na strony? Ponieważ istnieją już narzędzia do tego zadania, takie jak more(lub less). Dlaczego większość programów wymagających edycji plików NIE przedstawia edytora i zamiast tego zleca pracę zewnętrzną $EDITOR? Ponieważ to sprawia, że ​​wszyscy wykonują jedno zadanie, do którego zostali stworzeni, a użytkownik używa swojego ulubionego edytora do wszystkich zadań.

Stycznie, większość programów powłokowych jest zaprojektowana tak, aby ich wyjście było przesyłane do innych programów powłoki. Jedynym wyjściem, jaki mogą dać, są rzeczy, które byłyby przydatne do przeanalizowania w następnym poleceniu w łańcuchu. cpTakie programy są używane w skryptach, a także ręcznie z terminala, więc jego wynik koncentruje się wokół kodu wyjścia i list plików, które nie powiodły się lub zakończyły się powodzeniem.

Zawsze oczekuj łączenia narzędzi, aby osiągnąć pożądany efekt.

Jest to jedna z tych marginalnych rzeczy, w których istnieją argumenty za i przeciw dodaniu opcji paska postępu do cp. Głównym argumentem przeciwko jest to, że możesz nie wiedzieć z góry, że chcesz poznać postęp. Ctrl-T / SIGINFO jest dostępny na BSD w tym celu, a jeśli stanie się on dostępny na platformach GNU / Linux, może być więcej powodów, aby uruchomić logikę paska postępu w cp. W międzyczasie bardziej ogólnego rozwiązaniem jest użycie oddzielnego narzędzia jak na Coreutils Progress Viewer ( progressdawniej znany jako cv) , aby wyświetlić stan każdego procesu w systemie.