Czy dobrą praktyką jest wymaganie ukośnika końcowego w nazwach katalogów?

9

Chcę poprosić użytkownika mojego skryptu bash o podanie ścieżki katalogu jako argumentu. Które z poniższych jest dobrą praktyką programowania?

Wymagaj, aby użytkownik wprowadził końcowe / (ukośnik)
Wymagaj, aby użytkownik nie wprowadzał końcowego / (ukośnika)

programming-practices user-interface bash

— Rohit Agarwal
źródło

3

Zauważ, że rsynczachowuje się inaczej w bardzo ważny sposób w zależności od obecności końca /, więc w niektórych przypadkach chciałbyś znormalizować dla spójności, a w innych chciałbyś przejść czysto, aby wdrożyć to, co powiedział użytkownik (jeśli wiedziałem, że rozmawiają rsync).

— sh1

Kolejnym, który mnie ostatnio zaskoczył, jest to, że ls -l dirzachowuje się inaczej niż ls -l dir/jeśli dirjest dowiązaniem symbolicznym do katalogu.

— Flimm,

Powiązane: Czy podczas definiowania ścieżki do katalogu należy uwzględnić ukośnik końcowy?

— Stevoisiak,

27

Najlepszą praktyką jest nie zakładanie żadnego z nich.

Jeśli masz dostęp do narzędzi / klas narzędzia do budowania ścieżek, skorzystaj z nich, jeśli nie, napisz kod, aby zaakceptować dowolny format i odpowiednio postępować.

Nic nie jest bardziej denerwujące dla użytkownika niż konieczność pamiętania, czy dodać ukośnik końcowy, czy nie.

— ChrisF
źródło

6

Następstwem: Zawsze analizy: Ścieżki z odpowiednich narzędzi wiersza polecenia - dirname, basenamei readlink. Bardzo częstym problemem jest ${path##*/}zastępowanie basename, ale jeśli ścieżka kończy się ukośnikiem, który zwraca pusty ciąg zamiast ostatniego elementu ścieżki.

— l0b0

1

+1 za korzystanie z klas użyteczności. Nie mogę powiedzieć, ile razy widziałem, jak programiści wymyślają na nowo koło, jeśli chodzi o składanie ścieżek, kiedy większość frameworków może to teraz łatwo zrobić.

— RationalGeek,

1

Jestem również bardzo zirytowany, gdy jakaś aplikacja wymaga ode mnie zrobienia tego w określony sposób. A czasami użytkownik nie może kontrolować, jak napisać tę ścieżkę: czasami pisze, więc tak, decyduje się na pisanie z ukośnikiem lub bez, ale w przypadkach, gdy użytkownik autouzupełnia za pomocą TAB, wiele powłok umieszcza ukośnik, więc musisz go usunąć? Jeszcze bardziej irytujące jest to, że aplikacja zachowuje się inaczej, jeśli umieścisz ukośnik w katalogu przekazywanym jako argument ( rsyncpatrzę na ciebie)

— Carlos Campderrós,

Ostatnio potrzebowałem zweryfikować ukośnik od danych wejściowych użytkownika do użycia z rsync (ponieważ jest wrażliwy na te rzeczy). Jak zauważył @ChrisF, najlepszą praktyką jest zakładanie żadnego z nich. Wymyśliłem następujące jako wdzięczny sposób zakładania, że nie: ${STR}$(printf \\$(printf '%03o' $(($(printf '%d' "'${STR:(-1)}")==47?0:47))))udokumentowałem to również dla jasności: dodaj lub usuń końcowy ukośnik w bash

— John Mark Mitchell,

10

Ponieważ bash ignoruje wiele ukośników, możesz bezpiecznie założyć, że użytkownik nie wprowadził ukośnika na ścieżce i sam go dodać.

cat /etc/hosts

jest taki sam jak

cat /////etc//////////hosts

Twój skrypt może wyglądać następująco:

echo -n "enter path: "
read path
if [ -f $path/myfile ]
then
  echo "found myfile!"
else
  echo "nope"
fi

i nie musisz się martwić, czy użytkownik wejdzie na trailing / na ścieżkę.

— użytkownik 281377
źródło

5

Nit: To nie jest bashzachowanie, jądro to robi.

— Blrfl

7

Zmarły Jon Postel miał kilka świetnych rad w sekcji 3.2 RFC 760, które mają tutaj zastosowanie:

Zasadniczo implementacja powinna być zachowawcza w zachowaniu wysyłającym i liberalna w zachowaniu przyjmującym. Oznacza to, że należy ostrożnie wysyłać dobrze uformowane datagramy, ale powinien akceptować każdy datagram, który może zinterpretować (np. Nie sprzeciwić się błędom technicznym, których znaczenie jest nadal jasne).

— Blrfl
źródło

3

Pod względem koncepcyjnym ukośnik nie jest częścią nazwy. Ukośnik jest tylko separatorem między nazwami. Mój katalog domowy to / home / stefan, a nie / home / stefan /.

Jeśli nie spodziewasz się końcowego ukośnika, nie zawiedziesz, jeśli taki istnieje, jak już wspomniano amunicji. Ale możesz łatwo skleić nazwy i zmienne, ponieważ nie musisz cytować ukośnika:

a="/home"
b="stefan"

dir=$a/$b

— nieznany użytkownik
źródło

0

Wymaganie, aby katalog nie zawierał ukośnika końcowego, byłoby bardzo denerwujące dla interaktywnego użycia na konsoli: automatyczne uzupełnianie za pomocą TAB automatycznie dodaje ukośnik końcowy dla katalogów.

Więc na pewno musisz zezwolić, aby katalogi były oznaczone końcowym ukośnikiem.

— oberlies
źródło